Slashdot Mirror
Slackware 14.2 Released, Still Systemd-Free (slackware.com)
sombragris writes: Slackware, the oldest GNU/Linux distribution still in active maintenance, was released just minutes ago. Slackware is noted for being the most Unix-like of all Linux distributions. While sporting kernel 4.4.14 and GCC 5.3, other goodies include Perl 5.22.2, Python 2.7.11, Ruby 2.2.5, Subversion 1.9.4, git-2.9.0, mercurial-3.8.2, KDE 4.14.21 (KDE 4.14.3 with kdelibs-4.14.21) Xfce 4.12.1... and no systemd!
According to the ChangeLog: "The long development cycle (the Linux community has lately been living in "interesting times," as they say) is finally behind us, and we're proud to announce the release of Slackware 14.2. The new release brings many updates and modern tools, has switched from udev to eudev (no systemd), and adds well over a hundred new packages to the system. Thanks to the team, the upstream developers, the dedicated Slackware community, and everyone else who pitched in to help make this release a reality." Grab the ISOs at a mirror near you. Enjoy! The torrents page can be found here.
According to the ChangeLog: "The long development cycle (the Linux community has lately been living in "interesting times," as they say) is finally behind us, and we're proud to announce the release of Slackware 14.2. The new release brings many updates and modern tools, has switched from udev to eudev (no systemd), and adds well over a hundred new packages to the system. Thanks to the team, the upstream developers, the dedicated Slackware community, and everyone else who pitched in to help make this release a reality." Grab the ISOs at a mirror near you. Enjoy! The torrents page can be found here.
Now with Plasma 5! You can plug the stick into any machine, and it runs perfectly right out of the box, two monitors, weird audio, doesn't matter, everything works.
Once you go Slack, you never look back!
“He’s not deformed, he’s just drunk!”
Systemd isn't mentioned anywhere in the release notes or the website...
ChangeLog: http://www.slackware.com/chang...
Back in the day we switched to Yggdrasil because Slackware was slacking off on releases, and we needed new features.
// enjoy it if you want
/// please pick up any trash you make
//// lawn mower is right here, if you're in the mood
/ this is my lawn
Eudev is more or less a fork of udev before it was absorbed by systemd. In my dealings with it, it works exactly like how udev worked before the systemd developers hijacked the project so, I would imagine it was a trivial but necessary change for Slackware.
It will be interesting to see how long Slackware can resist systemd. Even venerable projects like LFS (Linux From Scratch) seem to be leaning towards its adoption. They still provide the non-systemd book as the default but, looking at the mailing lists, I'm not sure how long it will remain the default.
Definitely. Whenever I find deadlocks and race conditions in my code, I just sprinkle the code with sleep(1). PROBLEM SOLVED!
They might be opposed to systemd on a moral level but, they may not be able to avoid it on a technical level. As systemd absorbs more and more things, and more things start to depend on systemd, it's a simple problem of manpower: Unless your distro is run by a multi-billion dollar company that has the resources to undo the damage caused by systemd, you may have no choice but to adopt it.
It's interesting to think of systemd in terms of The Cathedral and Bazaar. RedHat built a really nice stall in the middle of the bazaar. Initially everyone loved it and it was very healthy for the bazaar. Then one day they looked around and realized that they owned considerable interests in all the surrounding stalls in the bazaar and decided, "You know what? We should just build a cathedral right here in the middle of the bazaar and bring all these stalls inside".
Slackware -does- use the standard init system. Everyone -else- has been making crazy things up and doing their own thing.
Couldn't be simpler:
open /etc/inittab
# These are the default runlevels in Slackware:
# 0 = halt
# 1 = single user mode
# 2 = unused (but configured the same as runlevel 3)
# 3 = multiuser mode (default Slackware runlevel)
# 4 = X11 with KDM/GDM/XDM (session managers)
# 5 = unused (but configured the same as runlevel 3)
# 6 = reboot
# Default runlevel. (Do not set to 0 or 6)
id:4:initdefault:
“He’s not deformed, he’s just drunk!”
I used to love Slackware. Timely releases, no dependency hell, and very simple package management.
There was never a problem with their package management...simple tgz files with an install script onsite, and there were multiple tiny 3rd party utils to manage versions and uninstalls. It really was great for being able to have a minimal system, know exactly what was on it, and just be able to understand it perfectly.
A couple of years ago, this changed. It was now not only recommended to do a full install, but support was not required UNLESS people did a full install, at least by most of the community.
This is frustrating. Slackware started out as being the most unix like Linux. Something it has clearly abandoned...when installing mplayer REQUIRES installing Samba, just in case you need to play a file across an SMB share.
They are not targeting the same audience, and instead are targeting the audience of distros like Ubuntu...except they won't ever win. I don't know what niche they serve anymore, aside from brand loyalists.
Arch seemed like a good replacement, but it is bleeding edge only. So, I've gone to the BSD side. I would love for Slackware to do a course correction, but that seems unlikely.
If you ignore ACs because they are anonymous - you're an idiot.
My main problem with systemd is the philosophy. If it was fully decouplable, then IMO it would be a fine piece of software.
It's also kind of suspicious that the only service manager that D-Bus talks to when it comes to D-Bus activation is systemd, leading to a malformed state in every other system that doesn't use systemd, because it starts services outside the service manager. That gentle push.
If the people behind systemd had any actual Unix-development skills, that is exactly what they would have done. Instead we have a monster that tries to assimilate everything. Huge egos often coincide with small skills. This is a nice example.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Most of large projects have essentially a zero percent chance of ever becoming dependant on systemd, because they are not actually dependant on Linux in the first place. The number of essential or otherwise even moderately important projects for Linux that are truly dependent on Linux itself is actually quite small, and even if every one of them forked, it is unlikely to become unmanageable, given the number of people that use Linux.
File under 'M' for 'Manic ranting'
Lennart is too young to have read "The Cathedral and Bazaar" when it came out. He comes from an MS Windows background so never knew the Bazaar idea existed and has no patience with people who try to suggest it does. That's why things like persistent user processes in the background (about chapter three in most scripting books) is just not something he sees as being something that should exist.
He says that: 1: it should be an easy admin task to enable-disable users ability to run such tasks since they are a security risk (eg. a lingering ssh connection out through the firewall can be reversed so it can be used to connect back into the system). 2. As default, only programs that explicitly have permissions (from PAM etc) to linger after logout should be allowed to do so.
So he has no problems with lingering processes, he just thinks they should be secure and easy to admin. No sane modern OS would ever implement the current Linux scheme with unrestricted ability for users to run arbitrary programs after logout (and even after the account have been locked).
bogus argument - this so-called security risk is also there when the user is logged in - you cannot really make security contingent on a user being logged in, because logged in means zip - user can be logged in a system for weeks w/o doing anything ..in reality LP redefines what it means to have a user account, and what it means to be logged in, arbitrarily limiting the user (and this *is* windows think), I mean next thing he figures out its a good idea for security to log user out at midnight, eventually figuring out he needs positive id checking user's ass is continuesly behind the terminal..)