Does current version of Slackware actually contain newest versions of software?
 

Hi All.

I want to replace Arch Linux with someting more "professional". I don't need stability but I want to have the latest versions of every software without manual building (so Gentoo is inappropriate in my case).

I researched Slackware web site and discovered that even "current" version of Slackware contains pretty old software (e.g. php-5.4.34 while Arch Linux supplied with 5.6.3, kernel 3.14.24 versus Arch's 3.17.4, etc).

So I think that Slackware-current is far from "rolling release".
Am I right?

Thanks

Yes you are right. It's more like Debian-Testing than Debian-Experimental.

In most cases, however, building your own packages of the latest software is easier on Slackware than on other distros. There's building, involved, yes, but the building usually consists of downloading the Slackware source directory, replacing the source tarball in that directory with the latest one, running the build script that's also in the source directory, and then upgrading to the resulting package.

slackware current is the work in progress of slackware. Eventually the changelog will announce a release candidate and after some of these, Pat will make that -current a new release which will be maintained with security fixes and -current will continue to develop towards the next release.

slackware-current can have some issues and may be broken at times and is not recommended for production boxes.

All that said, i usually run -current without issues. Of all the pre-release linux i have tried, it has remained the most stable one in existence.

If there is a piece of software in -current that is not the latest it likely falls into one of these three categories:
1. Pat and the team haven't had time to update it
2. Pat and the team didn't see a significant update worth the time to make the update
3. The software update would require significant updates to other bits, see category one.

Not all the software in -Current is always the most up-to-date, but more overly, the most up-to-date known stable packages.

Example: procps is unmaintained as a package, but is still used by Slackware, but procps-ng is the truly latest version. The same goes for ConsoleKit and ConsoleKit2.

Patrick's private repo which is rumored to be the legendary Slackware-experimental, aka Bob's Holy Happy Funland has never been seen by human eyes, well... so we've been told. Legend says one youngster tried to sneak in once, but the poor bloke was greeted by the wrath of Bob, and hasn't been seen since. The memorial service is the day before after two days ago. AlienBob and Robby have been rumored to have seen this mystical land of wonderment but were briefly driven mad and lost all memory of the incident.

I have a perfect example of this. I recently found out that the 3.18 kernel added GPU accelerated video decoding for my video card (an old ATI HD3870/r600 series). I knew this also required an updated mesa because there's been some patches that were submitted to help this along. I decided I wanted to upgrade 14.1 to utilize this, without completely moving to -current. Turns out, I ended up needing to recompile x, mesa, qt, llvm, and a few other programs. This, of course, I found out after several compilations failed because of dependencies or resulted in a screwed up a package (upgrading mesa without upgrading X left KDE unusable -- there were no titlebars on the applications and I couldn't gain focus of any window). After compiling X, I found that a few packages failed because of other dependencies. Altogether, I probably spent 3 days working on this (probably would be substantially faster on a more modern computer, but mine is an aging Athlon64 X2 6400+ with 8GB of RAM). For the most part, it wasn't difficult, I just took their slackbuild scripts and used them to build the newer versions (some required minor changes).

I am sure Pat and team have a better idea of what dependencies need to be updated when updating a major piece of software, but it is still a lot of work for a small team.

Also, they tend to go for "tried and true" pieces of software rather than the "latest and greatest". Latest and greatest can include unknown bugs and their stability is not yet proven. That being said, they don't always go with older versions. Of the programs that are typically up-to-date in current, they likely have a good record of providing stability with their latest releases. Of the 52 major packages that distrowatch tracks, Slackware contains 32 of them. Of those, 10 programs are up-to-date in -current (Thunderbird 31.3.0 is listed as a beta/development, but according to Mozilla's site, it is now stable). If you look at all the packages they track (219), Slackware contains 121 of them and 43 are up-to-date and 3 are development/beta versions.

http://distrowatch.com/table.php?distribution=slackware

If you want the latest and greatest, it's probably best to look somewhere else. If you're looking to sacrifice the bleeding edge for rock-solid stability, then you've come to the right place :)

On the other hand look at emacs:

24.4 release Monday, October 20: https://lists.gnu.org/archive/html/e.../msg00713.html
24.4 Slackware changelog entry Tuesday, October 21: http://www.slackware.com/changelog/c...php?cpu=x86_64

Not bad considering, IIRC, P.V. isn't even an emacs user.

IMHO this doesn't address the OP's requirements. In that case the update went quickly because it was a security fix, but not every software is updated in Slackware as soon as a new version is available. Slackware is not a rolling release, period.

Also, Slackware-current is irrelevant here, as it is sleeping several months after a release, and its content is only up to date between the first RC and the next release.

At the moment I'm running two Slackware64-current boxes and one Slackware-current box. It is true that not all of Slackware-current's software is bleeding edge. Slackware-current uses a sane approach when patching security flaws and providing up to date software while maintaining OS stability. Breakage will occur in Slackware-current, but, it is a rare occurrence.

It was? I don't see any CVEs for that time period or any note about that in the changelog. 24.4 was a major emacs release representing a year or two of work: http://www.emacswiki.org/emacs/EmacsReleaseDates It would be pretty weird to go from 24.3 to 24.4 thinking mainly of a security problem and not the many user visible changes and new features.
That point seemed answered adequately above (and in readily available Slackware documentation) which is why I didn't address it. I'm only attempting to muddy the waters and point out that Slackware packages aren't uniformly old. Plus I took the opportunity to give a tip of the hat to slackware to make up for my last LQ post which basically said that I'm only sticking with this until OpenBSD works on that machine.

No, you're right, I misread. This notwithstanding, showing one case doesn't set a rule. Quite the contrary actually, as you highlight that this software hadn't be updated for ages in Slackware ;)

Does kernel 3.18 brings improvements for an ATI Radeon 6670? And did you end up with a working mesa, X, etc?

The video decoding is for the HD3000/4000 series cards. For the others, there's DPM (Dynamic Power Management) tweaking, allowing for higher clocks on overclocked cards. There were also a few other thigns like concurrent buffer reads and userptr support. I don't think it's anything amazing, but I'm sure there will be benefits.

And I haven't installed it on my main machine yet due to having family in town last week, and building shelves in the garage this week, but everything seemed to work fine in a VM with the upgraded packages (somewhere just shy of 300 packages, although the majority of them are for X). I did all the builds and installation in one VM, then I created a new VM with a full Slackware64 14.1 install and took all those packages and did a mass upgradepkg *.txz. Everything seems to be working fine on it, however, it is using the vbox video driver and not the radeon, so the ultimate test will be when I do the upgrade on my main box. I just don't know when I'll find the time to do it, because I have to take into account the possibility of extra time to fix it if it breaks (it also serves as my media server, so I can't leave it broken and come back to it later). I'm hoping it will take less than 5 minutes to do the upgrade (upgrading the packages and then restarting the computer, although, I should only need to restart X), but I'm planning for a few hours, just in case something goes wrong.

I'm thinking I'll be able to get to it on Monday. When I do, I'll be updating my thread on it.

I remember a few months ago I tried recompiling mesa, X, etc and gaved up (I couldn't recompile mesa for some reason). I will take a look at your thread.

I upgraded to the latest mesa (I think it might be an RC, but I'm at work now and can't check) and I upgraded to the X included in -current. I think I needed a newer libdrm than the one in -current. Any packages I upgraded where done using a slackbuild to make sure they were compiled against my dependencies and not -current's. This also prevents having missing or mismatched dependencies, since it should hopefully kick out errors as I was compiling. The goal was to do this on a completely stock 14.1 to make sure I wasn't going to shoot myself in the foot.

Absolutly ...