Live data from Hacker News

Linux distros without systemd

ungleich.ch

261–270 of 449 posts

Re: Linux distros without systemd

#261
post #158

Earlier quoted context omitted.

It's good that systemd apologists have moved on from arguing that it isn't a single binary. But it is not a bunch of loosely coupled tools any more than it is "just" an init replacement.

Hmm. "Apologists." Couldn't be that it's been a lot better for me where I regularly interact with it and has been no worse where I don't. It's gotta be apologism . We have to be out to getcha . I think you owe me an apology for that one, dude. More productively: what parts of systemd's ecosystem--aside, apparently, from journald, but the above no-harm-no-foul reply to the sibling still applies as far as I'm concerned…

> It's gotta be apologism.

Apologists are engaging in apologia, which means a defense of one's ideas. It's not suggesting a hidden agenda, to the contrary, it suggests the agenda is fully on display since it's plain what is being defended.

Re: Linux distros without systemd

#262
post #8

I get no end of bemusement from open source advocates that think it makes any kind of rational sense to campaign against an open source project. THIS IS ALL OPEN SOURCE. Freedom and choice is the whole point, isn't it? If you prefer an alternative or forebear to systemd, that is great. Use it. Advocate for the system you prefer. Convince people that the choice you have made is better. Meanwhile the vast majority of d…

It's not SystemD itself that's the problem; it's just technically terrible, but, as you say, it's open source. A lot of open source software is terrible but popular.

It's Debian violating their social contract that was the problem for me.

What the vast majority of distributions do is irrelevant, a lot of them are chasing popularity or have a proprietary interest in having a "unified platform", but I had come to expect better from Debian. There is really no longer a "reality of that shift" to reflect on, since the SystemD problem has been more or less fixed: there are now debian-based distributions to upgrade to. If other people want to run that dumpsterfire of cowboycode on their computers, that's fine by me.

Re: Linux distros without systemd

#263
post #77

Earlier quoted context omitted.

It's not the init replacement part that bugs me. It's the expansion into audio, kernel logging, resolvers, containers, and so forth that is the issue. It's a monolith of sorts that breaks the loosely coupled toolbox concept of Unix.

Systemd is a bunch of loosely coupled tools, though; it's not a monolith at all. PulseAudio was written by Lennart but isn't part of systemd. You don't have to use systemd's resolver. systemd-nspawn is a completely separate process and isn't required for systemd as a whole. It's worth watching Benno Rice (a BSD developer, actually) discuss systemd and some of the misconceptions, some of which you're expressing, there…

"Systemd is a bunch of loosely coupled tools"

As just one example, the nspawn owning package requires a libnss package which pulls in systemd-resolve. I believe it also requires dbus.

Re: Linux distros without systemd

#264

Earlier quoted context omitted.

Come up with something demonstrably better then. Nobody is stopping you.

Why are you acting as if alternatives don't already exist?

"demonstrably better" ... there's a reason beyond entropy why a lot of distros decided to adopt SystemD. A talk linked to in another thread goes over a lot of this. TFA itself shows there are alternatives.

It's like arguing that KDE or Gnome shouldn't exist as options... nobody removed anyone's options. Don't like it, fork it.

Re: Linux distros without systemd

#265
I wish there were some way to favorite discussions on HN, not merely the article that started them -- if that feature existed, then this would be one of my favorite discussions on HN ever... why? Well, you have a ton of bright minds, who, for whatever reason(s), can't agree, yet each one adds some valuable piece of information to the debate.

Basically, where there's controversy (especially with bright minds) then there's always something there.

I hope that future system designers and historians will read and re-read these systemd controversies we are having in the present day... maybe we'll have some fundamental key piece of understanding then that we don't now, and based on it, everyone could agree... of course, then again, perhaps that would never happen...

Still, a lively, highly informative, interesting and thought-provoking discussion! A+ as far as discussions on HN go!

Re: Linux distros without systemd

#266

Earlier quoted context omitted.

You would have to write quite a bit of code... The success of systemd is in that it solves problems for distros that none other was solving (or even looking other way). If you want to successfully replace it, you have to solve the same problems, and do it better, so it would be worth replacing systemd. And because none other was doing it, you would have to write solution that does that. Slapping some bash scripts tog…

It's a very strange argument that I have seen previously that someone could write an alternative to systemd but haven't ergo systemd must be the best alternative. This is wholly and totally imaginary. Every part of system has an alternative because it is all solving existing problems that people have been solving for decades with a variety of tools. The only actual challenge is replacing just part of systemd while re…

> This is wholly and totally imaginary. Every part of system has an alternative because it is all solving existing problems that people have been solving for decades with a variety of tools.

Alternative doesn't mean 100% substitute both ways. The pre-systemd didn't go in their abstraction in the way, that systemd does - it is basically system-level, event handling machine. The events could be not only boot, but also hotplug, timer, socket connection or others, and their handling is configured by the system or admin in unified way, including unified way of adjusting system-supplied units. Other inits just ran scripts at some order the boot and that's it, ignoring, that something doesn't have to happen at boot, but at some other time.

That's one of the things, that systemd handles way better, than any suggested alternative. By ignoring where systemd is strong, you won't make the alternatives any better.

> The only actual challenge is replacing just part of systemd while retailing compatibility with the rest of it.

No. I don't see why we should have the Sisyphos task of maintaing sysv/cron/etc idiosyncrasies forever. Sometimes, it is better to get rid of the collected warts, and not limit the system to existing semantics.

Re: Linux distros without systemd

#267
SysV init had the ability to restart, allowing upgrades without rebooting. Can systemd do that?

The mechanism was kind of interesting:

SysV init would create socketpair, then fork. The parent (with PID 1, required for correct functionality) would then exec the new SysV init binary with an option specified to make it receive state over the socket. The child would supply that state, then exit.

Re: Linux distros without systemd

#268

Earlier quoted context omitted.

Rust would have been more appropriate. Something like SystemD at such a low level in terms of hardware and service management should not be done in a language with a garbage collector imho.

> Lennart Poettering and Kay Sievers started the project to develop systemd in 2010. https://en.wikipedia.org/wiki/Systemd#History > Mozilla began sponsoring the project in 2009[16] and a nnounced it in 2010. > The first numbered pre-alpha release of the Rust compiler occurred in January 2012. https://en.wikipedia.org/wiki/Rust_(programming_language)#Hi... Look, I like Rust and all, but are we really suggesting it fo…

I understand that... Go still isn't an appropriate language for SystemD, also, when did SystemD really take hold? Lots of projects will shift underlying options with time.

Re: Linux distros without systemd

#269

Earlier quoted context omitted.

Rust would have been more appropriate. Something like SystemD at such a low level in terms of hardware and service management should not be done in a language with a garbage collector imho.

systemd predates Rust by a bit over a year.

The point stands, Go isn't a good option for this type of process.

Re: Linux distros without systemd

#270

Earlier quoted context omitted.

I'm not such a lover of Go, but: non-sarcastically, Go may well have been a good choice.

> Lennart Poettering and Kay Sievers started the project to develop systemd in 2010. https://en.wikipedia.org/wiki/Systemd#History > Go was publicly announced in November 2009,[29] and version 1.0 was released in March 2012. https://en.wikipedia.org/wiki/Go_(programming_language)#Hist... The brand-new language that Google just announced last year was probably not considered a serious option here.

Ha yeah, I didn't mean "they really should have used Go", I just meant, "Go as it exists today may be a good thing to use for this".
Post reply on HN