Hi everyone,

I just want to share my experiences with Slackware64, why I upgraded to -current, and why am I currently back on -stable.

PRO -current

The most obvious reason for upgrading to -current is KDE 4.3.3, as it has many improvements. Most relevant for me are these:

1. Complete translation to my language.

2. Dolphin and KMail are even more stable, though I haven't really have stability problems with 4.2.4 that would be worth mentioning. Just, in very special situations I was able to provoke a crash, where now the programs just "behave".

3. Integration with HAL got a lot better. Most of my external USB hard disks are LUKS encrypted, now. When I plug them to my computer, the device notifier opens, and when I click on "Volume (crypto_LUKS)" I am asked for the LUKS passphrase. This second step never works in KDE 4.2.4.

4. Look and feel: Faster, fancier, better.

Nevertheless I am back on Slackware64-13.0 -stable now, for the following reasons.



PRO -stable


1. Problem in -current with multilib setup
[EDIT: These probs are gone with newer version of the multilib stuff!]
After applying Alien Bob's excellent (!) patches and massconverting the 32-bit Slackware-current packages as described in the README, I found replacements for some files in /etc/rc.d. For example, there was an rc.hald.new next to rc.hald, but with a size of 0 bytes. And there was a new rc.inet1.conf, with a different size than the one that has been there before. Plus two or three more files with extension .new, either with 0 bytes or with a different size than the original file.
The result was an error message "can not start dbus; can you?" or so, when I tried to start KDE.
Replacing the existing files with the .new versions prevented my system from booting, the next time, even when I did it only with the Non-0-Byte files.
I am interested: Did anyone else observe this?
Here it is reproducable!

2. -stable is just that!
While currently the updates in -current wouldn't hurt, as they don't affect any core libraries, this will sooner or later change, and the likelihood that something essential will break will increase, at least in the weeks or months before the next stable release.
However, I want to make my 64-bit machine my main machine, now, because thanks to the latest updates to multilib support provided by Alien Bob, finally I can use the PCFAX functionality of my Brother MFC-290C, which was actually the last issue that prevented me from doing so. Now this works, and I don't want to take the risk of breaking anything relevant on my main machine.
I therefore decided to live with incomplete translations and the little inconvenience regarding LUKS encrypted USB hard disks, among a few other, minor snags, all cosmetic in nature.




CONCLUSION
I learned to like Slackware64-current mainly because of KDE 4.3.3 a lot, as all the (minor) problems I have in KDE 4.2.4 are solved, there. It only seems to conflict a bit with a multilib setup.
My hope now is, that we'll have to wait for 13.1 not nearly as long as we had to wait for a 64-bit version (which is so good in quality, that the long time of waiting was really worth it, of course) or 13.0. In fact, I think, the time for 13.1 could be now... or around Easter 2010. This would be much sooner than usual, and break the release rhythm everyone is used to, but the many improvements I have seen in KDE 4.3.3 would well justify such a decision, IMHO.

What do you think?

gargamel

Hi,

I really think that another stable release is imminent. If only for the problems with KDE for release 13. I've been working with the 2.6.32.rc3,rc5&rc7 kernels and feel the kernel will be a determining factor along with the KDE problems.

I've just upgraded to -current, first time I've done so in a few years and so far I'm really impressed, it's really stable.

If you can reproduce this with the versions of *-compat32 packages I currently have in http://slackware.org.uk/people/alien...re64-compat32/ - or build them yourself using the scripts in the compat32-tools package I'd certainly be interested.

What you describe was a bug in a much earlier version of the convertpkg-compat32 script which is part of the compat32-tools package. This bug should no longer appear if you use build "14alien" or later of that package (13 september 2009 or newer).

Eric

I have experienced this with a version I downloaded a week or so ago with the following command:

# lftp -c "open http://slackware.com/~alien/multilib/; mirror ."

So, apparently I somehow missed that the URL has changed in the meantime.

But I'll be happy to check it again, just give me a few days of time to get some important tasks done, first. I'll report back as soon as I have the opportunity to try it out, again.

gargamel

Your URL has identical content as the one I mentioned - they are both mirrors of my master site at home.

Make sure you do not use old versions. I just checked again - the dbus and hal "-compat32" packages on my site (and the mirrors) do not contain any rc.*.new files. Also, rc.inet1.conf.new is installed by the n/network-scripts package for which I do not have a "-compat32" version at all.

So, perhaps your issues are long gone, or stem from other packages than the "-compat32" packages.

Eric

Seems you are right, all along.

I removed everything from my previous downloads, then as root:

And guess what: All problems mentioned in my OP are gone!

I don't know why or how, but obviously I had indeed used some older version(s) of something, although I had downloaded the stuff only a few days ago... Hmmm. Doesn't really matter, it works just fine now!

Thanks again, Alien Bob!

gargamel

Makes sense!

gargamel