
AntiX 17, a Linux Distribution Without Systemd, Is Released - pwg
https://antixlinux.com/antix-17-released/
======
jchw
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.

~~~
dirkt
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.

------
dmcdm
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"?

~~~
nobodyorother
Essentially: [https://xkcd.com/1172/](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/](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.

~~~
nobodyorother
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)

------
Koshkin
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...

