Systemd 216 released including DNS resolver and full TTY stream parsing

The idea, from what I'm deducing, is to migrate Avahi (a Linux implementation of Apple's Bonjour zeroconf protocol) into the systemd codebase.

Monolithic and modular aren't mutually exclusive.

So, please tell me how can I use logind without bringing systemd as a PID 1 process.

Or how do I stdin/stdout interface (the basic interface in UNIX, where everything is a file) to the new awesome DNS resolver without having to bring up D-Bus ?

Systemd is like a bait-and-switch virus. If you want any piece of it, you have to take it all. It spreads and infects/replaces any other competing piece of software. All seventy bits have tight hierarchical coupling, and while you can run the top of heap independently, you can't run the utilities without bringing in the whole mess.

Systemd is valued by those who don't understand the quality of having independent programs that talk via standardized human-readable interfaces.

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.

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.

RMS will jump in and it'll be GNU/Linux/SystemD

Indeed. It's a damn shame Red Hat was able to expand the reach of their terrible technology from their distributions into the greater Linux ecosystem, but the BSD guys probably love it.

Systemd marks stable bugfixes in an easy way in their git repository so people can easily determine the bugfixes. I know because our systemd packager makes use of that to ensure those bugfixes are included in our systemd version. Because every packaging systemd that I know relies on tarballs, it is a bit messy. I do know that various Fedora packagers find it rather backwards to still be packaging based on tarball releases.

While BSD gives a complete system and source tree, the source tree is also designed such that you can use all or none of it and get a working system. Going into the subdirectories and just building the parts of the userland you want from the given source tree is entirely possible. Furthermore, after building everything, rc is designed as a script, with executables, arguments, etc, all being well documented and easy to override in rc.conf to your liking. For example, I don't like the built-in syslog, and prefer syslog-ng. Disabling the built-in syslog was a matter of adding these two lines:

    syslogd_enable="NO"
    syslog_ng_enable="YES"

and after that the included syslog doesn't run at all. There's no looping logs through the original syslog and out the other end, or any silliness like that. Similarly, the dhcp client, ntp client, etc, are all easily configurable as well. The problem isn't that systemd provides these bits and pieces, the problem is that it's a pain and a half when you need to turn them off.

Which is the problem.

Edit: I can see the systemd love is strong in here...

Too bad that's how it was sold.

2011: "Hey, check out this init system!"

2014: "Hey, it isn't just an init system! It's so much more!"

This works pretty well as long as you can easily replace all the bits you need. Don't like coreutils, run your own commands (on old Solaris boxes I pretty much had to to maintain some sanity). Need different drivers, install them.

What systemd is doing is dangerous in my opinion. Soon you won't be able to replace things. Software will expect to link to systemd libraries even for trivial things like startup notifications. Want to use udev? Sorry, part of systemd. Want to use gnome? Sorry, write your own logind stub. Want to use your own resolver... well, now there's a special one - let's see if it's going to show some special behaviour.

If this was a completely separate project, I wouldn't mind. But if they influence projects both up and down the stack (kernel, gnome), they have too much power to force things. Even if the changes are good right now... I'd rather they stayed away from the idea that they can reimplement everything in their umbrella project. Just so we don't ever end up in a situation where systemd can actually dictate something that projects both up and down the stack disagree with. If anything, splitting the projects into their own independent releases would force them to provide very clear, properly versioned, backwards compatible interface between them.

Respectfully: that "independent tools packaged together" line is repeated often - and it's just so much bullsugar. I run systemd in prod, on many machines, and am way confused as to why anyone thinks this is true.

(The rest of this post isn't aimed at you, chimeracoder - but you've made an argument I've heard a few times, and I'd like to address it at length, because this is where systemd discussions usually devolve into namecalling instead of actual discussion.)

Thinking of systemd utilities like unused kernel drivers - just harmless bits occupying disk space and never used until loaded - is simply an incorrect analogy. A client of mine is running systemd in prod, and I'm managing their system - so when I tell you this, what I'm saying is "whoever explained either isn't running systemd in prod on multiple machines, or is having a wildly different experience than I am." Ask whoever explained this to you if they are running systemd in prod! I would love to be wrong about this!

I feel like I hear this explanation (excuse?) fairly often, so instead of setting up a straw man, lemme flip the script here:

Could someone - anyone! - please point out a single distro or OSS project that a) makes use of systemd and b) doesn't end up building the same exact monolithic init.d re-implementation as everyone else running systemd?

Systemd could potentially be used as a suite of independent tools, kinda, I guess - but that's not what the devs are aiming for from what I can tell, and I've never seen - or even heard discussion about - systemd being used in practice as anything besides a monolithic init.d replacement. Most arguments to the contrary fall apart really quickly, with a simple question:

"How and why would you actually build this theoretical pick-your-own-utils-totally-not-a-monolith thing you're describing? Please show your work. Extra credit: explain why no one else appears to have attempted this, outside of the thought experiment that I've just proposed to you".

My guess is, like it or not, I'm going to be stuck using systemd-resolve (the DNS resolver) and systemd-timesync (the NTPD replacement), I'm guessing, because I want to use systemd-network, and the best case scenario is that my old ntpd and nsd daemons are going to have some weird issue working properly with systemd-network. What weird issue? Well, those old daemons had some quirk or other that really should have been fixed for interoperability's sake, and mumble mumble DBus won't connect for some esoteric reason, so.... they'll still "work", but the systemd-* replacement we've written works so much more cleanly and with less random flaky bugs , and using them will stop that weird hanging issue you're seeing, so....

Ugh.

(Again, sorry chimeracoder for the comment hijack. I have a lot of systemd angst, apparently.)

>you don't need all of the tools, and you can use most of them independently of the rest.

As someone who has read a minimal amount of systemd lit in the past 6 months, that's not what I've heard. Everything is dependent on everything else in Systemd, so I'm told.

In any case, why doesn't it use current Linux DNS resolvers?

The answer to "why not standardize it" isn't to make a brand new and still-incomplete implementation part of init. At most there could have been justification for further standardizing the interface through which dnsmasq, unbound, et al. can act as the default system resolver. But it's not like they didn't all already have a way to do so.