Live data from Hacker News

Why systemd?

blog.jorgenschaefer.de

221–230 of 263 posts

Re: Why systemd?

#221
post #201

Earlier quoted context omitted.

Getting tired over all the systemd hate. If you don't like it, don't use it. Instead of complaining and making useless-by-design wrappers and/or dumbed-down-versions, why not focus your efforts on making a new better init system and convincing people they should use it instead. systemd isn't final - it's software, and will come and go. Not to mention, most of the systemd hate seems to be spread by only two main sourc…

To avoid using systemd in practice basically means switching distributions, or switching away from Linux entirely. Depending on your setup, this may be far from trivial. I think systemd has a lot going for it, and it's been pretty stable on my Arch notebook, but I'm not too thrilled with the way it takes over so many tasks at once and eschews text log files. What's frustrating is that I didn't have much choice in the…

> but since Red Hat, Suse, and now Debian and Ubuntu are switching to systemd

With so many heavyweight linux enterprise companies jumping on systemd, one must wonder what consideration they have given the issue? I'd wager, a lot. Also, note that systemd is really designed with servers in mind, so it's not surprising for a desktop/laptop distro user to find it bothersome (it wasn't designed with your use-case in mind). With that said, the beauty of Arch is you can yank systemd out and go with whatever init system you desire.

Re: Why systemd?

#222

Out of confused mind.) There is no fundamental problem that it "solves" which other UNIXes presumably still does have. The problem does not exist. AIX, Solaris, *BSD and many old-school Linux guys will tell you that. Also, any old-school guy will tell you that a kitchen-sink, put-it-all-in design is a wrong way. btw, user processes supervision is a task of an OS kernel, which it handles via a bunch of specialized sys…

Solaris guys certainly wouldn't tell you that, unless they haven't used Solaris in the last decade. Since Solaris 10 (2005), it has a unified process supervision and init system, with declarative config files, dependency boot, and all that other good stuff that's just now coming to Linux. It's part of the Service Management Facility (SMF), which replaced the old init-script-based system. The Illumos distributions all…

Please tell us about these improvements over shell init scripts.

Let's say a have a program to run - nginx - very popular program. Tell us, please, what improvements the good stuff gives me?

BTW, in my opinion, the SMF has been written "because we can" (use XML for configs and Java for its processing) not because shell init scripts has been broken. There are many strange reasons why some programs were written or has been adopted.

Re: Why systemd?

#223
post #201

Earlier quoted context omitted.

Getting tired over all the systemd hate. If you don't like it, don't use it. Instead of complaining and making useless-by-design wrappers and/or dumbed-down-versions, why not focus your efforts on making a new better init system and convincing people they should use it instead. systemd isn't final - it's software, and will come and go. Not to mention, most of the systemd hate seems to be spread by only two main sourc…

The "new better init system" already exists. Several of them, in fact. The only difference? They have no intention of engaging in any shady realpolitik, or consolidating functionality unrelated to their core purpose. Jupiter Broadcasting are an unreliable source, to say the least. I did watch that episode. When you use such pristine arguments as "Someone reimplemented systemd's D-Bus APIs, therefore systemd is portab…

Quite frankly, if this is the attitude one can expect from the uselessd developers... then I think this conversation is moot.

If a truly better init system already exists, then people who care strongly and/or have very specific use-cases where that init system excels exceptionally, then they will use it. Nobody is married to systemd.

One must also look at how many industry heavyweights are behind systemd now (even Canonical). I'm certain they have considered the pros and cons to systemd much more extensively than all of the armchair quarterbacks appearing in this thread. Perhaps you personally dislike systemd for what you think are good reasons, but know you are in the minority now (you weren't always).

Bottom line -- systemd is targeting servers, everything else is tertiary. Don't like it, then don't use it. But quit using every possible chance to spread needless hate. systemd is not an assault on you personally. No matter how loud you scream -- systemd is not going anywhere for the time being.

Re: Why systemd?

#224
post #215
post #206

Earlier quoted context omitted.

http://0pointer.de/blog/projects/the-biggest-myths.html "That is simply not true. Porting systemd to other kernel is not feasible. We just use too many Linux-specific interfaces. For a few one might find replacements on other kernels, some features one might want to turn off, but for most this is nor really possible. Here's a small, very incomprehensive list: cgroups, fanotify, umount2(), /proc/self/mountinfo (includ…

I guess uselessd is fundamentally impossible then, along with other systems that provide the same functionality. Again, if it were impossible there wouldn't need to be a policy against it.

IS uselessd possible? From its own docs[1]:

"uselessd is planned to work as a primitive stage 2 init (process manager) on FreeBSD. Stage 1 is inherently unportable requires a total overhaul in regards to low-level system logic (with systemd assuming lots of mount points and virtual file systems that aren’t present, is designed with an initramfs in mind and many other things). Stage 3 can always be achieved by having a sloppy shim around the standard tools like shutdown, halt, poweroff, etc.

So far, uselessd compiles on BSD libc with a kiloton of warnings, with lots of gaps and comments in the code, and macros/substitutions in other places. All in all, it is an eldritch abomination. A slightly patched version of Canonical’s systemd-shim is provided and works well enough to emulate the org.freedesktop.systemd1 D-Bus interface. Some of the binaries provide diagnostic information, but at present we are trying to find ways to bring up the Manager interface in the whole buggy affair, in order for systemctl to send method calls. Nonetheless, you are absolutely welcome and encouraged to play around with it in its present state, and we hope to get somewhere eventually."

1) http://uselessd.darknedgy.net/

Re: Why systemd?

#225
post #197
post #162

Earlier quoted context omitted.

It doesn't address the logging issue, as far as I can tell. It appears to rely on the same logging solution as the original daemontools. I used daemontools extensively for a while, and it was great, and I like Bernsteins design philosophy which appears to have been largely carried forwards into s6, but it was simplistic, and suffers from a number of the same problems as a "raw" SysV-init, such as putting us back at t…

People actually _want_ the logging behavior of systemd? My impression is that it's the most widely hated part; I've heard endless stories of journald thrashing the filesystem forever, losing logs completely on corruption, etc. And even operating properly, its performance is comparable to grepping a flat text log, since despite having a "more efficient" format, it increased the actual data size by something like 4-10x…

Also coredumps don't really belong into the journal, I'd turn that off.

Re: Why systemd?

#226
post #167

Earlier quoted context omitted.

Also you depend every-day on another process that is special in some sense just as the process manager: Xorg. If Xorg dies all your desktop applications die. By your line of reasoning Xorg should be moved into PID 1 too, which is definetely not a good idea. I don't say that Xorg hasn't crashed, it did rarely when running RC code or proprietary drivers. In fact I probably had as many Xorg crashes as kernel panics, whi…

I don't understand how you come to the conclusion that putting Xorg in pid 1 would be even a remotely fitting comparison. For starters, as an example, I have 100 times as many servers than I have desktops to deal with - for a lot of us Xorg is not an important factor. But the process manager is vital to all of them - server and desktop alike if you want to keep them running. If the process manager fails, it doesn't m…

I think you raised an interesting point here 'for a lot of us Xorg is not an important factor', I agree. The same could be said about some of the features that systemd provides that cause a lot of flames (binary logs). It has been said before that systemd is monolithic, and this is probably what makes switching so hard.

It is all-or-nothing, whereas if you could gradually replace the old sysvinit/policykit/consolekit/etc. stuff with systemd/logind then problems during that transition could be debugged more easily. You could also choose to not replace some components where the systemd/non-systemd replacement is broken.

Re: Why systemd?

#227
post #221

Earlier quoted context omitted.

To avoid using systemd in practice basically means switching distributions, or switching away from Linux entirely. Depending on your setup, this may be far from trivial. I think systemd has a lot going for it, and it's been pretty stable on my Arch notebook, but I'm not too thrilled with the way it takes over so many tasks at once and eschews text log files. What's frustrating is that I didn't have much choice in the…

> but since Red Hat, Suse, and now Debian and Ubuntu are switching to systemd With so many heavyweight linux enterprise companies jumping on systemd, one must wonder what consideration they have given the issue? I'd wager, a lot. Also, note that systemd is really designed with servers in mind, so it's not surprising for a desktop/laptop distro user to find it bothersome (it wasn't designed with your use-case in mind)…

systemd is designed for all use cases in mind. I have yet to see any sentiment that it's specifically for servers, desktops or embedded. Lennart's "Biggest Myths" would have your statement decried as an utter falsehood.

Re: Why systemd?

#228
post #223

Earlier quoted context omitted.

The "new better init system" already exists. Several of them, in fact. The only difference? They have no intention of engaging in any shady realpolitik, or consolidating functionality unrelated to their core purpose. Jupiter Broadcasting are an unreliable source, to say the least. I did watch that episode. When you use such pristine arguments as "Someone reimplemented systemd's D-Bus APIs, therefore systemd is portab…

Quite frankly, if this is the attitude one can expect from the uselessd developers... then I think this conversation is moot. If a truly better init system already exists, then people who care strongly and/or have very specific use-cases where that init system excels exceptionally, then they will use it. Nobody is married to systemd. One must also look at how many industry heavyweights are behind systemd now (even Ca…

You're not even addressing any argument against systemd at all. You're just presenting a consolation:

"Hey, everybody, look at all the people using systemd! They must know better than you, so shut the fuck up and use whatever you want - no one is stopping you! By the way, systemd is meant for servers, even though the developers have never said anything like that and have made it clear that it's meant for all use cases."

In this regard, you are little more than a troll. Or a person who thinks popularity means quality. Both, even.

Re: Why systemd?

#229
post #220

Earlier quoted context omitted.

For me Linux is pretty dead already because I can't entirely trust the direct it's going in having survived the Unix wars of the 1990s. There are so many parallels to that at the moment, it's not funny. There are large vendors pulling it in separate directions (Canonical, Redhat, Google). At the end of the day, much like back then, customers will suffer from terrible support, fragmentation and political battles. I ju…

"There are large vendors pulling it in separate directions (Canonical, Redhat, Google)." It's pretty clear how that's going to shake out, isn't it? Google is pretty much a non-issue here; yes, Android and ChromeOS use a Linux kernel base, but they have no impact on any mainline distros, and there's no indication Google wants them to. So it reduces down to two parties fighting for control: Canonical and Red Hat. And R…

Yes and RedHat is IBM circa 1997 and Canonical is HP circa 1997. The Sun of 1997 is Oracle (again).

Creeping up on their arses is Microsoft (again) with Azure and incredibly cheap commercial offerings.

Re: Why systemd?

#230
post #201

Earlier quoted context omitted.

> The author of this piece makes the classic mistake > of equating the init system as the process manager > and process supervisor. I think it is a bit more subtle than that. The author makes the mistake of inferring an architecture from observed behavior and fails to ascertain where the warts come from, the architecture or the implementation. They aren't the only one, its a common problem. The result though is kind…

Getting tired over all the systemd hate. If you don't like it, don't use it. Instead of complaining and making useless-by-design wrappers and/or dumbed-down-versions, why not focus your efforts on making a new better init system and convincing people they should use it instead. systemd isn't final - it's software, and will come and go. Not to mention, most of the systemd hate seems to be spread by only two main sourc…

I realize you were speaking in generalities but to be specific I don't hate systemd. I do dislike "emergent" architectures but that is more of a OCD systems analysis curse I have to deal with.

This statement, "systemd isn't final - it's software, and will come and go.", is the one that most captures my angst. And you can replace 'systemd' with 'linux' or 'gstreamer' or 'webkit' or 'gcc' or 'fsck' for that matter. Not only are they not 'final' but what they would be able to do if they were 'final' is left unspecified. That puts the system on the DAG equivalent of a drunken walk. And users don't seem to like it when their systems are evolving randomly.

I really enjoyed the early RFC process of the IETF because we could argue over what was and was not the responsibility for a protocol, what it had to do and what was optional, and what it would achieve when it was 'done.' Then people compared what they had coded up. When the architecture is the code and the code is the spec, my experience is that sometimes we lose track of where it was we were going in the first place.

Post reply on HN