Live data from Hacker News

Linux distros without systemd

ungleich.ch

441–449 of 449 posts

Re: Linux distros without systemd

#441

Earlier quoted context omitted.

> addresses the complexities of a modern system in the simplest fashion but no simpler I have a serious contention with the statement that systemd is the simplest possible solution for this problem. Especially since it involves not only service management, but user logins, a data bus, logging management, file system mounting, initd, and a host of other things. Are all of those pieces necessary? Arguably yes. But not…

Thing is, though, most of those things are different systems. systemd-logind systemd, systemd-udevd, and journald (and others) are different systems in the same project. They're a bit tied together (through dbus and I'm not sure what else), but that doesn't mean they're the same system.

The problem is that they're not really swappable. So, effectively it is all one system(d).

Re: Linux distros without systemd

#442
post #245

Earlier quoted context omitted.

I strongly agree that git has a UX issue, and the widespread adoption of it over mercurial is a perfect example of inertia leading us to get stuck in a local minima.

You probably mean local maxima.

I was referring to an etherial notion of "loss", which is why I said minima.

Re: Linux distros without systemd

#443
post #253

Earlier quoted context omitted.

This is out of the line. You were given civil arguments for why systemd requires Dbus but in your response, you accuse the other person of being a jerk and "big-timeing". Please use the strongest interpretation of other people's claims on the topic, before using them as a means to accuse them of wrongdoing.

That person is big-timing. Their tone ("you should read more" and so on) is in violation of the HN guidelines, filled with needless snark and condescension. The offending comment has been flagged by multiple users who agree that the comment doesn't meet community standards.

Perhaps the tone of JdeBP wasn't great, but they had a point. On the other hand, eropple's comment tone wasn't ideal either and they consistently miss the original point of systemd requiring dbus. Unfortunately, I am unable to check this since JdeBP post's have been censored.

Re: Linux distros without systemd

#444
post #228

Earlier quoted context omitted.

If you run or write that command into script without checking what DIR variable contains, the problem is in your lack of experience with shell, not the language choice. Also nowadays, rm itself has --preserve-root as default, so this won't delete your root fs.

By the same logic, if an app written in C has a security issue due to a null pointer or buffer overflow, the problem is clearly the coder's lack of experience with C.

Actually yes, because it is possible to write correct C, and because they could have chosen other language less conducive to those pitfalls. But your analogy doesn't hold, because in case of shell, the situation is different: the pitfalls are easy to avoid, and for unix admin tasks, there is no compelling alternative to shell.

Re: Linux distros without systemd

#445
post #228

Earlier quoted context omitted.

If you run or write that command into script without checking what DIR variable contains, the problem is in your lack of experience with shell, not the language choice. Also nowadays, rm itself has --preserve-root as default, so this won't delete your root fs.

This is true if you are running the GNU userland. It's not necessarily true with other userlands that are often run on top of Linux. In a discussion touching on systemd, it strikes me as a little surprising that somebody would rely on a quirk of another replaceable component. ;)

Checking for content of a variable before passing it to rm is a basic instinct that should be done in all shell scripts. The comment about --preserve-root is just a reminder that the problem of deleting / is very rare.

Re: Linux distros without systemd

#446
post #222

Earlier quoted context omitted.

> Users crying about Linux desktop all the time, but systemd has a huge part making the situation way better. Definitely. Maybe it's not great that GNOME has a hard dependency on systemd ( I personally don't care), but most people don't appreciate how much things have improved on the desktop with systemd.

I've been using linux since kernel 2.2. Deployed hundreds if not thousands of workstations for home users and developers. Trust me, I've seen desktop ups and downs, and I disagree. Systemd works until it doesn't, and then it's an unfixable lost cause and you reload it like a naughty 9x box.

Yeah, same for me. Since about 2.2. And I remember patching init.d scripts on Debian, adding sleep 5 In the network script, because you know our service had to have eth0 up and configured. So it's not like the old init system was perfect either :)

Or when I was building VM appliance with dB inside, and I was reading the news about systemd and how it would allow cpu and ram limits per service and thinking how if I had it it would save me from weeks worth of work (yes IBM DB2 is total crap when you run it in VM). and so on.

When I look back of all the stupid things I had to take care of and in systemd are just a config away, I can't help but wonder why people dislike it so much.

Re: Linux distros without systemd

#447
post #446

Earlier quoted context omitted.

I've been using linux since kernel 2.2. Deployed hundreds if not thousands of workstations for home users and developers. Trust me, I've seen desktop ups and downs, and I disagree. Systemd works until it doesn't, and then it's an unfixable lost cause and you reload it like a naughty 9x box.

Yeah, same for me. Since about 2.2. And I remember patching init.d scripts on Debian, adding sleep 5 In the network script, because you know our service had to have eth0 up and configured. So it's not like the old init system was perfect either :) Or when I was building VM appliance with dB inside, and I was reading the news about systemd and how it would allow cpu and ram limits per service and thinking how if I had…

You were able to do those hacks because it was open to you at run time. You COULD fix it. Now if it breaks and there's no fix, you may as well have used boxed software because your options are only to wait for a fix or find something else. Honestly, I'd have very little problem with systemd if it was not written in a compiled language. Losing that flexibility sucks.

In another comment I noted that this is obviously a divide between the hobbyists and the 9-5 linux users. I am both, so this is particularly sucky.

Re: Linux distros without systemd

#448
post #283

Earlier quoted context omitted.

Suppose you run your system on a new, better, and faster computer architecture, newly supported by Linux. Now, let’s assume that this is a new architechure which in many ways is different in style to other processors, but let’s say GCC supports it and can generate 100% correct code from it. Your problem now is that much of all the old software was written and tested only on older architectures, and this new architect…

The harder it is to avoid undefined behavior, the more I blame things other than the software. Especially when you can run the old version under emulation and it still works without bugs. And a lot of the blame goes to the distro that shipped a bunch of broken binaries.

> The harder it is to avoid undefined behavior

That is surely an aspect of the language, not the platform?

> And a lot of the blame goes to the distro that shipped a bunch of broken binaries.

Sure, I can see that. It is normally the case with new ports to new platforms to be in a state of unreadiness for quite a while. But this is not really relevant to the question of who to blame for the brokenness; the hardware platform or the software?

My analogy is that systemd merely exposed bugs in other software which had been there for ages (and only sporadically exposed). But then systemd comes along and expose a whole lot of them at once. Keeping with the analogy, some blame certainly goes to any disto which released this combination of systemd plus software which has bugs triggered by systemd, but still, is it reasonable to blame systemd in this case?

Re: Linux distros without systemd

#449

Earlier quoted context omitted.

I don't believe typical developers use "plain POSIX environments," whatever that's supposed to mean.

I'm not going to discuss the merits of portability or what "typical developers use". I'm questioning the idea that systemd is somehow more portable than its alternatives. That belief can only be rooted in plain ignorance of the actual situation. It has absolutely nothing to do with what typical developers use, and to that end your comment is a pointless derailment. What I mean is that there are init systems that only…

> What I mean is that there are init systems that only require POSIX compliant APIs

Those are irrelevant as they can't even do basic tasks like shutting down the computer or restarting it. Feel free to find a POSIX API for Linux' reboot syscall.

Some systems also require mounting additional filesystems, again not possible in a world limited to POSIX interfaces.

Sandboxing, SELinux, ...? Not in POSIX.

And so on.

Post reply on HN