They seem to neglect to mention what they're using as an init system. I'm glad people are making some alternatives to the Poettering stack and everything, but I actually would prefer it to not just be traditional init. Something with less lock-in like Upstart would be nice.
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.
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.
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"?
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.
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.
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.
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.
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.
[+] [-] jchw|8 years ago|reply
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.
[+] [-] dirkt|8 years ago|reply
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.
[+] [-] dmcdm|8 years ago|reply
[+] [-] nobodyorother|8 years ago|reply
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.
[+] [-] jchw|8 years ago|reply
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.
[+] [-] pjmlp|8 years ago|reply
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.
[+] [-] jjrh|8 years ago|reply
It's not just people resisting change.
[+] [-] dtornabene|8 years ago|reply
[+] [-] Koshkin|8 years ago|reply