5 ms·

I'm putting this long list of "systemd myths" from Lennart's blog here: http://0pointer.de/blog/projects/the-biggest-myths.html http://0pointer.de/blog/projects

I'm putting this long list of "systemd myths" from Lennart's blog here: http://0pointer.de/blog/projects/the-biggest-myths.html http://0pointer.de/blog/projects/the-biggest-myths.html before the discussion kicks off... ....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?

chimeracoder 12y ago
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).
- viraptor 12y ago
  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.
- namecast 12y ago
  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.)
- worklogin 12y ago
  >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?
  - mhurron 12y ago
    > why doesn't it use current Linux DNS resolvers? NIH
exabrial 12y ago
> Myth: systemd is not modular. > Not true at all. At compile time..... Gun, meet foot. Foot, meet lead.
takeda 12y ago
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?
- wtallis 12y ago
  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.
  - takeda 12y ago
    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.

chimeracoder 12y ago

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).

viraptor 12y ago
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.
namecast 12y ago
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.)
worklogin 12y ago
>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?
- mhurron 12y ago
  > why doesn't it use current Linux DNS resolvers? NIH

exabrial 12y ago

> Myth: systemd is not modular. > Not true at all. At compile time..... Gun, meet foot. Foot, meet lead.

takeda 12y ago

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?

wtallis 12y ago
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.
- takeda 12y ago
  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.