Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What “technical” concerns do I have with systemd?

blog.lusis.org

Post reply on HN
Print view View original

41–50 of 102 posts

Re: What “technical” concerns do I have with systemd?

#41

Post by VLM »

sp332 wrote: post #21
copper_rose wrote: post #9

He's hit the nail on the head - systemd's fundamental design is not appropriate for the server environment: "I have to provide a system that runs reliably and can easily be reasoned about and yet I have to build it on distributions created by people who consider how long it takes to get to the fucking GDM login screen and if shutting the laptop lid will cause the system to hibernate properly or not."

Why do you "have to" build it on those distros? Why not use a server distro that doesn't even have X let alone GDM?

The idea that you should artificially separate OS into server and desktop, solely so you can charge more for the license for server OS, is a false dichotomy that needs to go away and only exists in proprietary commercial OS. It exists solely in the marketing sphere, and only intersects with the technical sphere WRT including artificial limits to ruin performance on a system that has a workload marketing doesn't approve of.

I do not want parallel non-deterministic booting on a server. If it works I don't care because I don't reboot daily/hourly/for fun. Its a linux box not Windows. If it doesn't work then non-deterministic behavior makes race conditions and error messages very confusing.

There is an inherent architectural / philosophical violation where flexibility is considered "unix"ish yet it is forbidden under systemd domination. If you disagree with the above paragraph for init system on a server, thats OK, I think someone with that has the wrong opinion but I respect an honest disagreement. Under a unix-ish philosophy there have been about ten alt-inits over the past couple decades that'll parallel / non-deterministic init, so go ahead friend, more power to you, give one a try until your fingers get burnt. Sysvinit (or BSDs init) will be waiting for you when you return. This flexibility, this compatibility, is philosophically forbidden under systemd.

You will do it the systemd way, because we won the political battle, not for technical reasons (god knows systemd is not the first attempt at this architecture). Or you will be forced to leave. Well OK then. The future is looking very freebsd to me. So long and thanks for all the fish!

Re: What “technical” concerns do I have with systemd?

#42

Post by zarvox »

e7620 wrote: post #37
the_mitsuhiko wrote: post #14

Earlier quoted context omitted.

> He's hit the nail on the head - systemd's fundamental design is not appropriate for the server environment: [Citation needed] From where I stand, systemd is what I always wanted on a server.

What feature of systemd did you always wanted on a server?

I'm in the same boat - I wind up in a situation where I find myself missing the features, stability, coherance, and integration of systemd at least once a week in my day job, where we currently use Ubuntu with upstart.

For me, it's a combination of things:

1. Proper dependency management, where I specify dependencies as they are, rather than flattening the dependency graph.

2. Proper service supervision. I've had upstart lose track of running processes, which is silly - you had one job!

3. Ability to decouple the init system's view of "process is running" from "process is ready/live". This is nice if you want to await liveness by letting the system supervisor tell you if the service is live or not, rather than writing a bunch of external scripts or checks.

4. A single place to modify the way system services are run, and unified config for e.g. resource limits, and tools for working with them.

5. Simple exploration and interleaving of logs from various communicating services via journalctl, which is insanely helpful for debugging things in a distributed system. You can see the calls come in from the network and bounce between services, and see exactly where something goes wrong. You could do this with other solutions, but I get this out of the box with journalctl, and I can look in more detail at any of the services, or when I'm checking a service's status.

It's true that many of these things could perhaps have been done in other ways, but the fact is that the systemd developers did the work to make it happen and now I can focus on my product, rather than on learning a bazillion pieces of plumbing to enable me to ship product. I'm fine adapting a few things to run via unit files instead of shell scripts if it means I can ship more correct and more reliable product in less time.

Re: What “technical” concerns do I have with systemd?

#43

Post by vezzy-fnord »

zarvox wrote: post #42
e7620 wrote: post #37

Earlier quoted context omitted.

What feature of systemd did you always wanted on a server?

I'm in the same boat - I wind up in a situation where I find myself missing the features, stability, coherance, and integration of systemd at least once a week in my day job, where we currently use Ubuntu with upstart. For me, it's a combination of things: 1. Proper dependency management, where I specify dependencies as they are, rather than flattening the dependency graph. 2. Proper service supervision. I've had ups…

Have you considered running something like monit, alongside Upstart?

Re: What “technical” concerns do I have with systemd?

#44

Post by teacup50 »

gh02t wrote: post #36
teacup50 wrote: post #17

Earlier quoted context omitted.

I'd challenge you to find this level of monolithic architecture in a modern desktop OS like Mac OS X.

You're not serious right? MacOS is very much a tightly integrated system.

Mac OS's architecture is totally unlike systemd.

Areas of responsibility are implemented by standalone mechanisms that compose to create the larger integrated system and can:

1) Run in isolation from their upstream dependents.

2) Be replaced individually.

Re: What “technical” concerns do I have with systemd?

#45

Post by agwa »

lovelearning wrote: post #22

Assuming that everything the author says turns out true - such as the "big one" exploit - in say an year from now, does anybody know any active popular open source distro that aims to keep systemd away from servers?

Debian has only made systemd the default, and getting sysvinit back is as simple as running `apt-get install sysvinit-core`.

Removing systemd might have consequences for GNOME, but that's not a concern on servers. There is a significant enough anti-systemd contingent in Debian (not to mention Debian also supports kfreebsd, where systemd doesn't run) that I'm confident sysvinit will remain a viable option for servers and non-GNOME desktops on Debian. Even GNOME desktops may work on Debian without systemd thanks to the work being done on systemd-shim.

Re: What “technical” concerns do I have with systemd?

#46

Post by colanderman »

jessaustin wrote: post #26

Why weren't any of these objections heard back before Canonical knuckled under? Was upstart even worse? I really enjoyed the "impotent rage" piece linked in TFA's comments.

upstart is terrible in its own special way. Beside that it loses track of anything with a more complicated structure than, say, fingerd, its "dependency" system is wholly back-asswards: a job specifies which other jobs to start when it is ready (as opposed to a job specifying which jobs should be ready before it starts).

Re: What “technical” concerns do I have with systemd?

#47

Post by colanderman »

hyperpape wrote: post #16
RadioactiveMan wrote: post #6

As a user of linux on the desktop, I've never felt a moment of concern over the fact that it takes longer to boot than did Windows. I'm not sure who is panicked by this and I'm distressed that we would solve all of our problems with init by embracing systemd. If Gnome requires systemd, lets drop Gnome.

As a user of computers, I have never once felt that boot time was adequate for any device I have owned.

You must be young. Back in the good ol' days computers booted instantly. Apple ][, Commodore 64, I'm looking at you.

Re: What “technical” concerns do I have with systemd?

#48

Post by hyperpape »

colanderman wrote: post #47
hyperpape wrote: post #16

Earlier quoted context omitted.

As a user of computers, I have never once felt that boot time was adequate for any device I have owned.

You must be young. Back in the good ol' days computers booted instantly. Apple ][, Commodore 64, I'm looking at you.

My first computer was a Mac Plus, so it appears I just narrowly missed the good ole days.

Re: What “technical” concerns do I have with systemd?

#50

Post by drewcrawford »

teacup50 wrote: post #44
gh02t wrote: post #36

Earlier quoted context omitted.

You're not serious right? MacOS is very much a tightly integrated system.

Mac OS's architecture is totally unlike systemd. Areas of responsibility are implemented by standalone mechanisms that compose to create the larger integrated system and can: 1) Run in isolation from their upstream dependents. 2) Be replaced individually.

osx guy here.

Yes and no. It's true that OSX uses a variety of separate daemons, that run in different pids.

However they are all "required", "packaged together", "part of one source tree" and "shipped by a single vendor". In this respect they are a lot like systemd.

In fact it is arguably a lot more integrated. Both Python and Ruby are OSX dependencies. systemd isn't even close to that much of a power-grab.

Post reply on HN