LinuxQuestions.org
LinuxAnswers - the LQ Linux tutorial section.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 03-27-2013, 10:40 AM   #31
GazL
Senior Member
 
Registered: May 2008
Posts: 3,325

Rep: Reputation: 882Reputation: 882Reputation: 882Reputation: 882Reputation: 882Reputation: 882Reputation: 882

Wow, wasn't expecting that little lot when I did my afternoon rsync. Thanks Pat.


Pat, can I ask what the kernel-headers package now contains? AIUI general wisdom is that the installed kernel headers should be frozen at the point that glibc is built for sake of consistency. Is that what you do, or does the kernel-headers-3.8.4 package contain the results of a make headers_install from 3.8.4?
 
Old 03-27-2013, 12:49 PM   #32
BrZ
Member
 
Registered: Apr 2009
Distribution: Slackware
Posts: 491

Rep: Reputation: 79
Yesssss! Thanks for the new compiler, boss ;]
 
Old 03-27-2013, 02:21 PM   #33
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 858

Rep: Reputation: 1668Reputation: 1668Reputation: 1668Reputation: 1668Reputation: 1668Reputation: 1668Reputation: 1668Reputation: 1668Reputation: 1668Reputation: 1668Reputation: 1668
Quote:
Originally Posted by GazL View Post
Pat, can I ask what the kernel-headers package now contains? AIUI general wisdom is that the installed kernel headers should be frozen at the point that glibc is built for sake of consistency. Is that what you do, or does the kernel-headers-3.8.4 package contain the results of a make headers_install from 3.8.4?
The kernel-headers package always contains the headers that were built from the kernel of the same version. Now, in the case of 3.8.4, recompiling glibc against the new headers does not change any existing API, and adds exactly one new define to /usr/include/bits/syscall.h in the glibc headers that doesn't seem to be used by any existing code (yet).

I'd say in about 99% of the cases, unless there's been a major change in the kernel (2.4 -> 2.6 comes to mind), it doesn't really matter much if glibc gets a rebuild. I think this case is easily in the 99% bracket, but maybe I'll do it anyway.
 
2 members found this post helpful.
Old 03-27-2013, 02:23 PM   #34
solarfields
Member
 
Registered: Feb 2006
Location: Outer Shpongolia
Distribution: Slackware
Posts: 448

Rep: Reputation: 116Reputation: 116
of course it does

EDIT: ups... this was meant as an answer to the thread title "Slackware-current is looking good", not arguing with Pat

Last edited by solarfields; 03-28-2013 at 04:26 AM. Reason: clarification
 
Old 03-27-2013, 03:38 PM   #35
GazL
Senior Member
 
Registered: May 2008
Posts: 3,325

Rep: Reputation: 882Reputation: 882Reputation: 882Reputation: 882Reputation: 882Reputation: 882Reputation: 882
Quote:
Originally Posted by volkerdi View Post
The kernel-headers package always contains the headers that were built from the kernel of the same version. Now, in the case of 3.8.4, recompiling glibc against the new headers does not change any existing API, and adds exactly one new define to /usr/include/bits/syscall.h in the glibc headers that doesn't seem to be used by any existing code (yet).

I'd say in about 99% of the cases, unless there's been a major change in the kernel (2.4 -> 2.6 comes to mind), it doesn't really matter much if glibc gets a rebuild. I think this case is easily in the 99% bracket, but maybe I'll do it anyway.
Thanks for that explanation. I've wondered for a while now what your process is here. (now I know )

The reason I asked was I started wondering about that possible reversion to 3.4 you mentioned (though hopefully it won't be needed) and what impact that might have. While i agree with you that things generally work just fine when moving forward, having an older kernel and/or set of headers to those used for glibc sounds a little more risky a proposition.
 
Old 03-27-2013, 05:07 PM   #36
Erik_FL
Member
 
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 796

Rep: Reputation: 247Reputation: 247Reputation: 247
If the previous releases of KDE are any indication of things, it will take a few more releases of KDE 4.10 before it is working well enough for another Slackware release. So far I've had to update KDE after every Slackware release from 13 forward. That leads me to believe that KDE is not being tested enough before Slackware is released. My other suggestion is to release one version behind KDE development. For example if KDE 4.10 has been released then use the last version of 4.9 in a Slackware release. For the next Slackware release that might mean waiting for KDE 4.11 to release Slackware with KDE 4.10.

I recently made the mistake up upgrading KDE 4.9 to 4.10. While 4.10 is faster, it also has a lot of display bugs. The panel often turns solid white or black and sometimes I see transparent window borders instead of the correct colors. The problems are worse if I run KDE in a virtual machine, even with all the 3D acceleration disabled. KDE 4.10 seems like it may be crashing less, but it's hard to tell.

Because Slackware is so KDE centric, my suggestion is to find a really solid version of KDE and do a lot more testing before deciding to release Slackware. That also might mean choosing versions of some other packages based on what works the best with KDE.

My dilemma is how to deal with VirtualBox KDE compatibility issues. I'm pretty much stuck using whatever version of VirtualBox works best for my Windows software development. Unfortunately new KDE releases tend to break VirtualBox compatibility. It is also very helpful to use VirtualBox to run the same version of Slackware as I have installed on my hardware. I've managed to do that by updating KDE after Slackware releases and carefully choosing the version of VirtualBox to install.

Is it time to consider adding more non-KDE applications or another desktop environment as an alternative to KDE?
 
Old 03-27-2013, 06:21 PM   #37
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,476

Rep: Reputation: 532Reputation: 532Reputation: 532Reputation: 532Reputation: 532Reputation: 532
I empathize with your position. I won't defend KDE but I don't think the problem is KDE per se.

A more fundamental root cause is the painful pace at which free/libre software changes. Hardly a day goes by where I don't find something broken. Sometimes the breakage is upstream, sometimes the cause is a conflict between softwares, sometimes the cause is me trying to do something that is obvious to me but never occurred to the upstream developers. Sure, sometimes the problem is PEBKAC, but more often than not the relentless pace at which free/libre software evolves is at the heart of the problem.

Another root cause, generally, is free/libre software developers tend to treat the software as a personal playground. While there is some nominal accountability to users, often developers cater to their own itch rather than program from a group approach. With the nature of free/libre software I expect a lot of personal itch scratching, but when projects become seriously large that tens of thousands of people become dependent upon the software, there should be a shift in attitude.

Another root cause is the general lack, and avoidance, of meaningful usability testing. Usability testing in free/libre software generally just does not happen, except within the inner core of the developer priesthood. Few free/libre developers spend time with non developer and non geek types of users to understand or appreciate some of the problems their geekhood can cause. In this respect I believe proprietary software still has a major advantage over free/libre software. Unlike free/libre software, proprietary software developers seldom get the last word about how software will look and function.

KDE developers did not move from KDE 3.5 to KDE 4.0 in a graceful or diplomatic manner. They abandoned KDE 3.5 a couple of years before they released 4.0 and that non support interim left a sour taste with many people. KDE4 did not mature at a fast enough pace to satisfy long-term KDE users, leaving KDE users in a perpetual state of alpha and beta testing. Many left the fold. I myself avoided KDE4 for the full five years since 4.0, using my own builds of KDE 3.5 and Trinity during the period, and only recently installed 4.10.1. With that said, overall I think the KDE developers have responded well enough to the public relations mess they contributed to five years ago with KDE 4.0. With 4.10 I believe KDE4 finally reached a level of palatable usability without users feeling like perpetual testers.

I find KDE 4.10.1 stable yet I have done significant pruning. I have almost all desktop effects and animations disabled. I lived with them for a while after installing KDE 4.10 but overwhelmingly after several days the novelty of most effects disappeared and I disabled most of them.

Further personal pruning includes not using nepomuk at all despite potential benefits and recent code changes to improve performance.

I have more or less avoided akonadi, continuing instead with using kmail and kalarm from Trinity.

Not that 4.10.1 is without bugs. The notification system is suffering various regressions from 4.9, as I discovered trying to resolve a few related problems and then researching the bug tracking system. Amarok 2 can be tamed but is a serious mind shift from the familiar and well loved Amarok 1.4.

Recently I started using kalarm from KDE4 while still using kmail from Trinity. I am realizing the entire akonadi overhead is just plain silly to run a single minor app like kalarm. Running akonadi impedes KDE startup times and typically I don't see the kalarm icon appear in my system tray for about 30 to 45 seconds after startup --- a pretty long time by almost any software standard.

There are a few minor bugs with kmail2 that motivate me to avoid that app until fixed, but the whole akonadi layer perplexes me. I see potential benefits for those who deal with massive amounts of data, but I see no benefit for a significant number of users.

Therein lies a combination of root causes to software instability. I understand that nepomuk and akonadi are so-called "pillars" of KDE technology. I really get the whole pitch. I don't get at all that KDE developers won't seek a happy compromise to allow that significant number of users who have no serious data crunching needs to compile or configure KDE without nepomuk and akonadi.

I looked at the KDE PIM code. Akonadi is now deeply embedded throughout. The longer this continues the more challenged developers will be to find a way to allow users to unhitch themselves from akonadi. I fear the end result is a massive avoidance of KDE PIM apps, which means only hard core developers will be using, which will contribute to an excessive narrow perspective in programming, which will lead to further dissatisfaction and instability.

For myself, I'd like to see Pat hold off as long as possible with the next official release such that the KDE packages can be updated to the latest point release. Considering the average 8 to 9 month release cycle, that means KDE 4.10.3 could be included in the next official release. As these point releases are bug fix releases, that patience would go far to help ensure KDE is reasonably stable with the next Slackware release.

I'd like to see a handful of us Slackers create a robust /etc/skel ~/.kde profile such that most bells and whistles are disabled as the default. We could post that profile package somewhere online. Pat and the gang then could release KDE as is from upstream, but cautious users could install the profile before launching KDE for the first time. This profile would allow users to methodically explore which bells and whistles they want to enable rather than frantically trying to learn which to disable. I have been tinkering with this idea for my personal usage.

I empathize with Pat and the gang with trying to keep pace with this madness, to build a stable system, to seek awkward compromises and compatibilities.
 
Old 03-27-2013, 06:34 PM   #38
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,033

Rep: Reputation: 969Reputation: 969Reputation: 969Reputation: 969Reputation: 969Reputation: 969Reputation: 969Reputation: 969
Problems with kate

[previous content wrongly posted here instead of in new thread, sorry]

Last edited by Didier Spaier; 03-27-2013 at 06:37 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] setup fails on most current Slackware-current March 26, 2012 AlleyTrotter Slackware 15 04-09-2012 06:05 AM
[SOLVED] Script to build always a current ISO image of Slackware (slackware-current) robertjinx Slackware 2 12-09-2010 02:00 AM
Slackware64 -current vs Slackware -current or Slackware onebuck Slackware 16 06-23-2009 01:19 PM
slackware current question on the current kernels davimint Slackware 3 06-03-2007 07:39 AM
DISCUSSION: Upgrade to Slackware -current without a -current CD truthfatal LinuxAnswers Discussion 0 09-19-2006 01:42 PM


All times are GMT -5. The time now is 05:43 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration