
Systemd 216 released including DNS resolver and full TTY stream parsing - anon1385
http://lists.freedesktop.org/archives/systemd-devel/2014-August/022295.html
======
vezzy-fnord
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.

~~~
FedRegister
It sounds more like they're trying to implement the *BSD userland in systemd
so it's available on boot.

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!

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

~~~
viraptor
> 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.

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

~~~
viraptor
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".

~~~
derefr
I would guess making DNS resolution follow connection paths means DNS-over-Tor
becomes something that just happens automatically.

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

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

1) [http://lists.freedesktop.org/archives/systemd-
devel/2013-Nov...](http://lists.freedesktop.org/archives/systemd-
devel/2013-November/014808.html)

2) [http://lwn.net/Articles/555922/](http://lwn.net/Articles/555922/)

------
ddalex
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 ?

~~~
evol262
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?

~~~
vezzy-fnord
Monolithic and modular aren't mutually exclusive.

~~~
evol262
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.

~~~
viraptor
> 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.

------
kolev
I have to agree with most points in here though:
[http://boycottsystemd.org/](http://boycottsystemd.org/)

------
nilved
Will version 217 make me tea and drive my car?

~~~
viraptor
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 ;)

~~~
nilved
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.

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

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

~~~
bkor
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.

------
allegory
systemd can just fuck off.

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.

~~~
kirab
How is BSD less monolithic than systemd?

~~~
Sanddancer
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.

------
ausjke
Since I have no plan to have anything to do with systemd, just hope that
systemd will not become mandatory for linux system over time. Wish me luck.

~~~
ausjke
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?

------
strictfp
Systemd henceforth considered harmful in many ways

------
0xndc
This seems just a bit excessive for an init system.

~~~
agildehaus
Good, because systemd isn't just an init system.

~~~
worklogin
Too bad that's how it was sold.

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

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

------
agumonkey
systemd now includes its own april fools implementation which runs on 20th
August.

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

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

~~~
bkor
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.

~~~
nknighthb
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.

------
vidoc
On track to beat Pulseaudio's record!

------
justizin
Awesome.

