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

61–70 of 102 posts

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

#61

Post by jude- »

antientropic wrote: post #60
andolanra wrote: post #18

Something that tends to get lost in these discussions: it's not a question of systemd-versus-sysvinit. Systemd is miles better than sysvinit. There's absolutely no question that the vast majority of Linux users would rather sysvinit disappear entirely. But that doesn't mean that there aren't better alternatives. My personal preference is runit[1], which is based on djb's daemontools[2] and gives you all the dependenc…

What mystifies me in these systemd discussions is that people constantly seem to attack a caricature of systemd that has little in common with its actual implementation. Take for instance the perpetual "monolithic architecture" argument. What monolithic architecture? Systemd is in fact highly modular. For instance, PID 1 concerns itself with starting and monitoring units, and not much more. Other functions are implem…

What mystifies me in these systemd discussions is that systemd proponents always seem to think that "modular" is somehow the opposite of "monolithic," when it is entirely possible for a system to be both.

"Modular" only means that a system is factored into components that address logically separate concerns. "Monolithic" means that your modules are tightly coupled.

For example, the Linux kernel and X.org are both modular and monolithic, as is systemd. Coreutils, by contrast, is modular and NOT monolithic.

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

#62

Post by vezzy-fnord »

antientropic wrote: post #60
andolanra wrote: post #18

Something that tends to get lost in these discussions: it's not a question of systemd-versus-sysvinit. Systemd is miles better than sysvinit. There's absolutely no question that the vast majority of Linux users would rather sysvinit disappear entirely. But that doesn't mean that there aren't better alternatives. My personal preference is runit[1], which is based on djb's daemontools[2] and gives you all the dependenc…

What mystifies me in these systemd discussions is that people constantly seem to attack a caricature of systemd that has little in common with its actual implementation. Take for instance the perpetual "monolithic architecture" argument. What monolithic architecture? Systemd is in fact highly modular. For instance, PID 1 concerns itself with starting and monitoring units, and not much more. Other functions are implem…

So by your definition, Linux, is in fact, not a monolithic kernel. And neither is Busybox monolithic, then.

There seems to be a distressingly high amount of people lately who can't seem to tell that monolithic and modular software aren't mutually exclusive, and that you can be both. Lennart seems to propagate this idea lot that being modular automatically makes you non-monolithic.

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

#63

Post by snarfy »

jude- wrote: post #61
antientropic wrote: post #60

Earlier quoted context omitted.

What mystifies me in these systemd discussions is that people constantly seem to attack a caricature of systemd that has little in common with its actual implementation. Take for instance the perpetual "monolithic architecture" argument. What monolithic architecture? Systemd is in fact highly modular. For instance, PID 1 concerns itself with starting and monitoring units, and not much more. Other functions are implem…

What mystifies me in these systemd discussions is that systemd proponents always seem to think that "modular" is somehow the opposite of "monolithic," when it is entirely possible for a system to be both. "Modular" only means that a system is factored into components that address logically separate concerns. "Monolithic" means that your modules are tightly coupled. For example, the Linux kernel and X.org are both mod…

Tightly coupled modules is an oxymoron.

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

#64

Post by Shamanmuni »

IshKebab wrote: post #12

So... none? Unintegrated desktop linux is painful, and the fixes for it so far have mostly been hacks. Systemd actually attempts to create some kind of modern cohesive system which is a good thing. Maybe you don't see the downsides to the lack of integration because you're just used to putting up with them.

I don't agree with everything he says (the invasion of desktop linux seems completely unsubstantiated) but there are a couple of problems he points out that worry me, and I think we should pay attention.

Maturity: it certainly feels rushed that in less than four years systemd went from nothing to the default init system in most Linux distributions (if I'm not mistaken). For something so basic and important you'd think a good amount of testing and bugfixing should happen before that. We are taking our time with btrfs and Wayland, so why the rush with systemd? We certainly could endure some more years with the previous init systems. And this comes from an Arch Linux user, I like my software as fresh as I can I get away with, but it still seems odd.

Compatibility: this troubles me the most, you see hard dependencies appearing like what we currently get with Linux, systemd and GNOME. When people talk about this they are usually referring to the BSD family. That's a legitimate concern, but think about this: if in the future appears a brilliant programmer who designed a free kernel which runs circles around Linux, what will we do if everything is so tightly coupled? We have to consider the possibility that we won't be running the Linux kernel forever and be prepared to switch if something better appears.

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

#65

Post by antientropic »

illumen wrote: post #2

systemd should really include pulseaudio, and nginx. Oh, it already has a httpd in there.

You are referring to systemd-journal-gatewayd, which has a dependency on libmicrohttpd, a 93 KB web server. You don't have to run it - it's an optional unit, that even when enabled is activated on demand. You don't even need to build it, since it can be disabled with a configure flag. If systemd-journal-gatewayd were a separate package, nobody would complain about it. So why is it such a big deal that it comes included in the systemd source tree?

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

#66

Post by baudehlo »

andolanra wrote: post #18

Something that tends to get lost in these discussions: it's not a question of systemd-versus-sysvinit. Systemd is miles better than sysvinit. There's absolutely no question that the vast majority of Linux users would rather sysvinit disappear entirely. But that doesn't mean that there aren't better alternatives. My personal preference is runit[1], which is based on djb's daemontools[2] and gives you all the dependenc…

One (minor) problem with runit is that runsv maintains the pipe between the command and the logger. If runsv dies then the pipe is lost and logs are potentially lost.

S6 apparently solves this: http://skarnet.org/software/s6/index.html

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

#67

Post by antientropic »

jude- wrote: post #61
antientropic wrote: post #60

Earlier quoted context omitted.

What mystifies me in these systemd discussions is that people constantly seem to attack a caricature of systemd that has little in common with its actual implementation. Take for instance the perpetual "monolithic architecture" argument. What monolithic architecture? Systemd is in fact highly modular. For instance, PID 1 concerns itself with starting and monitoring units, and not much more. Other functions are implem…

What mystifies me in these systemd discussions is that systemd proponents always seem to think that "modular" is somehow the opposite of "monolithic," when it is entirely possible for a system to be both. "Modular" only means that a system is factored into components that address logically separate concerns. "Monolithic" means that your modules are tightly coupled. For example, the Linux kernel and X.org are both mod…

The Linux kernel is considered monolithic because all those modules run in the same kernel space, where they can all walk over each other and bring down the system. Systemd is not like that: its components run in separate processes.

By your line of reasoning, the GNU Hurd is a monolithic OS, because most Hurd servers live in the same source tree and send messages to each other at runtime.

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

#68

Post by stefantalpalaru »

gyre007 wrote: post #49
illumen wrote: post #2

systemd should really include pulseaudio, and nginx. Oh, it already has a httpd in there.

I'm glad people still remember Pulse Audio :-) What a piece of.......software ?

I managed to avoid it completely on Gentoo until recently when skype decided that the only way to deal with sound on Linux is through PulseAudio.

I like to think that a knowledgeable neckbeard suggested PortAudio and the info got mangled in transit :-)

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

#69

Post by keithpeter »

drdaeman wrote: post #10
pestaa wrote: post #7

Integration comes with a huge price. I'm a beginner sysadmin, and therefore not really knowledgeable about the recent changes in Linux -- however I've seen FreeBSD in production(ish), and it was indeed a more pleasent experience. Paths, configuration, the package system, the documentation (!) all felt nicer.

I believe it's more about tight vs loose coupling, not integration. The contrast is, systemd's parts are relatively tightly coupled together (in a way one can't easily pull, say, journald and use it autonomously, with other init), while, traditional init systems are bunch of loosely coupled mostly autonomous modules that happen to reliably work together thanks to standards' glue (so, they're integrated as well). I co…

I suspect the 'standards glue' is an important aspect of all this. With loosely coupled modules and standardised glue you can update components separately on different time scales and be reasonably confident that they will still integrate with other components.

Tighter coupling with rapid integration in functions and therefore changes in glue makes it harder to work piecemeal. Distributions have very different time lines. Pity the packager stuck trying to back port patches to an earlier version of the system when the upstream project(s) is(are) pushing out security updates based on the current versions and their current glue/api.

Of course it will work and work well. Redhat are betting their major product on this set of modules. The problem will be the load on other projects working around this.

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

#70

Post by keithpeter »

agwa wrote: post #45
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 getting sysvinit back is as simple as running `apt-get install sysvinit-core`"

Well I gather that is the intention but there are a few bugs at present around that and an ongoing issue about upgrade from Wheezy to Jessie changing the init system silently. See Debian-devel for gory details.

Post reply on HN