I was wondering why they felt the need to add their own DNS resolver. From the changelog:
"Hostnames, addresses and arbitrary RRs may be resolved via systemd-resolved D-Bus APIs. In contrast to the glibc internal resolver systemd-resolved is aware of multi-homed system, and keeps DNS server and caches separate and per-interface. Queries are sent simultaneously on all interfaces that have DNS servers configured, in order to properly handle VPNs and local LANs which might resolve separate sets of domain names. systemd-resolved may acquire DNS server information from systemd-networkd automatically, which in turn might have discovered them via DHCP. A tool "systemd-resolve-host" has been added that may be used to query the DNS logic in resolved. systemd-resolved implements IDNA and automatically uses IDNA or UTF-8 encoding depending on whether classic DNS or LLMNR is used as transport. In the next releases we intend to add a DNSSEC and mDNS/DNS-SD implementation to systemd-resolved."
Nice features, but I don't understand if they have to be under the systemd umbrella. Here's hoping it can be broken out to be useful in other situations.
> DNS server and caches separate and per-interface
This is rather strange. I don't believe any glibc-based client will care to use the same interface for resolution and connection (can you even force an interface on gethostbyname()?)
If that's not the case, why would multi-homed-aware system be of any use to the client? I can imagine the cache split helps, because you can drop only part of the cache when one connection drops - but unless programs are written to deal with this issue from the start, they're unlikely to re-resolve the hostname, or even use any network state events.
So who gains something from this new crazy system? I also don't really get why they pull everything in - this sounds like a completely separate project... I hate the idea of Linux/systemd the world is heading for right now.
Sure. But we've got nsswitch and Avahi already... and they work. If they have some bugs that cannot be worked around, I'd expect a comment like "we couldn't get Avahi to work, upstream bugs xxx and yyy forced us to rewrite it".
systemd offers great features but they all come as a part of the same giant ball of mud. Look at what happened to udev. In 2012 the udev codebase was added to the systemd source tree. At the time it was promised that using udev separately would continue to be supported[1]. Once kdbus is merged into the kernel using udev without systemd will amount to implementing a separate userspace kdbus[2]. This is happening with the release of 3.17 this year.
Nothing will be broken out. systemd is a blackhole. Nothing escapes. systemd is good and useful but the trend here is clear.
been waiting for this release since 215 introduced a bug where systemd-networkd sends a broadcast dhcp request by default without the option to disable it, thus breaking dhcp on certain networks.
Don't worry, I'm sure the new features in this release will break something else. (After all, stable bugfix-only releases have no place in systemd, just like with PulseAudio.)
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.
Can't expect the time when you won't need libc or a shell, for that matter. Let's delete "bash" and replace it with a built-in do-it-all shell, let's call that "cmd", right ? Configuration should be done in binary-encoded files, with arborescent key-value pairs - I know, let's call that a registry, shall we ?
Package management should be done through a central place where application can be vetoed, like an app store, if you will. We could do away with silly editors like VI, we'll embed a powerful office suite right into the system libraries, shall we ?
Monolitic software is always better than small separate tools that do only one thing, right ?
Except systemd isn't monolithic at all. It's 70 bits under one umbrella project, and you only need three of them to replace init. But because it can do something doesn't mean it does that thing out of the box or even in the default configuration. Even on Fedora (or CoreOS), where systemd has the most uptake.
Why is it that every systemd critic doesn't know what systemd is or does?
Conflating the aims of everything underneath the systemd umbrella is misleading regardless of whether you think monolithic and modular aren't mutually exclusive (and hey! systemd isn't monolithic or modular -- the additional bits run separately, they don't plug into systemd), akin to lumping everything in coreutils under the same "coreutils is trying to take over Linux!" argument.
> the additional bits run separately, they don't plug into systemd
What's the reason behind ubuntu running its own stub for logind instead of systemd-login? And how would you run systemd-journal without systemd? As far as I'm aware this is not possible and the internet doesn't seem to know anything about running them standalone.
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.
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.
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.
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.
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.
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".
....and not to kick it off myself, especially as the devolution from reasoned argument to straight-up whining seems to happen often in discussion about systemd but: ugh, really? My init system now needs a DNS resolver - sorry, from the article "a caching DNS stub resolver and a complete LLMNR name resolution implementation" - to be baked into it?
FYI, I used to think the same way you do, and I was very confused by systemd initially (and critical of it), but this is the way that someone explained it to me which made everything make sense.
> My init system now needs a DNS resolver
Don't think of systemd as 'an init system'. Systemd is a project that contains a number of low-level userland tools that do not belong in the kernel. The next logical place for them to go is in systemd. One of these is an init system, but systemd also contains other tools, most of which are independent.
Systemd in that way is sort of like coreutils - you don't need all of the tools, and you can use most of them independently of the rest. But some of them complement each other, so it makes sense for them to be maintained together, even if they can be compiled independently and distributed independently.
Or you can think of it like the Linux kernel - it's crazy when you look at some of the obscure drivers make it into the mainline kernel, let alone some of the kernel modules available, but it's not that most people use or notice them (or even have them, as they may not be compiled by default in most distros).
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.)
A lot of projects have dependencies on other projects. Systemd provides a lot of very useful functionality. So it's going to be depended upon. But actually it's pretty layered. Systemd provides things to activate NTP. That can either call timesync or any other daemon.
To me, these very simple daemons are for minimal install purposes. So "cloud" and embedded. Once the OS has systemd, it'll be easy to bootup (dhcp, ntp, etc all working for the simple cases).
Various parts of Linux do weird things. Workaround bugs from other projects. While we have the source and should just fix the bugs where they are.
As I mentioned in another comments, UNIX and BSD have everything in one repository. Develop things together, ensure that stuff works nicely together. That's how I see what systemd is starting to make happen.
You keep mentioning BSD as if it's a model to be aspired to. Many people disagree. For some reason, systemd proponents seem incapable of conceiving that people could disagree with them. If you could accept that, productive conversations might be had.
>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?
I have mixed feelings regarding systemd but to be honest I don't think this particular thing is necessarily bad.
In terms of name resolution unlike other OSes Linux is kind of dumb, it sends every single request to resolvers listed in /etc/resolv.conf it does not matter it resolved the same name second ago it'll send that request.
Back in my university I remember when network admin blocked one node in the lab I was working at. Their argument was that the server was DoSing department's DNS servers.
Turns out that one of students had a very inefficiently written application, the application was making a separate TCP connection to insert a row into a database and of course there were tons of data to be imported. The server then made reverse name resolution on every request and in turn made DNS query for every row inserted in the database.
The DNS problem was solved by installing bind and setting it up as a caching server. Of course now we have other services just for caching such as unbound, nscd, dnsmasq etc.
The thing is that DNS caching is essential part of a network enabled operating system and even if you don't care about DoSing your ISPs DNS server it still brings a huge benefit by speeding up name resolution. I can't think of a scenario when you wouldn't need a DNS caching server and it looks like other OSes already include one built in, so why not standardize it?
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.
While current setup works well in server environment where ideally you want to have full control over services so you can set up your system by running only services that you actually need.
But in case of desktop system such approach becomes very problematic. There are tons of services you need for it to function and simply there too many moving parts. From my limited experience Ubuntu shows it best. Because there's so much interaction required between many simple services it is full of race conditions with things working mostly ok but once in a while behave in an odd way.
The answer to "why not standardize it" isn't to make a brand new and still-incomplete implementation part of init.
Yes it is because unless you make it a required component of the core OS, balky sysadmins will never embrace it and Linux will keep doing the wrong thing. That's the ultimate goal of systemd: to enforce consistent, correct behavior across distributions.
I'm becoming convinced that systemd is an attempt to turn Linux into a sort of hybrid/quasi-microkernel, similar to NT. Move all sorts of things that were once in kernel space to user space.
libsystemd-terminal, the aforementioned TTY stream parser, is really just the prerequisite for David Herrmann to move kmscon (that's the Linux console replacement) from the Linux kernel to systemd.
The LLMNR and mDNS/DNS-SD thing seems to me like Lennart Poettering is trying to reimplement Avahi into systemd, possibly because he's dissatisfied not enough people use it? Or because he's tired of maintaining it and wants to integrate a zeroconf replacement with the systemd APIs, like he did with ConsoleKit/logind.
And the thing is, systemd doesn't even have any discernible direction. It's described as the "basic building block to make a Linux-based OS from", but when the guys try to market it to distros they variously call it an "init system", "service manager" or whatever. The idea being that if your initd doesn't come with a util-linux replacement, it's subpar. systemd is whatever the hell the authors want it to be, and they have yet to be able to convey a concise description of what it's meant to do.
Lennart hinted at a recent GNOME Asia talk that systemd is meant to be perpetually rolling, not dissimilar to the Linux kernel. It pretty much is a second kernel, and once again, I won't be surprised if in the future the concept of the Linux distribution becomes extinct and a Linux-based OS in practice will have a hybrid kernel approach.
Realistically, I expect PAM-like system to be pulled in (with PAM becoming optional) and package management abstraction being integrated into systemd in the next couple of versions. Soon we'll talk about Systemd/Linux being the correct name ;)
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.
It's a pit of complexity from hell that I will not stand for. This change makes it worse again.
3 hours today trying to get timedatectl to enable an NTP server on CentOS 7. All I got was "Failed to issue method call" and 3 hours of taking it to bits to work out why the hell it wasn't working then it just started to work out of the blue.
systemd makes Linux feel like Windows does from an administrative perspective. Feels like stateful RPC/COM/WMI hell about to hit Unix.
Scrapped the whole damn thing and installed FreeBSD 10.0 in the end.
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.
There's nothing wrong with rolling your own version of existing Linux software and tying it all together with linked libs. It's similar to coreutils/util-linux/Busybox, but without pipes or shell scripts.
The reason systemd is so infuriating is that its creators are lying about its true purpose, which is to supplant existing Linux operating systems with its own new idealized model. It flies in the face of those people who have been working with existing operating systems for decades and really rather liked the way things used to work.
Even if your dns resolver is better than the old one, if it requires a paradigm shift in the way it's used, it's fucking annoying and I don't want any part of it. Wake me when this supposed collection of tools becomes an actual collection of tools and not just one giant 'modular' extension of a brand new operating system.
for whoever down-voted me, any explanation? I honestly feel systemd is just too bizarre, thus veto it, will it carry x11 one day? do you only like words that praising this project?
Having a TTY stream parser in systemd seems pretty odd until you read the reasoning why[1]: there's already one in the kernel, and having one in systemd means one less thing that has to be in the kernel. Which has some interesting implications.
If you're moving stuff out of the kernel into systemd, then the reason it was presumably in the kernel was because there was a need for it, and the kernel couldn't depend on anything else being around to maintain it. So while the kneejerk "systemd isn't complete until it can send mail" response is incorrect, there IS a very real concern for people who are against systemd here -- if kernel stuff is being moved into systemd, it's because it's viewed as nearly equal with the kernel in terms of being required in terms of Linux. That means eventually, nobody will be able to escape the pull of systemd. (This isn't the first time this has happened, either: a lot of the responsibility for managing cgroups is going to be falling on systemd[2].)
67 comments
[ 2.5 ms ] story [ 127 ms ] threadEdit: I can see the systemd love is strong in here...
2011: "Hey, check out this init system!"
2014: "Hey, it isn't just an init system! It's so much more!"
"Hostnames, addresses and arbitrary RRs may be resolved via systemd-resolved D-Bus APIs. In contrast to the glibc internal resolver systemd-resolved is aware of multi-homed system, and keeps DNS server and caches separate and per-interface. Queries are sent simultaneously on all interfaces that have DNS servers configured, in order to properly handle VPNs and local LANs which might resolve separate sets of domain names. systemd-resolved may acquire DNS server information from systemd-networkd automatically, which in turn might have discovered them via DHCP. A tool "systemd-resolve-host" has been added that may be used to query the DNS logic in resolved. systemd-resolved implements IDNA and automatically uses IDNA or UTF-8 encoding depending on whether classic DNS or LLMNR is used as transport. In the next releases we intend to add a DNSSEC and mDNS/DNS-SD implementation to systemd-resolved."
Nice features, but I don't understand if they have to be under the systemd umbrella. Here's hoping it can be broken out to be useful in other situations.
This is rather strange. I don't believe any glibc-based client will care to use the same interface for resolution and connection (can you even force an interface on gethostbyname()?)
If that's not the case, why would multi-homed-aware system be of any use to the client? I can imagine the cache split helps, because you can drop only part of the cache when one connection drops - but unless programs are written to deal with this issue from the start, they're unlikely to re-resolve the hostname, or even use any network state events.
So who gains something from this new crazy system? I also don't really get why they pull everything in - this sounds like a completely separate project... I hate the idea of Linux/systemd the world is heading for right now.
Nothing will be broken out. systemd is a blackhole. Nothing escapes. systemd is good and useful but the trend here is clear.
[1] http://article.gmane.org/gmane.linux.hotplug.devel/17392 [2] http://www.phoronix.com/scan.php?page=news_item&px=MTczNjI
Package management should be done through a central place where application can be vetoed, like an app store, if you will. We could do away with silly editors like VI, we'll embed a powerful office suite right into the system libraries, shall we ?
Monolitic software is always better than small separate tools that do only one thing, right ?
There's no need, https://en.wikipedia.org/wiki/PackageKit exists
>Monolithic* software is always better than small separate tools that do only one thing, right?
Even in the linked post, it's referencing seperate daemons that "do one thing."
Why is it that every systemd critic doesn't know what systemd is or does?
What's the reason behind ubuntu running its own stub for logind instead of systemd-login? And how would you run systemd-journal without systemd? As far as I'm aware this is not possible and the internet doesn't seem to know anything about running them standalone.
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.
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.
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.
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
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.
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.
You're the one with the different definition IMO.
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
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".
Or you can quit bitching at the people who make the software you use.
....and not to kick it off myself, especially as the devolution from reasoned argument to straight-up whining seems to happen often in discussion about systemd but: ugh, really? My init system now needs a DNS resolver - sorry, from the article "a caching DNS stub resolver and a complete LLMNR name resolution implementation" - to be baked into it?
> My init system now needs a DNS resolver
Don't think of systemd as 'an init system'. Systemd is a project that contains a number of low-level userland tools that do not belong in the kernel. The next logical place for them to go is in systemd. One of these is an init system, but systemd also contains other tools, most of which are independent.
Systemd in that way is sort of like coreutils - you don't need all of the tools, and you can use most of them independently of the rest. But some of them complement each other, so it makes sense for them to be maintained together, even if they can be compiled independently and distributed independently.
Or you can think of it like the Linux kernel - it's crazy when you look at some of the obscure drivers make it into the mainline kernel, let alone some of the kernel modules available, but it's not that most people use or notice them (or even have them, as they may not be compiled by default in most distros).
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.
(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.)
To me, these very simple daemons are for minimal install purposes. So "cloud" and embedded. Once the OS has systemd, it'll be easy to bootup (dhcp, ntp, etc all working for the simple cases).
Various parts of Linux do weird things. Workaround bugs from other projects. While we have the source and should just fix the bugs where they are.
As I mentioned in another comments, UNIX and BSD have everything in one repository. Develop things together, ensure that stuff works nicely together. That's how I see what systemd is starting to make happen.
Having distro's means that you farm some of this stuff out to a third party.
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?
NIH
> Not true at all. At compile time.....
Gun, meet foot. Foot, meet lead.
In terms of name resolution unlike other OSes Linux is kind of dumb, it sends every single request to resolvers listed in /etc/resolv.conf it does not matter it resolved the same name second ago it'll send that request.
Back in my university I remember when network admin blocked one node in the lab I was working at. Their argument was that the server was DoSing department's DNS servers.
Turns out that one of students had a very inefficiently written application, the application was making a separate TCP connection to insert a row into a database and of course there were tons of data to be imported. The server then made reverse name resolution on every request and in turn made DNS query for every row inserted in the database.
The DNS problem was solved by installing bind and setting it up as a caching server. Of course now we have other services just for caching such as unbound, nscd, dnsmasq etc.
The thing is that DNS caching is essential part of a network enabled operating system and even if you don't care about DoSing your ISPs DNS server it still brings a huge benefit by speeding up name resolution. I can't think of a scenario when you wouldn't need a DNS caching server and it looks like other OSes already include one built in, so why not standardize it?
But in case of desktop system such approach becomes very problematic. There are tons of services you need for it to function and simply there too many moving parts. From my limited experience Ubuntu shows it best. Because there's so much interaction required between many simple services it is full of race conditions with things working mostly ok but once in a while behave in an odd way.
Yes it is because unless you make it a required component of the core OS, balky sysadmins will never embrace it and Linux will keep doing the wrong thing. That's the ultimate goal of systemd: to enforce consistent, correct behavior across distributions.
libsystemd-terminal, the aforementioned TTY stream parser, is really just the prerequisite for David Herrmann to move kmscon (that's the Linux console replacement) from the Linux kernel to systemd.
The LLMNR and mDNS/DNS-SD thing seems to me like Lennart Poettering is trying to reimplement Avahi into systemd, possibly because he's dissatisfied not enough people use it? Or because he's tired of maintaining it and wants to integrate a zeroconf replacement with the systemd APIs, like he did with ConsoleKit/logind.
And the thing is, systemd doesn't even have any discernible direction. It's described as the "basic building block to make a Linux-based OS from", but when the guys try to market it to distros they variously call it an "init system", "service manager" or whatever. The idea being that if your initd doesn't come with a util-linux replacement, it's subpar. systemd is whatever the hell the authors want it to be, and they have yet to be able to convey a concise description of what it's meant to do.
Lennart hinted at a recent GNOME Asia talk that systemd is meant to be perpetually rolling, not dissimilar to the Linux kernel. It pretty much is a second kernel, and once again, I won't be surprised if in the future the concept of the Linux distribution becomes extinct and a Linux-based OS in practice will have a hybrid kernel approach.
Coming soon to the systemd codebase: we'll be Katamari-ing all over busybox! When will we be big enough to absorb Wayland? Stay tuned!
It's a pit of complexity from hell that I will not stand for. This change makes it worse again.
3 hours today trying to get timedatectl to enable an NTP server on CentOS 7. All I got was "Failed to issue method call" and 3 hours of taking it to bits to work out why the hell it wasn't working then it just started to work out of the blue.
systemd makes Linux feel like Windows does from an administrative perspective. Feels like stateful RPC/COM/WMI hell about to hit Unix.
Scrapped the whole damn thing and installed FreeBSD 10.0 in the end.
The reason systemd is so infuriating is that its creators are lying about its true purpose, which is to supplant existing Linux operating systems with its own new idealized model. It flies in the face of those people who have been working with existing operating systems for decades and really rather liked the way things used to work.
Even if your dns resolver is better than the old one, if it requires a paradigm shift in the way it's used, it's fucking annoying and I don't want any part of it. Wake me when this supposed collection of tools becomes an actual collection of tools and not just one giant 'modular' extension of a brand new operating system.
If you're moving stuff out of the kernel into systemd, then the reason it was presumably in the kernel was because there was a need for it, and the kernel couldn't depend on anything else being around to maintain it. So while the kneejerk "systemd isn't complete until it can send mail" response is incorrect, there IS a very real concern for people who are against systemd here -- if kernel stuff is being moved into systemd, it's because it's viewed as nearly equal with the kernel in terms of being required in terms of Linux. That means eventually, nobody will be able to escape the pull of systemd. (This isn't the first time this has happened, either: a lot of the responsibility for managing cgroups is going to be falling on systemd[2].)
1) http://lists.freedesktop.org/archives/systemd-devel/2013-Nov...
2) http://lwn.net/Articles/555922/