Hacker News Reader

Comment by akerl_ | Hacker News Reader

Life must be terrible on that slippery slope you're building your house on.

It's been debunked time and time again that systemd is "monolithic", and nobody is forcing you to use any daemons they provide that you don't like. I run syslog-ng and cronie and ntpd and it works just fine.

And the jabs about a walled garden app store are totally out of left field.

There's plenty of room to have a rational debate about whether the direction systemd is moving is the best, whether it ought to be managed differently, and how to best provide init and process management services to systems. Lets have those debates, they're far more useful.

View on HN

No, it's not been debunked. Lennart has just made it clear time and time again that he has his own definition of "monolithic" and so the rest of us should just shut up.

Seriously. His reasoning is "it's not monolithic, this one package has 70 binaries that do different things, therefore it is modular." Clearly, his understanding of the word "monolithic" is as poor as his understanding of UNIX.

UNIX never meant anything. z/OS is UNIX. Even the Single UNIX Spec never clarified anything other than "UNIX includes these things". People who rail about how systemd "isn't UNIX" never had to maintain a heterogenous environment of IRIX, Tru64, HP-UX, AIX, and Solaris. They're all UNIX. OSX is also UNIX. Guess how similar they are and how many design philosophies they share.

Coreutils has a lot of binaries that do different things. Is is monolithic? The GNU ecosystem and autotools barely function without other GNU tools which aren't part of the same project. Are those monolithic? Monolithic is a canard.

The difference between coreutils' and systemd's components is that changing the implementation of one coreutils program (let's say "ls") will not require you to modify others (like "cat"). Not only are they separate modules, but also they are loosely-coupled by design. Contrast this with systemd's modules, which are much more tightly coupled.

What do you mean? If systemd is monolithic, coreutils is as well. In your response you make it sound like there is only one person who has this definition. That's not the case. Further, since ages UNIX (also BSD) put everything into one repository. That's also not called monolithic.

You're the one with the different definition IMO.

coreutils certainly has a monolithic release process. However, as jude- points out[0], in other senses it is quite modular.

The BSDs do have somewhat monolithic repositories, along with somewhat monolithic development and release processes. All the Linux distributions have, ultimately, monolithic release processes.

However, components within these ecosystems are much more loosely coupled. Mixing different implementations (or different versions of the same implementations) is not only practical but sometimes essential to getting useful work done.

I have a nuanced definition of monolithic that recognizes various ways in which something may or may not be monolithic.

Lennart and his cohorts have a very absolutist but conveniently-shifting definition of monolithic that they demand everyone blindly adhere to lest they be accused of spreading FUD.

[0] https://news.ycombinator.com/item?id=8203821

I believe these are the definitions used in software engineering. Someone please correct me if I'm wrong.

A "monolithic" system is a system that cannot be factored into stand-alone components. That is, there is a high degree of logical coupling between its components that make them difficult or impossible to use independently.

A "modular" system is a system built of multiple logically-distinct components. Note that this descriptor says nothing about their degree of coupling.

Examples:

* Linux, the X.org server, and systemd are both modular and monolithic.

* Coreutils is modular but not monolithic.

* The "ls" program is monolithic and not modular.

Note that under these definitions, "modular" is necessary but not sufficient for "not monolithic". From the way he talks about it, however, Lennart seems to believe that "modular" means "not monolithic".

Well, "monolithic" isn't very clearly defined, either way. There's multiple interpretations, but systemd does fall under tight coupling. Its modularity is somewhat arbitrary. A lot of auxiliary daemons can be configured out of the build, but some others like generators and most damningly journald, cannot.

Yes, you can run regular syslogd and crond implementations beside systemd's journald and timer units. To be honest, it would be pretty ridiculous if you couldn't, and it's not much of a consolation.

Although journald can be effectively disabled by forwarding to syslog (however, PID1 itself no longer supports syslog as a target), the systemd developers do want it to be the primary syslog mechanism on a Linux system, and are pushing it as such. Yet due to choosing to use a binary format similar to a RDBMS, but without the transaction consistency of an actual RDBMS, it's prone to unnecessary corruption. This was deemed not to be an issue, apparently: https://bugs.freedesktop.org/show_bug.cgi?id=64116

Then you have an (optionally network-enabled) system logging service that stays resident without being used, a potential attack vector and really just a huge, completely unnecessary sink to proxy your actual syslogd of choice to.

You're damning journald for things syslogd doesn't do either.

Syslog is not reliable. Syslog is incredibly falsifiable (journald is not). Syslog does not handle system crashes well either (pretty much the case where journald gets corrupted).

Syslog also doesn't capture application logs. Syslog does not hand over from dracut. Syslog guarantees nothing.

Don't present it as a step backwards when it's a step forwards, albeit with some warts. Even in its worst case, journald still provides more functionality and more security than syslog, and you can still use your normal syslogger

From my experiences with Fedora 20, journal corruptions happen in seemingly random cases. Not on any system crashes either, but just clean reboots. As well as other general systemd issues occasionally, including message bus queue freezes.

The plaintext medium is more reliable, largely because recovery can be performed with any generic tools that operate on text streams. Third-party journal readers, on the other hand, are discouraged.

Reply on news.ycombinator.com