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.
...that would be introduced in a major version change.
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)
Just wanted to say that. Multos annos!
Sincerely, great news.
Now, if it would just remove X11/Xorg completely and rely only in Wayland, it would be my dream distro :-)
(Dreaming is allowed, ain't it?)
PS: I grew writting the X11 config file manually in my long-dead first PC and grew really hating X11 (like when as child something makes you sick and, as adult, you eat it but don't like it).
Systemd isn't mentioned anywhere in the release notes or the website...
ChangeLog: http://www.slackware.com/chang...
I ordered the CD the DVD and a donation.
It looks like the real story here is they had to change from udev to eudev in order to keep it that way.
Wonder what the public key field is for?
All of you systemd haters are missing out on a fantastic piece of software. One of the things that I like the most about systemd is the wait timers. Nothing says good software design like a good uninterruptible wait timer.
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.
It will probably have whatever version of systemd is standard in 10 years or so when Pat deems it stable for inclusion.
Why, you ask? Because the Python devs are really bad about backwards compatibility, so there's a whole lot of people out there who can't upgrade the language without rewriting all their code.
Is still without as well. Always has been, and always will be. Plus you are not an island in an ocean of sysD penguins swimming around, circling.
Only if you think long waits on the order of "never" would qualify as interesting. It's my understanding that many of people who happen to have significant influence in the direction that Slackware takes are quite opposed to the idea of systemd's inclusion in Slackware, so if one wants an otherwise "slackware-like" system that uses systemd, it will have to be a fork.
File under 'M' for 'Manic ranting'
Oldest, sure... but behind? least developed? Where are you getting those ideas from?
File under 'M' for 'Manic ranting'
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.
Considering every single essential part of the operating system that systemd has "absorbed" so far has also been successfully forked, and a backwards compatible version of that does not depend on systemd is available, I'm not sure how much of a problem the picture you paint above is going to be.
File under 'M' for 'Manic ranting'
"Behind"? Look at the distrowatch packages table for Slackware and reconsider your position.
Like eudev and their struggle to keep Linux distros systemd free? Donate here: Gentoo
Their install instructions / help still talk about diskette one, two, etc. Very confusing to try and see what you would do to install today, 2016, from a DVD. I'm sure you don't insert the DVD and use 'dd' to move the image into some drive...
SystemD, so what. Their was a hue and cry when SCO moved from ye ancient tried and tested Unix boot, init and structure tree of SCO 3 to the "new" system 5. Today, that system 5, old init system is being replaced by something more modern. And one day, systemd will be replaced by something even slicker - and there will be hue and cry again.
Personally, I always picture it liuke this
Because Python 3 doesn't work (at least not with existing code). Python 3 is for all intents and purposes an entirely different language and why would any dev dump an existing/working codebase, experience and paradigms just because someone didn't think all that well about what a programming language needs in the past?
Custom electronics and digital signage for your business: www.evcircuits.com
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.
Slackware was the first distro I ever installed. Back in 1996 I managed to install it on a 486 DX 50. I had no clue what I was getting into and when I was finally able to startx, I ended up in TWM. I was like "huh?" I temporarily ditched Slackware and pursued other distros while immersing myself in research and learning. After flirtations with Turbo Linux and SUSE (YAST really got my attention), I had learned a lot and went back to Slackware. It was my go to distro for a very long time. On the one hand, I still call it my favorite distro. On the other hand, I haven't seriously used it in a very long time after it became cumbersome relative to all the newcomers that followed. Perhaps I will give this a spin.
As far as SystemD goes, I don't care one way or another. With SystemD (I know I will get down modded for this, but I'm still not posting AC) I can use every last utility I have ever used to scour init, and I don't mind parallel initialization. In fact I think it's pretty cool. So whatever. But yeah, Slackware is awesome.
Brought to you by Carl's Junior.
Sun still rises in the east. Film at 23:00
> 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.
*Maybe*. Along with several other distros, Gentoo Linux will continue to go to great lengths to make it possible to run without systemd. Indeed, its default sysvrc replacement is OpenRC and will remain OpenRC for the foreseeable future. Many of the core distro devs are openly critical of systemd for a variety of reasons. And -frankly- most people who know enough to have a even vaguely informed opinion about systemd can do without the Gnome DE.
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.
I don't think it's likely to be a problem, most systemd components are being replaced by non-systemd components (like ConsoleKit2, or elogind). No one seems really excited to depend heavily on systemd because of its limitations, so I expect systemd might remain nothing more than an init system into the future. It is ok as an init system, and doesn't prevent people from using other init systems, so I don't see a huge problem there.
"First they came for the slanderers and i said nothing."
Eh, Void Linux originally started with systemd but currently uses runit, so there's that option. And I've gotten OpenRC to run on Slackware, so that's another option if push comes to shove.
> Gentoo Linux will continue to go to great lengths to make it possible to run without systemd.
Actually I think it was Gentoo who forked udev to eudev, and IIRC they made a change or incorporated a patch for/from Slackware into eudev.
Will start my upgrade to 14.2 tomorrow, backing up now :)
posting as AC since I moderated some posts here
Indeed. And the good news is that there are now two larger distros that can can maintain eudev. Unless the systemd-cabal manages to get the kernel dependent on systemd (and that would be really bad for compatibility and security, so I doubt it is going to ever happen), it is actually not that hard to do a systemd-free (i.e. classical stable and reliable) Linux distro. You just have to maintain what is already there and works well, an idea that the systemd fanatics do not understand, of course. And applications that depend on systemd will be Linux-only anyways, which is not really smart, considering that there are a lot of Unix-like systems out there and in use.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
It is not that bad. 2to3 already does a pretty decent job of converting. Some manual work required after that, but a "different language" is just hyperbole.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Its like they are not even trying. Python 3.5 is perfectly okay.
http://michaelsmith.id.au
I wondered the same thing. I guess if all you ever deal with is ASCII, Python 2 is ok. But 3 makes it a lot easier to deal with non-ASCII Unicode, and as a linguist I have to deal with that every day. (Although I'll admit it's still not easy--I still feel like I have to stand on my head to open a Unicode file, even in 3.)
Forks require maintenance, though. If virtually every large project in the ecosystem has to be forked, the manpower required to support them all will be prohibitive.
Python 2 had full Unicode support, too. You had to be explicit about it (u'' literals etc), but it was there.
For the purposes of running random downloaded code, they are two different languages, in a sense that neither is a subset of the other, and so they're not compatible in either direction.
And so we have both of them, for the time being. I do not see a big problem.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
It has been almost 8 years since v3 was released, there is no excuse at this point. And it is not a different language; the changes are largely semantics and tools exist that facilitate code conversion.
Although I've been using it less and less for the past couple of years, Slackware remains my favorite Linux distribution. Ohter distributions simply became easier to install and maintain over the years. However, I'm considering moving back to Slackware, because that vile concoction called systemd is starting to infest every Linux distribution that is out there, with the exception of some of the more esoteric distributions. And truth be told, IMHO Slackware is the only "real" Linux distribution left.
The first Slackware version I installed was 3.2, I still have the CD box lying around somewhere. I got it from the father of a friend of mine and couldn't install it at home, because all I had was a very old 286 (yeah, it's lame I know; it did run Minix for a while though, that was fun too). Although that soon changed, I got permission at the university to use a PC in one of the project rooms to install and learn Linux. That was an interesting time for me. For a while I even walked around with a Linux installation on a very portable medium: a ZIP floppy (this was before ZIPSlack). While everyone was doing their programming excercises on Windows (or rather in a DOS box in Windows 95), I had full access to a development environment that I could take with me and simply insert into lab computer and work on them. And then, when I got home I could simply do the same and work on them some more. Those were interesting times!
And on the Eighth Day, Man created God.
Their website hasn't changed for... ever! Which is why people like it I guess...
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.
Attention all users of ecryptfs: Slackware 14.2 provides the Linux Kernel 4.4.14 which introduces a regression in ecryptfs. Encrypted directories - e.g. your encrypted home directory - are not accessible with this kernel. Also, the provided fixed ecryptfs module in the testing directory doesn't work. See http://www.linuxquestions.org/questions/slackware-14/can%27t-access-ecryptfs-with-kernel-4-4-14-a-4175583163/ï
Read more
Finally a sane comment.
Okay I'll have to eat some humble pie. I did a search on the links for systemd and nothing came up. I probably misspelt it.
Oh well modded appropriately :-)
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
Things don't depend on systemd. Things depend on functionality provided by a program that no other program provides. If systemd absorbs a critical part of the system (e.g. udev) then you can simply fork it and move on. If systemd provides some functionality on the other hand then it is up to the Linux community to do what it used to do best, rather than bitch and moan, get coding and provide an alternative to the required functionality.
There's no technical reason that everything will ultimately end up depending on systemd. Heck Debian has for years shown that there's not even a technical reason a Linux distribution depends on the Linux kernel itself. Systemd may be monolithic but it is still part of a modular OS.
If people care about systemd then the forks will be maintained. If they don't then I guess it turns out that the community isn't nearly as concerned about systemd as they have claimed.
Last time I checked the FreeBSD people was working on a systemd clone.
There may be plenty of people who care, but they might constitute the minority of the overall community, and therefore incapable of maintaining forks of the entire ecosystem of that larger community.
Or it might be that too many of those people who care, don't have the skills and/or the time necessary to maintain such forks.
They're way ahead of where many will be in 10 years when they're all stripping out systemd.
Il n'y a pas de Planet B.
Bloatware is for toy OS's.
...that would be introduced in a major version change.
Aka. The most aged.
UNIX systems also have a migration over time unfortunately for the most part UNIX was beat out by Linux. However MacOS X is a UNIX system. And Solaris was Turning to be more Linux like.
What we see as Real UNIX like is just out nostalgia for the old systems ignoring the modern trade offs that has happened to deal with today's computing demands.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
I've just started twiddling with xubuntu after years of windows exclusivity, I don't get why this systemd thing is in use if its so bad?
You mean in the same sense that a tablet PC is an iPad clone?
Oh, You mean like KDE and Gnome?
Or it might be, that they people who care are simple not yet organized enough and it just takes some time until this happens....
Since when did "Linux of old" ever "just work"? Back in the day, you had to recompile your kernel just to get sound to work!
Systemd's functionality as an init system isn't actually that bad - providing you don't need alternative control functions (such as the old "service reload") and providing it doesn't reduce a "boots-with-errors" system to "doesn't boot at all until all errors are fixed" system.
The huge problem came when it stopped being just an init system and swallowed up other, previously independent functions. And, most egregiously, converted the system logs from generically-processable text files to binary files.
Systemd is a lot like the Master Control Program from "Tron". Started out as a simple chess program, ended up as a tyrannical overlord.
Systemd was not a surprise. We've had systemd for years now and if people haven't organized forks by now, they're far too lazy to organize themselves in the future.
There may be plenty of people who care, but they might constitute the minority of the overall community, and therefore incapable of maintaining forks of the entire ecosystem of that larger community.
Or it might be that too many of those people who care, don't have the skills and/or the time necessary to maintain such forks.
Option 3. They just like bitching to hear their gums flap. In a world where you can roll your own linux distro, the bitching and moaning about systemd is pretty amusing. The loudest whiners claim to have great knowledge of systemd's shortcomings, so they should be able to roll their own, or at least choose a systemd free distro.
I choose option 3 as here is a systemd free slackware distro, and what are most of the posts? Whining about something that isn't even in the release.
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.
Lennart Poettering have been working strictly on open source Linux software ever since he graduated. He has at least +15 years developer experience on Linux. I have no idea why you think he has a MS Windows background. Did you just made it up?
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).
EUdev? Is there something for the UK too?
I think that the *bsd folks would have something to say about kde or gnome becoming irretrievably dependent on systemd.... don't you? My earlier point about forks remains.
File under 'M' for 'Manic ranting'
Exactly, they will avoid it until avoiding entails more effort than including it.
There is an old interview on LQ that talks about this: http://www.linuxquestions.org/....
I know, I used it for years that way. But it's easier in 3. And it wasn't that hard to switch over; most of the work was done by 2to3.py I did still have to fiddle with open(), though; it seems like opening a file in utf8 could have been made easier.
Debian, Fedora, and Redhat are not.
Similarly, with Tails you should use this version.
https://kat.cr/tails-1-4-1-i386-iso-multilang-tntvillage-t10922671.html
http://lsuzvpko6w6hzpnn.onion/tails-1-4-1-i386-iso-multilang-tntvillage-t10922671.html
http://i.imgur.com/QLGyQYf.jpg
Put it on a USB easily with this.
http://www.pendrivelinux.com/yumi-multiboot-usb-creator/
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..)
but they might constitute the minority of the overall community
Precisely what I was saying. Now the Slashdot prediction was that Linux will cease to exist, RedHat won't have a single user, and the singularity approaches and will kill us all. Reality may not turn out that way.
Linux has always been community built and community driven underneath. There are technical reasons why some distributions are going certain directions, but these very distributions spawned out of an interested community base.
So again, if this is the situation it was made out to be the forks will be maintained, if it wasn't then we'll all end up with systemd and the critics can go whinge about BSD.
don't have the skills and/or the time
Skills and or time do not give me a working Office suite. That's why I part with money and receive working software. The people on the other end of the deal make time for this as they receive the money. Opensource doesn't break down this dynamic. Even the computer illiterate can help against systemd if they wanted to. Go donate to the Devuan project or another project and make it worth their while to dedicate time and skills to something you find important.
not yet
I think we're on different timelines here. The topic is about future declines due to maintenance, not a question as to whether alternative projects are getting off the ground .... which they are.
KDE and Gnome do not become irretrievably dependent on systemd. They become dependent on a feature it provides or the API it exposes, like cgroups which is part of the Linux Kernel. There's no reason someone can't write something else to implement that functionality. Based on the number of people who say systemd is doing it wrong here on Slashdot, expect 5+ alternatives to every single API systemd exposes.
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.
Interesting that he created a whole new API for this functionality then.
Oh wait, unless it exists in the exact single implementation which you are used to then it doesn't really exist is that how it works?
Oldest, sure... but behind? least developed? Where are you getting those ideas from?
The changelog, and the previous changelog. Ancient versions of software, really really slow release cycles. To anyone used to standard distribution development behind and least developed describes it perfectly. The fact that Slackware released a version seems to have surprised many people.
I recommend trying out Void Linux as well. IMO, it's basically the lightweight foldable chair of Linux distributions. It's designed to work on small SoCs like the RPi, and it's also systemd free, although I think it's possible to replace runit with it. See chair analogy.
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..)
No, it is a real security problem; lingering processes have been used countless time to regain access to systems from the outside. Pre-systemd there wasn't even a good and reliable way to kill a (logouted) user's processes across servers (pkill was never a standard and it is unreliable since both broken and malicious programs can escape it).
Hyperbolic assertions about what LP might do are lame arguments. Besides timed logouts have been the order of the day for decades; I have never worked on a sensitive system that allowed the user to stay connected for weeks on end; it just too dangerous to allow that.
And don't forget that LP and the rest of the systemd developers really knows "user and session management" in Linux; they have practically invented and maintained all the core Linux software used for this like CK and logind.
Instead of abusing Unix signals like "nohup", lingering programs should just use PAM or similar to gain permission to run in their own scope; much better and much more granular security.
One of the reasons I stick with Slack is that unlike Debian I don't have to use ancient software versions with back ported patches. Who are these people you speak of? Do they have Internet or reading disabilities? distrowatch.com/dwres.php?firstlist=slackware&secondlist=ubuntu&firstversions=1&resource=compare-packages&secondversions=1
It seems reasonable to default to current locale encoding for files (and stdin/out/err), since it's what most other apps will do.
I can see the logic behind that, but it means that a program that works on one computer will not work the same on another computer, even when (IIRC) the input is coming from (or going to) a pipe, which means it has no necessary relation to whatever encoding someone's shell is set to. We've been bitten by that several times.
What I'm getting at is that I have to write code like this:
strMainFSTOut = codecs.getwriter('utf-8')(sys.stdout.buffer)
when it seems like
strMainFSTOut = open(sys.stdout, 'w', encoding='utf-8')
ought to be sufficient.
In the end it's a minor irritation: I can never remember the incantation when writing a new program, and have to go back to my old code. 3 is better than 2 was.
It's the same problem for pipes - if you are passing text around, the program on the other side of the pipe has to agree with you on the encoding, and the de facto standard for that is to use locale.
BTW, did you know that you can change the encoding of stdin/out/err specifically using PYTHONIOENCODING environment variable? Works for both 2.7 and 3.x, too.
But I have to make that assumption regardless of how file open() works; for me, it's just a question of how much code I have to write, whether I need to import the codecs library and call its functions, or whether that's done under the hood.
I know about the PYTHONIOENCODING variable, but I want to make my program self-contained. Not every computer I run on will have PYTHONIOENCODING set.
That's kind of my point. Systemd poses no risk to distros that want to remain systemd-free.
File under 'M' for 'Manic ranting'
There are subsets of C and Java (C++, ObjC, Kotlin, Scala) that are older than 8 years and also 'largely semantics and tools that facilitate code conversion' yet we still have plenty of code being written in plain old C or Java.
A programming language is primarily semantics, changing the semantics implicates that it is a different language regardless of the similarity, if it were the same language, things would largely still work (perhaps with deprecation warnings).
Custom electronics and digital signage for your business: www.evcircuits.com
FreeBSD is not opposed to the idea of SystemD, just opposed to its implementation.
Read his blog. You can see the mindset at work there. He just does not get this messy *nix thing and wants to "fix" Redhat's platform to make it like the "modern" MSDOS with a GUI under the control of a single entity that he is used to.
What do you base what appears to me to be an utterly ridiculous statement on? Do you not understand that even today there are tasks that take a very long time to solve with computers? With what appears to be a very limited understanding on your part at first glance, just so I can get an idea of what on earth you are going on about, what would you call an example of a "sane modern OS"?
He's very busy reinventing wheels poorly without properly understanding the previous implementation, sometimes not even on a newbie level because he just will not listen so remains a newbie.
No problem, we just have to rewrite a pile of scripts with his incredibly verbose new syntax, watch them run and silently fail, then just keep on changing bits and pieces until they work, for the moment, via the moving target black box of systemd.
Or we can just use old systems that work until Lennart sees the next shiny thing and another developer comes in to make the project stable.
Read his blog. The guy is an incompetent prick that is using RedHat and interproject politics to force us to use his toy instead of it being used on it's own merits.
This is a distro based on ubuntu 10.04, right?
I don't get it either, I find Slackware to sit perfectly in between the
conservative (RHEL, Centos, SuSE) and the bleeding edge (Arch, Fedora, OpenSUSE).
Although I wished they would have dropped the ESR version of Firefox.
I would add in that it seems to more rock solid than most distros. Also it seems to have a cleaner install as there is some software I use regularly that I have to build from source as well as the need libraries and on Slackware I don't have a big song and dance like I did the last time I tried Ubuntu. Add in that it doesn't treat me like a retarded baboon and it is a really good distro.
Time to offend someone
Your optimism is disturbing. My experience with Linux sound back in the days was that you had to recompile the kernel, re-compile the userland software, dick around with incomprehensible config files, update the entire distribution, bitch about it on Usenet groups, sacrifice a chicken on a Windows 95 CD-ROM at midnight under full moon....and then, maybe, just maybe, your sound works, when the stars are aligned correctly. I haven't used Linux in an environment with a sound card for well over a decade. I hope things are better now, especially since Windows 10 discs are harder to come by these days.
Don't take it as a joke. My system boots faster with Slackware than the OS(naming it won't be good) with systemd.