AntiX 17, a Linux Distribution Without Systemd, Is Released(antixlinux.com)
antixlinux.com
AntiX 17, a Linux Distribution Without Systemd, Is Released
https://antixlinux.com/antix-17-released/
3 comments
It's based on Debian, and the main problem with Debian and systemd is that systemd dependencies have spread everywhere, and it's really hard to install any systemd alternative without accidentally pulling in systemd, too.
I know because I tried to do that for quite some time before I had to give up, and switched to Devuan.
So if AntiX in any way similar to Devuan, you probably can use any of the init-alternatives you'd like.
I know because I tried to do that for quite some time before I had to give up, and switched to Devuan.
So if AntiX in any way similar to Devuan, you probably can use any of the init-alternatives you'd like.
Can someone summarize why one would particularly want a distro which lacks sysyemd? I failed to find thier reasoning in the About / FAQ and don't know enough to understand the rationale on my own. Not to bait a response, but is this just another example of how when a fundamental and broad change is introduced into any sufficiently large software community, some small subset of the community inevitably takes issue and proceeds to fork and maintain a release where they can continue doing things "the old way"?
Essentially: https://xkcd.com/1172/
It's great that they're making systemd, but if it doesn't work for you, it won't. (Rephrasing a Github bug I read a while back) systemd seems set on replacing the existing software stack with software that works for its creators, without regard to established historical standards of behavior.
For example (in the GH bug), folks using systemd for networking can't necessarily connect to intranet sites, because systemd doesn't keep historical behavior: it doesn't try all the DNS servers you've provided for each request. Instead, it always connects to whichever DNS server hasn't failed most recently. That's faster, that's good.
If you needed systemd to connect to your local DNS server to resolve intranet names like http://myreports/, and 8.8.8.8 to resolve external names, that would work fine... Until the local server took too long to respond to one request. Then, all future DNS requests would go to 8.8.8.8, effectively blackholing your intranet. That's broken, that's bad.
The resolution supplied in that bug, IIRC, was users shouldn't do it that way. So, the resolution appeared to be that the user should've been hired as the network administrator instead of their current job. Maybe it's been fixed some other way since then? Please correct me if so!
Sure, systemd might be faster, but faster isn't better than working-as-expected.
It's great that they're making systemd, but if it doesn't work for you, it won't. (Rephrasing a Github bug I read a while back) systemd seems set on replacing the existing software stack with software that works for its creators, without regard to established historical standards of behavior.
For example (in the GH bug), folks using systemd for networking can't necessarily connect to intranet sites, because systemd doesn't keep historical behavior: it doesn't try all the DNS servers you've provided for each request. Instead, it always connects to whichever DNS server hasn't failed most recently. That's faster, that's good.
If you needed systemd to connect to your local DNS server to resolve intranet names like http://myreports/, and 8.8.8.8 to resolve external names, that would work fine... Until the local server took too long to respond to one request. Then, all future DNS requests would go to 8.8.8.8, effectively blackholing your intranet. That's broken, that's bad.
The resolution supplied in that bug, IIRC, was users shouldn't do it that way. So, the resolution appeared to be that the user should've been hired as the network administrator instead of their current job. Maybe it's been fixed some other way since then? Please correct me if so!
Sure, systemd might be faster, but faster isn't better than working-as-expected.
Found the bug! Seems like the new behavior is non-compromisable, but keszybz and pottering both put forward potential solutions that leave everybody happy(?), but that haven't been acted on since July. So, there was some compromise between the requestors and developers, just not in the places I expected to find it in the bug report.
https://github.com/systemd/systemd/issues/5755
https://github.com/systemd/systemd/issues/5755
Yes, people should not do it that way; and that has been true for far longer than systemd has even been an idea.
* http://jdebp.eu./FGA/dns-client-all-proxies-must-provide-sam...
* https://news.ycombinator.com/item?id=15228940
* http://jdebp.eu./FGA/dns-client-all-proxies-must-provide-sam...
* https://news.ycombinator.com/item?id=15228940
That reminds me of a Windows 2000 bug, when there were issues connecting to DNS servers, the search order would be switched, and depending on the overall intranet configuration, the order really mattered.
I don't think most people want to hold back progress, but it is alarming how difficult it is to remove systemd from modern Linux stacks. We went from having a choice of many init systems to virtually no choice at all.
To me it seems like a repeat of X11: many proprietary interfaces to a complicated blackbox that handles nearly an operating system's worth of functionality. I'm not pro-UNIX-way or any kind of purist, but I've seen how this pans out before and it seems unlikely to work out well in the long-term future.
My preferred future is one where the protocols for communicating with an init system are open, efficient, and replaceable. libc defines a standard interface between user space and kernel mode (...sort of, anyways) and I want to see similar stuff for various parts of the system, like controlling power or authenticating sessions and so forth.
To me it seems like a repeat of X11: many proprietary interfaces to a complicated blackbox that handles nearly an operating system's worth of functionality. I'm not pro-UNIX-way or any kind of purist, but I've seen how this pans out before and it seems unlikely to work out well in the long-term future.
My preferred future is one where the protocols for communicating with an init system are open, efficient, and replaceable. libc defines a standard interface between user space and kernel mode (...sort of, anyways) and I want to see similar stuff for various parts of the system, like controlling power or authenticating sessions and so forth.
The issue is what is "the old way", when all proprietary UNIXes moved into systemd like init systems, before systemd started to be an issue on Linux land?
Then again, I guess many would be happy to just get one of those green phosphor UNIX terminals I was using back in the university days.
Then again, I guess many would be happy to just get one of those green phosphor UNIX terminals I was using back in the university days.
The main issue I have heard is when something goes wrong it's very very difficult to find the cause. There are legitimate issues with systemd and it's not hard to find some good writeups on the technical (and design) objections.
It's not just people resisting change.
It's not just people resisting change.
its definitely flame bait, the "why" of systemd. On a personal note, I prefer a simpler init system. Its also worth adding, again, personally, I find the increasing of non init system functionality dependent on some aspect systemd worrying.
The init system seems fine, its all the cruft rapidly attaching to it. Case in point: Breaking sighup behavior and killing processing aggressively because GNOME was too buggy to close out normally. And yes, I'm aware there's currently a toggle switch for the behavior.
interesting. wasn't aware of the breaking of sighup behavior. thanks for the comment
But how many of us should care? Why is it such a hot topic? I for one will stick with Slackware even when (if) it switches to systemd...
Of course, this is all principles; in practice I'm happy running Arch with systemd because 'it works' - but like many others, I'd prefer if we developed things such that it won't take years of effort to move onto the next big thing, or worse, end up like X11 where it's nearly impossible to.