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?

Yesssss! Thanks for the new compiler, boss ;]

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.

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

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.

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?

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.

Problems with kate
 

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