Live data from Hacker News

Linux distros without systemd

ungleich.ch

331–340 of 449 posts

Re: Linux distros without systemd

#331

Earlier quoted context omitted.

Memory safety is not the alpha and omega of programming languages. People do not write million lines of code applications in bash, for a reason, trade-offs are to be made. That said I agree they should have picked Go instead /s.

> People do not write million lines of code applications in bash, for a reason, trade-offs are to be made. Isn't that basically what SysVinit and a good-sized chunk of the management tooling in Linux is? To their credit, Bash is a _weird_ language, but it's not going to corrupt memory when it crashes, and its failure modes are pretty well understood by the distro maintainers writing those scripts.

Those are all not million lines of code applications, but that only speaks in favor of a more traditional Unix userspace design. With modularity on the process level you don't need a million lines of code to herd services. Why an init system should a million lines of code is a mystery to me.

Re: Linux distros without systemd

#332

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 "would have" in this thread as a hypothetical situation where the option had been available.

Re: Linux distros without systemd

#333
post #176

Earlier quoted context omitted.

I haven't tried hg but from what I've seen one major advantage of git that gets under-acknowledged is its speed. Git is fast and fast really does matter for a version control system you use constantly. Is hg as fast as git?

Personally, I like pushing with hg, but I prefer pulling with git. An HgHub service at the scale of GitHub would probably result in massive end-user UX issues but maybe happier developers and repo administrators.

This reminds how pleasant it was to use hg as a git front-end (via an extention[0]) - compared to using the git cli. I think I'll have to revisit and see if that's still the case, and if I can make it work with feature branches etc.

Also looks like there's finally python3 support in the recent mercurial 5.0 release.

[0] https://hg-git.github.io/

Re: Linux distros without systemd

#334
post #15

Earlier quoted context omitted.

The objections to systemd are still as valid as ever. We still see a pretty high rate of security vulnerabilities in it. However, as projects adopt systemd-proprietary APIs, distros are forced to choose between maintaining ongoing forks of those projects, dropping those projects, or adopting systemd. E.g. I suspect Slackware only avoided being forced to adopt it because they'd already decided to not support gnome.

High rate? Compared to the Linux kernel, systemd's CVE rate is very low.

Compared to sysvinit, upstart, or procd, say, to remain in the same domain space?

(Though the implication that systemd is an OS Kernel is ... interesting.)

Re: Linux distros without systemd

#335

Earlier quoted context omitted.

> systemd monoculture As someone who really wanted the BSDs to get more credit ~20 years back, and spent a fair amount of time on various commercial Unixes as well, I find that phrase rather amusing. Historically poor standardization of the userland aside, GNU/Linux is the poster child for monoculture in Unix, and has left a whole lot of dead or dying software in its wake.

I've decided to migrate my Linux boxen to BSD (this is a long-haul project that will take me a year or more, I estimate). In part because systemD itself really made me aware of the issue that you're raising.

It's worth watching this[1] talk about systemd by a FreeBSD person, of all people.

1 - https://www.youtube.com/watch?v=o_AIw9bGogo

Re: Linux distros without systemd

#336
I maintain systems with and without. I thought I understood systemd, but I've given up trying to predict the behavior of systems running systemd.

The tragedy for me, is that I don't really like how the Init systems work, either. So there's really no one on my side. I seem to always fall into the trap of the Dreaded Centrist.

Re: Linux distros without systemd

#337

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…

I didn't mean that everything was in a single binary, but that everything is tightly coupled. Just because a binary is replaceable, doesn't mean the replacements that have existed for decades will be "drop in" or integrate as well, which leads to feeling like a second class citizen or the overhead originally mentioned.

I didn't mean single binary either.

I meant, that systemd solves some category of problems, that other tools didn't solve, didn't intend to solve and didn't even care for what the problems are. For distribution maintainers, systemd was something to welcome, that did address their problems.

So yes, there is no replacement (the requirement for it being drop-in only places the bar higher), because there's nothing else that scratches the same itch.

Re: Linux distros without systemd

#338
post #201
post #178

Earlier quoted context omitted.

By that standard SystemD proponents' fetishization of ineptly implemented change for change's sake clearly makes their position invalid.

Why on earth do systemd haters insist on capitalizing the D? It's really amazing how people think mistyping the name is some kind of useful or novel criticism of the software.

the -d suffix is traditionally for service daemons. SystemD is not a service daemon.

Lowercase is a UNIX convention. SystemD does not have a UNIX approach.

Since SystemD is not a Unix service daemon it shouldn't be spelled "systemd" to prevent confusion.

Re: Linux distros without systemd

#339
post #274

Earlier quoted context omitted.

Given the timeframe, something like OCaml would likely have been a better option.

Ocaml parallelism/concurrency story was not that good - but Haskell has just got its fancy new epoll based I/O manager (100000+ lightweight threads) around that time, with the 7.0.1 release (16 November 2010) They could have even take inspiration, imagine: typed, functional, monadic init files - "systemd: avoid success at all costs" :)

>Ocaml parallelism/concurrency story was not that good

OCaml concurrency is great, and Lwt [1] would be exactly what systemd need: run daemon and poll the answer concurrently.

Ada, C++ and D would have been another great choices.

[1] https://github.com/ocsigen/lwt

Re: Linux distros without systemd

#340

Earlier quoted context omitted.

Most of the problem I have it is with the imperialistic culture that came with it and with the serious security bugs that they keep sweeping under the rug. It is easier to configure and is convenient to have one holistic system in a lot of ways, but... They pushed for Gnome to have a hard dependency on it so that everyone would be _forced_ to use it instead of just letting it be accepted by merits. They have a track…

This is always the case with any new software. Things may get a bit worse before they get better. Honestly Systemd addresses the complexities of a modern system in the simplest fashion but no simpler, and that is the key. It is in the same spirit as launchd on macOS. It works well overall and end up being more portable and consistent in the long run. Hatred for it seems to come mostly out of dogma, something to be av…

> This is always the case with any new software. Things may get a bit worse before they get better.

So why should I currently opt for the worse solution? Is the overall design of it promising?

> Honestly Systemd addresses the complexities of a modern system in the simplest fashion but no simpler, and that is the key.

What complexities does it address? I lost track of everything an init system is apparently responsible for.

> It works well overall and end up being more portable and consistent in the long run.

Since systemd only runs on Linux APIs, I can't figure out what this even means. There are init systems that run perfectly fine in plain POSIX environments. systemd is not one of them.

Post reply on HN