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!”
One of the very first Linux distribution is still alive and kicking (without systemd!).
Great work Patrick & crew, I'll make sure I'll order a DVD soon!
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
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!
Oldest, sure... but behind? least developed? Where are you getting those ideas from?
File under 'M' for 'Manic ranting'
lol
The first test in our automated testing process (which reviews every pull request before it's merged) is to test for "sleep"... we completely disallow it to be used... ever!
How did it get this way? Well, I'm sad to say that it was actually my fault. I have a habit when I'm debugging particularly tricky MPI code (we do massively parallel scientific simulation) to use "sleep(pid)" where "pid" is the "processor ID" or "rank" of the current MPI process. I use it to "serialize" print statements so they don't clobber each other. There are definitely other ways to achieve the same thing... but this is quick and dirty while I'm developing.
Unfortunately... I accidentally checked in code with these a couple of times. Running in serial (1 processor) it only causes a 1 second slowdown... but if you're running on 10,000 processors... well... you're going to be waiting a while!
Since it happened twice, "sleep" got the perma-ban by our devs (to save themselves from me!).
Anyway - a little off-topic... let me try to pull it back on topic. Slack was the first distro I ever loaded back in the 90s. I downloaded it to several (20ish?) 3.5" disks at my job (after school job doing tech support at a local ISP)... got them all home and tried to install it and guess what? Yep. One of those disks was corrupted. Took two more tries before I was able to get it going... but my mind was permanently BLOWN once I got it working :-)
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!”
FreeBSD works just fine without systemd. There is no reason for systemd to exist on a unix environment, GUI or anywhere else. This is where Unix's security is it's strength. Not in a clusterfuck of their code.
But I will definitely give slack another look. I miss my "just works" Linux of old.
"Suppose you were an idiot...and suppose you were a member of Congress...but I repeat myself." Mark Twain
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.
Not for RedHat. Say goodbye to the workstation market and all science and engineering software on a platform that has thrown X away and doesn't let users run scripts for days at a time without killing them off.
It's worth noting that the only people with a clue about what Wayland actually does that are pushing Wayland are ones working in the phone and tablet spaces. Nice for them - sucks for the rest of us yet people keep on trying to shove it down our throats.
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..)