Hacker News new | past | comments | ask | show | jobs | submit login
Sad news today: systemd-resolved to be deployed in Ubuntu 16.10 (dns-oarc.net)
103 points by rcarmo on June 6, 2016 | hide | past | favorite | 169 comments

If systemd is so horrible why is everyone switching to it? EDIT: This is an honest question. I read quite a few negative comments on it and yet people in charge seem to be convinced this is the way forward. I'm curious why.

Because systemd makes certain desktop related tasks easier to present to the user. It's a huge loss imnsho because linux on the desktop wasn't held back by a lack of such niceties but by market conditions, at the same time linux on the server will be held back by systemd because of its tendency to do things 'its' way.

I haven't seen any single subsystem harm the linux eco-system as much as systemd has and while I understand the desktop vendors clout in this the server is where linux shines and that was territory that was hard won.

If all systemd had done was offer an alternative init system then that would have been a non-event, to take over the entirety of the linux system side tried-and-true and battle tested utilities is irresponsible at best and dangerous at worst. It wasn't broken, so it did not need fixing / rewriting.

I use systemd on my desktop, mobile phone, and servers. I'm paid to maintain Linux servers. systemd is a great addition to the Linux server ecosystem. It's infinitely easier to write a systemd init script that is functionally correct, than it is to write the equivalent init script in shell.

> It wasn't broken, so it did not need fixing / rewriting.

Writing a robust init script in shell is a HUGE pain. Every distro seemed to have their own tools and methods for writing init scripts (e.g. Red Hat had /etc/init.d/functions, Debian had its own, Ubuntu had upstart) -- all of them sucked. systemd makes it easy (and for the most part, portable across systemd distros).

I also love the systemd init system and unit system. What most people complain about isn't that. It's all the rest. Systemd is a huge, huge thing that tries to do everything.

Here, people are complaining that systemd replaces the name resolution system. People also complains it handles tmpfiles, the random devices, the journal, etc... People complains that it replaced perfectly working, battle-tested components with new, unaudited code.

I don't personally care one way or another, btw. I'm a happy systemd user. But I understand the concern.

You probably didn't realize that pain until systemd. Otherwise if you searched for alternatives, daemontools family is pretty easy to find. Or you would be using BSD instead, with better security.

But, well, since I saw a 5-year-ago Stackoverflow question recommending double fork to daemonize which goes against process management best practices dating back to 1990s IBM AIX, I realize the Internet is not smart enough to get such delicate things straight. Maybe djb stuff was not easy to find. Whatever.

*"Portable across systemd" is not portable at all.

> Writing a robust init script in shell is a HUGE pain

In trivial case, it's simple in any modern distro [1]

In non-trivial case, it's complicated. And the complexity is not going away, all you can do is move the complexity to one corner or another.

When you add the complexity to the shell script, it's right there, plain and clear.

When you move the complexity to systemd, it's not magically goes away - it just moves to thousands of lines of C code (of not the best quality on this planet, to say the least).

[1] https://wiki.gentoo.org/wiki/Handbook:X86/Working/Initscript...

> When you move the complexity to systemd, it's not magically goes away

You're ignoring that complexity was added to every single init script. Every init script had its own potential bugs, issues, race conditions, dependency logic, etc etc.

Now you're moving it to one single master system.

No, it's not "magically going away". The repetition is going away. The code duplication of an extremely complex system is going away.

The repetition is easy. Any modern Linux distro solved the repetition problem long ago. You don't need systemd monster for that.

  depend() {
    need localmount
    after bootmisc
  reload() {
    ebegin "Reloading configuration"
    start-stop-daemon --signal HUP --pidfile ${pidfile} ${command##*/}
    eend $?

You do, however, need e.g. an init that knows what to do about orphaned processes, or the above is not reliable. It also does not provide any ability to guarantee that process remains running without something other than the typical init, nor to ensure logging is done properly, or enforce resource limits.

To provide the features "just" the init replacement part of systemd provides isn't even possible with most other inits, no matter how you write your script.

systemd the init system is by no means a monster (may I remind you and everyone else again that -resolved is merely a project under the systemd umbrella).

I'm not even sure where to begin when addressing a comment like this. You're biased against systemd in the first place so I don't see the point in discussing this.

It's really amusing that basic software engineering principles are thrown out of the window the moment things get political.

The modularity of systemd-the-monster is greatly overrated. The "basic software engineering principles" you are talking about are not about tightly-coupled interdependent in and out ball of mud with no documented protocols and APIs.

Things get political that very second back then when systemd crowd started pushing their agenda to the masses using strategies like gentle push.

An artifact of sysv, not of scripts.

. filename or source filename allow one script to effectively import another. This means that the various logic can live in one place and be reused.

You didn't provided any real argument besides the obvious one - change. I use systemd on my Debian servers and i just don't see it as something bad. I have created systemd services that i use and it's really convenient.

Yes, it is much more convenient, and as an init system there isn't much wrong with it. But in software change for change's sake alone is simply wrong, it creates friction because a lot of knowledge has to be discarded and then has to be replaced by different knowledge. Large amounts of regression testing suddenly become useless which will generate ample opportunity for re-hashes of old bugs and issues (see linked article).

Modular designs are good, monolithic designs are bad. Dependencies are bad and so on. Lots of choices at the design level were made against fairly hard won knowledge on how to architect complex software systems. All these dependencies translate into 'all or nothing' and that is never a good thing in the software world. It's just another form of lock-in, something that the world of closed source software is good at and I'm quite sad to see it pollute the world of open source.

Edit: I suspect a lot of the pushback against systemd - mertited or not - is because a lot of people in charge of little parts of the bazaar have seen their pet projects cast aside by the major distros and taken over by the systemd devs. In a world where street cred is a big force in motivating people to contribute to open source being maintainer of 'x' where 'x' is part of each and every linux distro out there and then to see 'x' taken over by systemd in a fairly rough manner without any kind of co-operation between the old maintainers and the new kids on the block there are bound to be a lot of ruffled feathers. But that's not technology, that's just ego.

systemd fixes a lot of problems for a lot of people, and it wasn't "change for change's sake" - SysV-style init was a mess, and a sad leftover from a time when disks were mechanical, and many other things that amount as anachronisms in 2016.

If we never replace things with better things, we'd be using superpowered DOS machines to this day. I don't get the "knowledge has to be discarded and then has to be replaced by different knowledge" argument if the new knowledge is of a better tool.

I'm not all in with systemd's ethos, but I don't see a significantly better tool around.

Your comment sounds like preaching.

> when disks were mechanical

DISKS are STILL mechanical. They will always be. That is why it's called a disk. You thinking is limited to fancy laptops and not considering enterprise servers.

> If we never replace things with better things

Better? That is far too strong. Things are not always better but making certain use cases easier. That does not mean it's better. Systemd has nice features, indeed; but it's also limiting in terms of losing the capabilities of full blown shell script. Sometimes this latter is very handy.

Edit: Downvote? Nice. Try commenting instead.

> You thinking is limited to fancy laptops and not considering enterprise servers.

All of the servers I manage except for a few legacy ones are SSDs by now, for the simple reason that they are cheaper to operate at this point:

They consume less energy, and while their price per GB is high, their IOPS per GB is high enough that we can get away with far fewer replicas of each item of data and still get good enough performance.

I can't afford not to use SSDs in every new server we provision.

Not using SSDs in your servers today means you're behind the curve except in certain niches where performance doesn't matter but sheer storage volume does. That too is set to change within the next couple of years with current rates of cost reductions.

No downvote from me but spinning disks are on the way out, all across the board including enterprise servers. It will take a while but they will definitely not 'always be' around. See also: vinyl records. They still exist but mainstream has moved on.

Disks are still present. They are way cheaper, so especially under big data, they are still irreplaceable.

For now. Making unqualified statements about the future is where the problem lies. In the long run, silicon will win over spinning rust and 'the long run' seems to be a lot shorter than we previously thought.

Disks are more expensive for most server use today than SSDs. You can't just look at cost per GB. You need to look at cost to process per GB, and then the vastly increased IOPS and transfer rates provided by SSDs makes them cheaper for most applications where data is regularly accessed at this point.

There are niches, such as long term archival, backups, etc. where disks may still be competitive, but even those are rapidly being eroded.

For things like web servers or database servers, I'll never provision another machine without SSDs.

You don't provide any argument. 'It runs on my machines' is akin to 'it runs on my laptop'. Previous system was working, battle tested, was _not_ broken, was not polluting user space. And these are just a few arguments fished from above and other commends here. Now - to defend the new system which will have to prove it's value and stability in the next 20 years or so- what good is it? What awesomeness brings to the table?

Maybe the previous init system was not quite broken, but it had massive drawbacks, and it was not for nothing that many alternatives have sprung up in the last 10-15 years. But most of those tried to limit their scope, while the current winner unfortunately doesn't.

From the little I know, socket activation seems to be systemd's main attractive item.

The main issue is that the amount of stuff that systemd does, and the level of integration all the various parts of systemd have with each other across undocumented or unstable APIs, means that it becomes more and more difficult to replace any of it over time - we're tied to systemd as the one true system management suite until somebody can replace all of it, it's very difficult (and decidedly unsupported) to replace it piecemeal.

In fact, the only reason systemd can do what it does is because those other systems were modular.

And thus if the tradeoff is worth it for you, then you should be free to use it. But do not foist it on the rest of us.

what annoys me is for all these changes linux still can't get a proper, graphical, flicker free boot sequence.

Patches are welcome

I use systemd on all the servers I manage, out of choice. I refuse to set up non-systemd server-setups any more - it is just so vastly more pleasant to work with than the alternatives.

But it's not "taking over" anything at all. People choose to use these components.

And yes, it was and is broken. With respect to specifically DNS, have you tested the various documented options for resolv.conf, for example, and confirmed what your resolver actually does?

I have, and on several different systems with different distros, what I found was that none of them behaved as documented. DNS resolution on most Linux distros is badly deficient, which is one of the reasons so many applications pull in their own resolver libraries, and one of the reasons so some distributions end up e.g. running local Dnsmasq instances to farm out the actual resolution to something that's easier to get to behave in sane ways.

> It wasn't broken, so it did not need fixing / rewriting.

DNS has been broken on most linux systems for a long time. If you read the ubuntu mailing list post, this is the problem they are solving:

* On servers, cloud images etc. we did not have any local DNS server. Configured DNS servers (via DHCP or static configuration in /etc/network/interfaces) were put into /etc/resolv.conf, and every program (via glibc's builtin resolver) directly contacted those.

   This had the major drawback that if the first DNS server does not
   respond (or is slow), then *every* DNS lookup suffers from a ~ 10s
   timeout, which makes every network operation awfully slow.
   Addressing this was the main motivation for the blueprint. On top
   of that, there was no local caching, thus requesting the same name
   again would do another lookup.
I don't particularly care HOW they fix that issue (local dnsmasq/unbound/resolvd) but to pretend that there isn't a problem is sticking your head in the sand.

I am not an Arch Linux developer, but I am a systemd user on Debian 8 and Arch Linux systems.

Here is one answer from an Arch developer about why they adopted systemd:


Cool. Nice to have in contrast.

My personal feeling is this: systemd might be a software blackhole that eventually eat and destroy everything it comes close to and that's OK. If it is so bad then other developers can create a new or modified system that keeps the good stuff and eliminates the bad stuff, while working with other software projects to integrate better.

If we're stuck with systemd, is is better than others worse than some and it isn't like it is the first highly opinionated software project to grace us. A new ecosystem will get developed, wikis written, books sold, training courses packaged. Wise developers of other software will whisper in dark corners about the evil that stalks the land in the form of bad code and design of systemd, and crazed developers will haunt Slashdot, Hacker News, and LWN holding up the hand-lettered signs to make sure we understand how terrible Lennartitis is.

If something new comes along (more modular! less Lennart! doesn't insult the tender heart of tmux developers) developers will fight it out and we can go back to the 5 init systems that we're currently using.

The problem is there are better things before systemd, namely daemontools (and its derivs runit, s6, ...). It wasn't popular, presumably because people didn't care that much.

OTOH, Nosh offers a tool to auto-convert service files into equivalent daemontools shell scripts: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...

Few seems to care enough either.

History of modern init FYI: http://blog.darknedgy.net/technology/2015/09/05/0/

Best i can tell, init as more than what started processes at boot, and stopped them at shutdown/reboot, only really became "important" as people used laptops as oversized mobile phones.

And as the concept of containers and *aaS/cloud took hold, some of the same things that benefited said laptops was found to benefit containers.

The reason systemd happened over any of the others though was that perhaps the main dev had a penchant for NIH solutions, and worked for the 800 pound gorilla of the Linux ecosystem...

This was a GREAT answer. The problem is that this is not a factual argument but more an emotional argument.

"From 2brainz (Former Arch Linux Developer for Init Scripts"

> I was the primary maintainer for Arch's init scripts for a while and I can share a couple of thoughts. Arch's initscripts were incredibly stupid. In their first phase, there was a static set of steps that would be performed on every boot. There was almost no way to adjust the behaviour here. In their second phase, the configured daemons were started in order, which only meant that a init scripts were called one after another. In the early 2000s, that seemed like a good idea and has worked for a while. But with more complex setups, the shortcomings of that system become apparent. With hardware becoming more dynamic and asynchronous initialization of drivers in the kernel, it was impossible to say when a certain piece of hardware would be available. For a long time, this was solved by first triggering uevents, then waiting for udev to "settle". This often took a very long time and still gave no guarantee that all required hardware was available. Working around this in shell code would be very complex, slow and error-prone: You'd have to retry all kinds of operations in a loop until they succeed. Solution: An system that can perform actions based on events - this is one of the major features of systemd. Initscripts had no dependency handling for daemons. In times where only a few services depended on dbus and nothing else, that was easy to handle. Nowadays, we have daemons with far more complex dependencies, which would make configuration in the old initscripts-style way hard for every user. Handling dependencies is a complex topic and you don't want to deal with it in shell code. Systemd has it built-in (and with socket-activation, a much better mechanism to deal with dependencies). Complex tasks in shell scripts require launching external helper program A LOT. This makes things very slow. Systemd handles most of those tasks with builtin fast C code, or via the right libraries. It won't call many external programs to perform its tasks. The whole startup process was serialized. Also very slow. Systemd can parallelize it and does so quite well. No indication of whether a certain daemon was already started. Each init script had to implement some sort of PID file handling or similar. Most init scripts didn't. Systemd has a 100% reliable solution for this based on Linux cgroups. Race conditions between daemons started via udev rules, dbus activation and manual configuration. It could happen that a daemon was started multiple times (maybe even simultaneously), which lead to unexpected results (this was a real problem with bluez). Systemd provides a single instance where all daemons are handled. Udev or dbus don't start daemons anymore, they tell systemd that they need a specific daemon and systemd takes care of it. Lack of confiurability. It was impossible to change the behaviour of initscripts in a way that would survive system updates. Systemd provides good mechanisms with machine-specific overrides, drop-ins and unit masking. Burden of maintenance: In addition to the aforementioned design problems, initscripts also had a large number of bugs. Fixing those bugs was always complicated and took time, which we often did not have. Delegating this task to a larger community (in this case, the systemd community) made things much easier for us. I realize that many of these problems could be solved with some work, and some were already solved by other SysV-based init systems. There was no system that solved all of these problems and did so in a realiable manner, as systemd does. So, for me personally, when systemd came along, it solved all the problems I ever had with system initialization. What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically. You can say what you want about Poettering, but he actually realized what the problems with system initialization were and provided a working solution. I could go on for hours, but this should be a good summary.

> The problem is that this is not a factual argument but more an emotional argument.

Most of the arguments against systemd are emotional arguments.

systemd is a good thing (tm) - I recognize that and am grateful for it.


In the beginning a lot of distros were "forced" to accept systemd because udev was merged into its codebase.

Systemd is great, but its group of devs are absolutely fucking terrible at public relations. Sometimes they make changes that upset users. Like the recent one that has (logind?) by default killing all user-created processes when the user logs out (this surprised people as it became a new default). Or the security incident before that where systemd made it possible for users to get access to framebuffer contents. Sometimes things happen.

It's just made worse when you go to the systemd group with your problem and they act like what they've done is correct and everybody should just live with it. Sometimes we're wrong, sometimes they're wrong. Poettering writes up these really long posts which are mostly good reads, but sometimes he calls us neckbeards who want to live in an unchanging, static past.

Great project, great code, great devs - but terrible attitudes [sometimes].

It was indeed logind.

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221

* https://news.ycombinator.com/item?id=11782364

The systemd developers' way of addressing that was to go and ask the people who wrote things like tmux to change tmux. The response of the tmux developers was to repeat the question asked and not answered 5 years ago.

* https://news.ycombinator.com/item?id=11798515

* https://news.ycombinator.com/item?id=11797075

The problem where the people who just switched to Ubuntu 16 are hitting problems with high-end database servers, middleware, containers, large builds, and so forth all running out of threads because of another systemd default that was switched by its developers, is still quietly on-going.

* https://news.ycombinator.com/item?id=11675129

> The problem where the people who just switched to Ubuntu 16 are hitting problems with high-end database servers, middleware, containers, large builds, and so forth all running out of threads because of another systemd default that was switched by its developers, is still quietly on-going.

That's evil. Thanks for pointing that out. Terrible to debug, poorly documented and funny side effects you don't immediately think off. That fork bomb reasoning for the change is also sketchy as if you have local privilege you can DoS the machine in a lot of other ways (cpuburn, filling the disk, hogging memory and causing swap of death). If you run a public SSH server you likely already used cgroups and other measures to prevent fork bombs.

Gigantic thread on the KillUserProcesses setting: https://lists.fedoraproject.org/archives/list/devel@lists.fe...

"Great code" -> I am sorry, but if the allegations are true it's not great. (Not saying every part of it is bad, I kinda like the idea of systemd-init-part, but I describe them as utterly inconsiderate to everyone else.)

Basically because RedHat has an obscene amount of clout in the ecosystem and can basically push through whatever they want.

See here systemd, pulseaudio, lvm, selinux, kvm, many more.

Some of these things are good, some of them are bad. The important thing is once RH has decided they want to take over another component of the ecosystem there isn't really a lot anyone can do. Not even Linus has been able to halt the systemd nonsense.

Why do other distros cave? Well because RH controls most of the other important projects too and they go to great lengths to create integration that is unnecessarily difficult to decouple. For instance Gnome. Probably impossible to run without systemd now (or at least highly impractical).

At the end of the day it has nothing to do with the technical merits of systemd and everything to do with how much power RH has to steamroll whatever solutions they want through.

> At the end of the day it has nothing to do with the technical merits of systemd and everything to do with how much power RH has to steamroll whatever solutions they want through.

RedHat is a premium member of our community that has a well earned reputation which makes whatever they do get noticed. Why are they to be the focus of a witch hunt like if they were MicroSoft of the Steve Ballmer era?

If these things didn't solve problem they wouldn't get used period. RedHat being an evil member of Linux seems almost comical. Linux has won the war and yes RedHat has been a key member in winning the technology war. I fail to see how all distros who can do whatever they want continue to chosen RedHat solutions over and over again? They make developers lives better and arguably Linux better.

Canonical on the other hand continues to be a Linux community member that tries to compete with everyone else and doesn't contribute upstream as much as everyone else. I say it is good news now we can have less wasted work on different solutions. Why hasn't Canonical's projects caught on? They don't work as well or seen to not work as well as other solutions. Unity anyone?

PulseAudio has been a HUGE success that so many talk down due to the rocky start of the project and the personality of the developer (Who also created SystemD) Audio in Linux was a huge mess prior to Pulse Audio.

KVM - is the best virtual system bar none.

lvm - I don't really need to defend this project?

selinux - This was started by the NSA not RedHat

I never said they were evil. You misconstrue what I am saying.

I am just saying if RH wants something to become the dominant solution it will be, regardless. Doesn't matter if they started the project, or acquired it, or if they just think it's a good idea, or maybe it's just something a subset of their clients want (i.e selinux).

It's not about competition either. Canonical is a terrible example. They are tiny compared to RH in terms of presence in the community. Their efforts are basically safe to ignore because they are downstream of everyone else.

The issue at hand is just how much of the upstream that RH has a stranglehold on.

As I said. Sometimes it's good, sometimes it's bad but even if it's mostly good it doesn't mean that it's not happening.

I don't think it's really all that bad; several big, popular, widely-deployed distributions are using it and most people appear to be getting on just fine.

It's just that people against it are extremely vocal.

I do dislike the idea of binary logs, though.

People against it are extremely vocal because it is much harder to work around than previous stuff. Don't like PulseAudio? Use alsa directly is fine, I did in my Arch Linux box. Don't like Flash? HTML5 FTW. Don't like systemd? I have to go to FreeBSD altogether.

I like binary logs. They are faster, which is not a bad thing if you have to grep them. And easy to filter thanks to a fix metadata interface, and so on.

journalctl could use some work, but it can just print JSON, and there's jq.

Maybe my dislike for binary logs is because I haven't yet learnt the tooling around them.

I'm familiar with dealing with text files in Linux/Unix land and have built up years of knowledge on doing so. I feel reluctant to throw that away.

Because scope creep means more and more packages have systemd as a hard dependency.

And that is not a coincidence

> Well, it is definitely our intention to gently push the distributions in the same direction so that they stop supporting deviating solutions for these things where there's really no point at all in doing so.

> Due to that our plan is to enable all this by default in "make install". Packagers may then choose to disable it by doing an "rm" after the "make install", but we want to put the burden on the packagers, so that eventually we end up with the same base system on all distributions, and we put an end to senseless configuration differences between the distros for the really basic stuff.

> If a distro decides that for example the random seed save/restore is not good enough for it, then it's their own job to disable ours and plug in their own instead. Sooner or later they'll hopefully notice that it's not worth it and cross-distro unification is worth more.


"There is also concern that it forms a system of interlocked dependencies, thereby giving distribution maintainers little choice but to adopt systemd as more user-space software come to depend on its components" from relative wikipedia article (https://en.wikipedia.org/wiki/Systemd). This does not sound any good.

systemd is many things. It's a sensible init system, better in some ways than upstart and lightyears ahead of SysV init. Its native support for confining daemons' process tree using cgroups is generally a good idea.

But it's also a load of unrelated utilities like this one. Unfortunately if you get systemd as an init system, you generally get all this other stuff (unless you take steps to remove them, which in some cases is simple and in others is painful).

Some of these utilities might be a good idea, but they should be separate projects, not bundled.

As a daemontools fan, I'm frustrated that something in the daemontools family never became popular (process supervision, be it daemontools, upstart, systemd, etc. makes managing services so much nicer). But I do recognize the utility of using cgroups as part of this. Is there, or could there be, a "do one thing" utility that can launch a process in its own cgroup, such that it would fit in nicely in a daemontools-style run script?

There indeed could be. (-:

Hey, presto!

    jdebp % cat /var/sv/epmd/service/run
    #Run file generated from services/epmd.service
    #Erlang Port Mapper service
    move-to-control-group epmd.service
    setuidgid rabbitmq
    jdebp %

Because it started small and OK. When distros made the decision to switch, it looked OK. It has proliferated into something else since then and none of the distros seems to be willing to take a step back.

Problem there may be that going back means picking up maintenance on code that has been abandoned for years.

There is a fork of Consolekit out there, Consolekit2, but they have to contend chasing logind's tail as most DEs have either stripped out their consolekit support, or it is suffering from severe bitrot.

Maybe because Red Hat pays the bills ?

Bingo. A full time programmer can churn out code and keep up with lists much better than someone that do so on their spare time.

Never mind that if you have several programmers on RH payroll on the same project, it is quite possible for them to use corporate channels to make decisions and then effectively dump that into the codebase over night.

My 2 cents: init script wasn't a enough pain in the ass for people in charge to search for alternatives but still a pain, and systemd was introduced to them by Red Hat manpower. It seems good enough so they went with it.

Actually, init script wasn't anyone's enough pain in the ass in Linux world save for djb. daemontools came out in 1997 and no one seemed to care. Systemd replaced those init scripts IMO only because they wrote all the replacement service files as well with the manpower at Red Hat's disposal. It's hard to match that from open source world.

Red Hat's marketing muscle to "embrace and extend".

How does this argument even make sense? Since when are Debian developers or Arch linux developers overly concerned with Red Hat marketing muscle?

RedHat controls development of other important Linux subsystems and introduced hard dependencies on systemd.

I don't understand why you are getting downvoted.

The absorption of udev and basically forced dependency on systemd from important desktop environment projects also controlled by RH is a very real reason why this happened.

Nothing prevented people from forking udev if they didn't want to take systemd.

Forks and alternative /dev managers have to contend with GregKH and Sievers though...


Thanks for the great read. mdev is indeed nice alternative to udev monstruosity. It is somewhat supported in Gentoo https://wiki.gentoo.org/wiki/Mdev

This might or might not be true. I would be inclined to agree more with it if the evidence from other distribution highlighted this argument.

I don't see Debian or Arch developers making that argument.

Are they hiding how much pressure from Red Hat they feel? Unlikely. Linux developers are happy to blog, tweet, and post to mailing lists about large and small things, but somehow a concerted push by a corporation makes them fall silent and accept SystemD?

I think it is pressure in the overt sense.

It is rather that RH can throw dollars and thus coder man hours at a problem while most other distros have to make do with volunteers (or can't field the amounts RH can).

Then again, there is a certain email from Poettering thats of interest.


An analogy with Google PlayServices is inevitable.

> "Google's strategy is clear. Play Services has system-level powers, but it's updatable. It's part of the Google apps package, so it's not open source. OEMs are not allowed to modify it, making it completely under Google's control. Play Services basically acts as a shim between the normal apps and the installed Android OS. Right now Play Services handles the Google Maps API, Google Account syncing, remote wipe, push messages, the Play Games back end, and many other duties. If you ever question the power of Google Play Services, try disabling it. Nearly every Google App on your device will break."


Those things all happened, it's just been going on subtly over a period of years. A search for Gnome and systemd on HN should turn up some of the earlier complaints. The *BSD developers certainly made some noise.

Under a severe pressure from a vocal and extremely tribal minority, of course. There are no technical reasons to do it.

I don't know about other distros but let me remind you that ubuntu sometime ago switched from gnome desktop to Unity despite all the cries that the latter is just horrible.

If you do not like unity, you can just use ubuntu-gnome like me. IMHO, Unity is horrible, but you have the choice to not use it. There is no need to complain.

Criticism does not equal complain. If I find something horrible I'll say so - that's feedback. By your way of thinking, since I don't have to use brainfuck (an intentionally horrible language) I should not mention that it is horrible. You just don't make sense other than patting youself on the back for being 'positive' downvoting the grumpy ones while letting bad ideas forward.

But you can still run gnome on Ubuntu (I do), and Linux without a graphical interface at all.

True. Or you can switch to Mint. The think with systemd though is that you don't have this option anymore. Regardless of how bad idea you think it is - you are stuck with it (as it seems). I think that's on the core of arguments against it.

Without "Desktop Environment", not without graphical interface.

Huh? When did a console become a graphical interface?

Not a console. X Window System and window manager.

And? I don't see Canonical hog tying their DE to user space internals such that everyone else had to fork it or adopt it.

Why are people constantly trying to demonize Canonical?

I have used Linux (mainly Ubuntu) exclusively for years and love it. I do some devops when needed, run a few websites etc. Granted, I'm not a full-time sysadmin but I do plenty of work with Linux.

I don't understand why systemd is taking over or what benefit it has bought. It works for now, is that enough?

It feels like a monstrosity of overly complex and questionable design. Yet, it spreads. Throwing "unix philosophy", a most agreeable set of ideas, out the window.

Maybe I'm just being reactionary and slow to adapt.

I've mostly lurked lately and have firmly vowed not to touch a systemd-related thread ever, but I'm waiting for a long compile and I'm going to bite.

First, please, let's get the unix philosophy crap out of the way. Most of the modern Linux tools don't follow it. The people who passionately hate on systemd for not following the unix philosophy happily use Grub2, LibreOffice and whatnot. The Unix philosophy is nice to have, but quality software that does not follow it exists, nonetheless.

The advantages that systemd has brought are hard to downplay. It gets a lot of hate because they're essentially non-existent for desktop users (and don't give me that shit about dynamically mounting storage devices or parallel startup and whatever, because those were available way, way before systemd was a thing). The unpleasant truth is that desktop Linux is largely irrelevant for a lot of the major players in the Linux world, and for the very few who care about it, the only relevant target is corporate workstations, where a tight integration with systemd is desirable.

tl;dr it has real advantages which are desirable to most of the companies that pour money into Linux stuff and, unsurprisingly, these can dictate much of Linux development at the moment.

Fair enough on unix philosophy, I'm not a purist, compromise is understandable. Still, an expectation that lower level tools be more in line with it than, say, LibreOffice doesn't seem that crazy to me.

So, what is the advantage systemd provides to companies?

My answer is going to be very skewed towards what I do (embedded systems), but:

- It offers a single, easily-configurable way to define startup tasks, issue various system-level commands (shutdown, suspend etc.), which is immensely helpful when you write a daemon that has to write on a dozen different targets. The official story is that SysV was nice and easy because it was just a shell script and we loved that. Truth is, writing startup scripts was a heart-wrenching adventure in figuring out the subtle differences between distributions. Systemd's solution is not better, IMHO, but it is certainly far, far easier...

* ...which is a big deal when, now that Linux is suddenly the next big thing (especially in make-belief markets like IoT), you have to suddenly convert swarms of Android and Windows programmers to Linux programmers. Especially on platforms where there's a lot of integration and packing work to do (which often gets outsourced to someplace where programmers are cheap and super-specialized), this is useful, because it's a lot easier to teach people to write systemd service files than it is to teach them to write shell scripts.

* Having a unified system for virtually every system-level task reduces the surface on which your customers can exercise their creativity, which reduces support costs.

* For companies that write Linux software, as opposed to "just" integrating it, having a standardized system for virtually every system-level task means that, as long as you stick to using that interface, your software is going to run on whatever distribution or platform you deploy it on. Historically, this was problematic on Linux, as every distro did its subtly different thing and, consequently, you had to test on every distro.

Edit: just to be clear -- these are all good things. My beef with systemd is related to its community's attitude towards reliability and bugs, the abysmal documentation that surrounds not just systemd, but its entire entourage (like D-Bus), its developers' lack of concern for anything that is not systemd or Gnome and runs on something other than their laptops, and the aggressive PR around it, the result of which is that a) now there's a bunch of systemd bigots who keep trying to push it into everything, even where it doesn't belongs, and b) there's another bunch of anti-systemd bigots who insist it's the doom but won't code a damn line to give us something else, and I have to keep explaining why systemd is OK sometimes.

Just one nit about "SysV was nice and easy because it was just a shell script and we loved that". The design behind SysV init was nice and easy and we loved that (i.e.: init is started by the kernel, it starts the scripts that bring the rest of the system up, and after that it takes care of reaping zombies). The init scripts used in Debian (picking that as an example as it's the Linux distro I am most familiar with) were horrible.

Not one or two, all of them. Writing an initscript started with copying the template from /etc/skel, and it was already pretty long. Compare that with the actual init scripts from FreeBSD/OpenBSD. Some are literally 3 lines long.

My issue with systemd is that there is no clearly defined scope. It started as a "SysV init replacement", which it clearly isn't. SysV is an init system, while systemd is more of a service manager that can also run as a system's init. When comparing the two, or even systemd vs {upstart, nosh, you name it} what are we even trying to compare ? systemd does init, service restart, tracks user's process and sessions, manages your network (systemd-network), your logs (systemd-journald), your devices (systemd-udevd), how your system syncs time (systemd-timesyncd) and I'll stop here because the list is long. IMO, it does too many things and it appears the various components are rather tightly coupled.

Others have mentioned the code quality; I can't comment because I haven't looked at the code. One thing that really bothers me though, is the tight coupling with dbus. It doesn't matter how good the systemd-* code is, if dbus is borked then your whole system goes down with it. I can debug a misbehaving init script by starting it with sh -x. With dbus, it's a nightmare.

> Not one or two, all of them. Writing an initscript started with copying the template from /etc/skel, and it was already pretty long. Compare that with the actual init scripts from FreeBSD/OpenBSD. Some are literally 3 lines long.

Unfortunately, a lot of the BSD wisdom is lost on people who try OpenBSD on their laptops, can't figure out how to connect to wifi without NetworkManager or wpa_supplicant, and automatically conclude it's arcane shit from another age. Clean init management is just one of the lessons that Linux could learn from there.

> Others have mentioned the code quality; I can't comment because I haven't looked at the code. One thing that really bothers me though, is the tight coupling with dbus. It doesn't matter how good the systemd-* code is, if dbus is borked then your whole system goes down with it. I can debug a misbehaving init script by starting it with sh -x. With dbus, it's a nightmare.

I've read the systemd source code here and there. At line level, the code is actually pretty good, idiomatic and clean. I don't remember seeing any obvious blunders.

Engineering-wise, I've seen better. The lack of a serious debugging infrastructure is just one of them, and that plagues pretty much any D-Bus application, not just systemd. A lot of features are gratuitous/unneeded, exist just because the developers couldn't bother to read documentation or didn't like the defaults of some tool so they wrapped it in a systemd interface, or simply because of Gnome.

Then again, a lot of things are badly-engineered and we run them. The only thing I very strongly dislike is the deployment/distribution model. It's a huge suite of tools of massive complexity; at any given time, for any given version, at least one of them is basically of beta-level quality, which means that, for any version N, you end up knowing at least one or two workarounds for a set of bugs. Then N+1 pops up. The old bugs are resolved, but now two other tools have been added, another one has been rewritten because reasons, and now there's a new generation of bugs that you have to learn and remember. The fun grows exponentially with the number of platforms that you need to support; I now know about, like, more than a dozen systemd bugs across five versions, because I have to support targets that use five different versions. I'm a walking bug tracker at this moment.

Edit: I know this is technically "the distributions' fault", but sometimes you don't quite have a choice, e.g. when working with whatever SDKs a manufacturer provides, or when dealing with systems where upgrades are difficult and infrequent for various reasons (regulatory, remote access etc.). Devops is not the answer to everything.

I agree. First the whole thing about systemd closing nohup and screen processes on logout and now this... I have been thinking about switching to freebsd as well, at least for my server environments.

Any good recommendations re: Linux distros that follow the Unix philosophy closely whilst still being up to date in terms of packages?

PC-BSD (based on FreeBSD) on my laptop works surprisingly nicely. It's been more stable than Xubuntu for me, and because of ZFS, capable of rolling back any wrongful update without an external backup. The ports system is straightforward and close to hand that I already want to contribute. I didn't know such system can be done with just a git cloned hierarchy of dirs with makefiles doing search. While its GUI app manager AppCafe resembles Ubuntu's user-friendliness, if not better.

For server maybe you can give OpenBSD a spin for its fame of security.

I started using freebsd two weeks ago. My usual ruby stack carried over just fine and so far it's kinda fun. The stack being sinatra, thin, nginx, postgresql. I assume any other sane backend stack will carry over just as easily.

The last on battle field are Void Linux, Slackware and Getnoo.

Don't forget Alpine Linux

To be fair, most Linux distros haven't followed the Unix philosophy for a long time.

The process turns a request for binary DNS data into into XML, feeds it into the sytemd/dus ecosystem, which turns it into binary DNS to send it to the forwarder. The binary DNS answer then gets turned into XML goes through systemd/dbus, then is turned back into binary DNS to feed back into glibc.

This reminds me of http://thedailywtf.com/articles/XXL-XML and the "XML fever" that infected most of the enterprise and otherwise software developers many years ago. Whenever I see some system XML-ifying everything, it's usually a good indicator of grotesque complexity elsewhere in it too.

I took a quick look at https://github.com/systemd/systemd/blob/master/src/resolve/r... which is where I believe the server-side part of resolvd lies, and found no use of XML at all, only the normal dbus binary serialization.

How do you square the use of Desktop Bus that you've observed in the code with the statement by Martin Pitt, systemd developer and Ubuntu systemd maintainer, that sparked this news report in the first place:

> we picked "resolved" as that [...] does not require D-Bus (unlike dnsmasq)

-- https://lists.ubuntu.com/archives/ubuntu-devel/2016-May/0393...

Is that him misunderstanding the tech he is evangelizing, or a bald faced lie?

How else would you send the data to dbus? dbus is xml-based.

This is caused by resolved requiring a separate forwarder. "XML" isn't inherently bad.

> dbus is xml-based.

No, it's not: https://dbus.freedesktop.org/doc/dbus-specification.html

> "XML" isn't inherently bad.

Yes, it is (well, as a data format; as a markup language it's ugly but serviceable). XML is incredibly verbose, arcanely complex and a colossal time-sink of man-hours which could have been spent on pretty much anything else in computing. It's the JavaScript of data formats (which is amusing, since JavaScript's data format JSON is actually not half bad).

> dbus is xml-based

"D-Bus is low-overhead because it uses a binary protocol, and does not have to convert to and from a text format such as XML." https://dbus.freedesktop.org/doc/dbus-specification.html

What really struck me was the fact that desktop community (not sure if this would be happiest word for it, but I think you'll understand) is dictating the fate of whole Linux. For me Linux was and is primary a server OS. Than worsktation one, and on the last spot consumer desktop OS. I mean for desktop perspective systemd maybe isn't that bad, but for servers I am sure there are better solutions.

I maintain Linux servers. I also write backend/server software. systemd is a Godsend. It's infinitely easier to write a systemd init script, than it is to write a robust init script in shell.

systemd (by leveraging cgroups) makes it easier to 'track' started processes. It makes it easier to stop/kill processes. It also provides handy security features (e.g. PrivateTmp).

Can we stop talking about the init scripts? systemd does that well, we all got it. I personally was not overwhelmed when having to use it but it's step forward from sysv init scripts - no one sane doubts that.

All the recent talk about systemd is about the other components that replace certain basic userland compoments.

logind for sessions changed the default to kill background tasks on logout, now it's about the implementation of the dns resolver that comes with systemd. There are other implementations that replace cron, ntpd, syslog...etc.pp. All of this has a dependency on glibc and uses dbus.

This has nothing to do with init scripts. This is an attempt to improve on the status quo of userland tools close to the OS. systemd appears to provide some minimal userland that comes with a Linux kernel and aims to be a userland API. I personally think this is a bad idea but I kind of see the point why you might want to do this.

The IMHO absolutely warranted criticism for some of these replacements is that they are not better designed, that they create new dependencies and complicate things without reason and there is a tendency to create some systemd specific API that userland has to implement - breaking compatibility with other POSIX systems - something that was hard to do even before systemd.

So it's not about init scripts - it's about revamping essential userland tools in a way that's badly designed according to some.

Personally I hold no grudge against this but I'm not keen on using this or having to deal with this as a sysadmin. It's a undocumented black box once you have run into problems and you are busy reading C code or capturing dbus calls. I have usually better things to do.

And for the initscripts - you could have done this with runit/s6 and mkdir with cgroups in 2008 if you wanted. You could have used setsid before that. This was deprecated and now systemd (or something else that implements the kernel API) is the whole mananger of cgroups.

I personally think the systemd way is not the right direction to take as it's horrible inflexible and will bite Linux but I can understand why you might disagree here strongly.

It's interesting that at least twice in these comments someone has claimed that this was a desktop technology that was going to ruin servers, and when server using professionals reply that it's really good for servers they get what read to be quite angry responses.

I don't know much about it, but even from my position of ignorance it's clear that the level of debate is very low.

I wonder how many of those servers are web hosts.

There seems to be a line drawn where those that do web hosting and similar love systemd, while other server admins loath it for introducing needless complexities.

I have taken to thinking about web hosting as "uptime by machine gun". This in that they achieve uptime not by maintaining solid server configs, but by rapidly firing containers and/or VMs at the problem until it goes away.


Seems to be true since the famous "400 restarts a day is OK"


dear deity...

Was my response angry? Was not my intention - I just wanted to point out where the grudge is coming from.

I guess the debate is so toxic because it's a perfect bikeshedding topic everyone that uses Linux can somehow participate in. Some sysadmins are surely frustrated because it breaks the way they worked in the past years, others are happy about the new features.

I'm undecided but if I read this https://news.ycombinator.com/item?id=11675129 I'm really feeling uncormfortable. Hitting this and debugging it seems like a nightmare. So I guess it's a win and eases a lot of pain points for ordinary users but make the live of specialists a lot harder. I can imagine how you hitting these bugs regularly turns you into posting something in the angry territory.

On the other hand the debate is now mostly technical (except some trolls).

My point was that there certainly were better solutions than systemd! It's about core philosophy of systemd that's wrong.

I just gave up on Linux distributions and switched to FreeBSD. Every year there are more steps backward in every Linux disto than good changes.

Gentoo is systemd-free with -systemd USE-flag

I see that this change (systemd) is mostly driven by desktop software dev teams. If linux chooses to care mostly about the desktop aspect (IMHO previous such experiments like Unity were total flops but I'm not an expert) instead of its server one then maybe that's the opportunity for BSDs to cover up the void. Not a bad thing at all.

No, I think it's good change. Last year I stopped contributing to ArchLinux, I'm seriously considering doing the same for FreeBSD/PC-BSD now. BSDs have a lot to catch-up, even things like network-manager don't work on BSD, it have to be ported, or network connections have to be configured manually in rc files. Personally it's ok for me to work like that. OpenVPN configuration in FBSD was EASIER than doing the same in UI on KDE5 nm-applet. (Personal opinion->) I think connection to VPN providers is more stable and I lose less data on BSD than on Arch. So it was another benefit :) Generally a lot of things are much easier in BSDs, there is literally ONE manual for everything and it applies from FBSD-NetBSD-OpenBSD-DragonFlyBSD. When one manual for a thing for ArchLinux doesn't apply to Ubuntu or even worse tutorial from Ubuntu doesn't work on Debian, things become ugly... I value it a lot.

things like network-manager don't work on BSD

That is a feature not a bug.

Why? My parents are using openSUSE because it's very Windows-like, they would have no chance against PC-BSD.

This was what irked me personally about Linux. I am a BSD fan and went the BSD direction because there was essentially one popular distro (FreeBSD) and at the system level they all worked the same way.

It was bizarre to me that a few years ago even changing your host name at the command line was different between the various Linux distros.

> even changing your host name at the command line was different between the various Linux distros

That was one of the things that the systemd people set out to remedy, in fact. Now, you run a Desktop Bus client that talks to a system-wide Desktop Bus server using a Desktop Bus protocol.

* https://freedesktop.org/software/systemd/man/hostnamectl.htm...

* https://freedesktop.org/software/systemd/man/systemd-hostnam...

* https://freedesktop.org/wiki/Software/systemd/hostnamed/

I am using PC-BSD and the network is configured with a GUI and working fine. I don't know what's about network-manager.

Sad indeed. Every IT product reaches a stage where the basic things are done. Then bloat is added to keep programmers employed and to create new problems that secure a steady income from consulting.

But perhaps I'm biased: I just had to use chattr to keep the &/!&%"/! NetworkManager from overwriting /etc/resolv.conf. All these things just worked 10 years ago.

> All these things just worked 10 years ago.

While I massively dislike the systemd approach, this is not true either. Using wifi, mobile connections on linux were a massive pain unless you already spent countless hour on writing your own fixes for you own setup.

> All these things just worked 10 years ago

10 years ago most resolvers did not use source port randomization no one had DNSSEC deployed.

10 years ago would be 2006. In 2006, three of the most popular DNS server softwares, djbdns, PowerDNS (ranked third in a contemporary survey of content DNS servers), and MaraDNS, all had source port randomization. As did mine, although its ranking was somewhat lower. (-:

djbdns had had it since the previous century, MaraDNS for 5 years, mine for roughly the same, and PowerDNS for (I think) 1.

I said resolvers, not servers. What client side dns libraries did source port randomization in 2006?

Resolvers are exactly what I told you about. You clearly don't know the jargon.

The RFC terminology for in-application DNS client libraries is stub resolvers. RFC 1034 section 5.3.1. A resolver in contrast is the complete subsystem, sometimes implemented as a stub resolver together with a separate program that it makes remote procedure calls to, that does query resolution. RFC 1034 section 2.4.

Yes, it's arcane terminology. It's not mine. I've been telling people to think of DNS like HTTP since the turn of the century. But if you use it, use it correctly.

* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dn...

Great... can you answer my question?

What client side dns libraries did source port randomization in 2006? AFAIK it wasn't until 2008 when most things were fixed.

People keep talking about the good old days before systemd where everything worked perfectly, but that ignores the fact that things were pretty broken.

If you care about things like local caching and failover, things are still pretty broken. Most unix systems are horribly fragile out of the box. You either run something like dnsmasq or unbound locally or use a hack like https://github.com/kvz/nsfailover. A large number of distributed systems completely grind to a halt when the primary name server fails (if only everyone used anycast...)

Don't use NetworkManager at all, that's it.

I'm conflicted about this. I've yet to find a Linux distribution that actually acts the way the documentation for /etc/resolv.conf claims the options in resolv.conf should work (most of the options do nothing or work differently than you'd expect).

Basically, if you rely on the system/glibc provided DNS resolution on most Linux distros and you want reliability, your best bet is to run a local DNS server and point everything there either way.

That's not changing with systemd-resolved in the state it is today, but who knows, maybe someone actually paying attention to the resolver stub will finally make that situation improve.

> most of the options do nothing or work differently than you'd expect

Please give examples.

>- It accepts DNS forwarders for all its interfaces. That means if you are on wifi and 3g, or ethernet and wifi, you have more than one DNS server from logically different networks. With no way of guaranteeing which logical network you asking.

That's going to be very inconvenient for laptop users...

How does this play out with wifi networks that resolve dns requests for say, "google.com" with their "click to accept the terms of your municipal free wifi" page?

I use a mac and the same issue is there; all I do is override the DNS on the wireless connection to use In systemd-land, I'd expect that to be in /etc/systemd/wireless.network:


(other settings omitted). However, DNS hijacking isn't necessary for a captive portal - they can reroute port 80 traffic and respond with 511 per https://tools.ietf.org/html/rfc6585#section-6, (quite common now as the interaction is better for non-browser phone apps) or advertise the login page via DHCP as in https://tools.ietf.org/html/rfc7710.

not necessary, and yet very common. And setting your DNS server to doesn't help when they reply with their internal gateway for all DNS requests.

FYI - android fires a request to http://clients3.google.com/generate_204, I'm fairly confident windows/ios/mac/ubuntu all do something similar.

I'm not sure how it's supposed to work -- are you only supposed to have DNS servers defined from one particular network, or is it a case of needing to specify priority of sets of DNS servers? Or is there any software that allows you to configure domain names for particular interfaces?

And any phone or tablet that uses it

I'm surprised that so many comments are about systemd, if it is evil or not, and so few about this actual issue. Is a system with this DNS implementation safe, would it work, is something you want to use?

Maybe the author is biased but the list of issues and potential vulnerabilities is so long that there could be CVEs reserved now waiting only for the release of software.

Systemd is arguably the most hated Linux software ever. Why have all major distros switched to this thing ? I don't get it.

A good description of why it's superior to init scripts: https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a...

I don't know enough about resolved to comment on this new development, but as a sysadmin I much prefer systemd as an init system.

Upstart wasn't bad at all. It actually worked really well. I've never dealt with other init scripts but now that my dev/deploy target is freebsd I don't really see any issues with shell scripts as init scripts either. I don't need any fancy parallelization and socket activation and all that fancy jazz for a backend server.

It was unfinished, almost unmaintained, and basically left for dead. It was (and is still) a lot better than shell scripts, but the problem (of system [lifecycle] management, including initialization) is complex and hard to isolate/decouple and evolve in a sane manner.

> I don't need any fancy parallelization and socket activation and all that fancy jazz for a backend server.

And that is perhaps the red line. Those that have embraced systemd seems to be made up of cloud/container/web people that worry about being able to take something from 1 to 1 million servers in a heartbeat.

Those that do not see the need are all those that for years have been running Linux using sysv or alternatives on the backend for various uses.

It's the most vocally hated possibly. Certainly not the most hated. While systemd has its share of issues, it's overall high quality and reliable. I can think of far more globally hated software (Flash).

Make a note that systemd-resolved is not systemd, merely "part of the systemd umbrella". -resolved is not widely deployed at all.

"There are only two kinds of languages: the ones people complain about and the ones nobody uses." -- Bjarne Soustrop

Because it's also very much loved, or at least detested less than SysV-init and the other stuff it replaces, by a lot of people.

There are things I don't like about it, but overall it makes my experience administering servers far more pleasurable.

Less time spent maintaining init scripts.

So, less than zero minutes for the vast majority of desktop users? Hell I barely even touch init (rc.d) scripts on my BSD servers.

When was the last time you had to "maintain" an init script? Apart from the rare cases when you have to write one, which is mostly start-stop-daemon and a switch-case, when was it really a pain in the past ~8-9 years?

The last time I had to setup execution order of 7 scripts and make sure 3rd starts after 1st is already running? https://www.reddit.com/r/linux/comments/4m0r93/why_did_archl...

  depend() {
    need net
    before inetd
    before xinetd

Because there are a group of Linux users out there who are more interested in creating a desktop-OS than a Unix-OS.

Honestly, at this point, why not rename SystemD to svchost.exe and set it up to use .reg files for configuration?

It thought that was Pulseaudio. Oh wait, same developer.

The one thing it does do is push responsibility for init scripts off of package maintainers onto upstream. Which explains it, I believe.

> It uses nsswitch to basically take over gethostbyname() and getaddrinfo(). This means any software using a DNS library like ldns, unbound, bind, knot, etc bypasses this system and gets an inconsistent DNS view from the rest of the system. It explicitly does not support those kind of applications.

> It won't work well with applications that have their own DNS code inside. Such as browsers.

The systemd developers have addressed M. Wouters' charges as follows. Such applications are classed as

> legacy software which does not use libnss-resolve

-- https://github.com/systemd/systemd/issues/3420#issuecomment-...


> legacy DNS clients

-- https://github.com/systemd/systemd/issues/3420#issuecomment-...

The systemd developers maintain that

> programs really should use NSS (with nss-resolve as backend) or resolved's native bus APIs, but not talk DNS themselves.

-- https://github.com/systemd/systemd/issues/3420#issuecomment-...

It's interesting to contrast Paul Wouters' dismissal of source port randomization with the conversation on the Ubuntu mailing list with Martin Pitt, the systemd developer and Ubuntu systemd maintainer whose announcement precipitated M. Wouters' critique.

> > source port randomization is enabled by default to further protect against DNS spoofing attacks.

> [...] source port randomization is pretty useless [...]

-- Paul Wouters, https://lists.dns-oarc.net/pipermail/dns-operations/2016-Jun...

> ATM resolved uses randomized ID fields [...]. It does not use source port randomization though,

-- Martin Pitt, https://lists.ubuntu.com/archives/ubuntu-devel/2016-May/0393...

> I'm concerned what this says about the maturity of the project: djbdns introduced source port randomization back in 1999.

-- Seth Arnold, https://lists.ubuntu.com/archives/ubuntu-devel/2016-May/0393...

Wouters dismissal seems to be related to resolved being a LAN DNS only.

> ... as you are most likely just doing DNS on the local network.

It is the predication on something that M. Pitt says isn't the case that provides the contrast, however.

What are some good resources for getting up to speed with systemd quickly for a web dev who didn't do extensive Linux administration besides setting up hosting on EC2 instances with nginx and REST API controlled by supervisor (software)?

sudo systemctl stop systemd-resolved sudo systemctl disable systemd-resolved

After that you can use whatever you like.

My new dev/deploy target is freebsd. It's actually kinda nice. It treats the user with respect and doesn't pretend to know better.

Systemd sounds good in theory until you cannot disable systemd-journald and it grows to 50M RAM. And out of nowhere dozens of gvfsd* processes are spawned for no apparent reason.

Debian anyone?

Debian 8 comes with systemd. There is a fork [1], but not really popular.

[1] https://devuan.org/

it'd be funny to fork devuan and replace init with systemd.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact