7 ms·

Systemd 216 released including DNS resolver and full TTY stream parsing

54 points by anon1385 12y ago

justizin 12y ago
Awesome.
0xndc 12y ago
This seems just a bit excessive for an init system.
- agildehaus 12y ago
  Good, because systemd isn't just an init system.
  - allegory 12y ago
    Which is the problem. Edit: I can see the systemd love is strong in here...
  - worklogin 12y ago
    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!"
AceJohnny2 12y ago
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 12y ago
  > 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 12y ago
    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 12y ago
      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 12y ago
        I would guess making DNS resolution follow connection paths means DNS-over-Tor becomes something that just happens automatically.
- dmm 12y ago
  systemd offers great features but they all come as a part of the same giant ball of mud. Look at what happened to udev. In 2012 the udev codebase was added to the systemd source tree. At the time it was promised that using udev separately would continue to be supported[1]. Once kdbus is merged into the kernel using udev without systemd will amount to implementing a separate userspace kdbus[2]. This is happening with the release of 3.17 this year. Nothing will be broken out. systemd is a blackhole. Nothing escapes. systemd is good and useful but the trend here is clear. [1] http://article.gmane.org/gmane.linux.hotplug.devel/17392 http://article.gmane.org/gmane.linux.hotplug.devel/17392 [2] http://www.phoronix.com/scan.php?page=news_item&px=MTczNjI http://www.phoronix.com/scan.php?page=news_item&px=MTczNjI
kbar13 12y ago
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 12y ago
  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 12y ago
    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.
vidoc 12y ago
On track to beat Pulseaudio's record!
ddalex 12y ago
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 ?
- srslack 12y ago
  >Package management should be done through a central place where application can be vetoed, like an app store. There's no need, https://en.wikipedia.org/wiki/PackageKit https://en.wikipedia.org/wiki/PackageKit exists >Monolithic* software is always better than small separate tools that do only one thing, right? Even in the linked post, it's referencing seperate daemons that "do one thing."
- evol262 12y ago
  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 12y ago
    Monolithic and modular aren't mutually exclusive.
    - evol262 12y ago
      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.
namecast 12y ago
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.
strictfp 12y ago
Systemd henceforth considered harmful in many ways
agumonkey 12y ago
systemd now includes its own april fools implementation which runs on 20th August.
vezzy-fnord 12y ago
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 12y ago
  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!
nilved 12y ago
Will version 217 make me tea and drive my car?
- deleted 12y ago
  [deleted]
- viraptor 12y ago
  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 ;)
  - allegory 12y ago
    RMS will jump in and it'll be GNU/Linux/SystemD
  - nilved 12y ago
    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.
kolev 12y ago
I have to agree with most points in here though: http://boycottsystemd.org/ http://boycottsystemd.org/
allegory 12y ago
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 12y ago
  How is BSD less monolithic than systemd?
  - allegory 12y ago
    https://www.freebsd.org/cgi/man.cgi?rc%288%29 https://www.freebsd.org/cgi/man.cgi?rc%288%29
  - Sanddancer 12y ago
    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.
peterwwillis 12y ago
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.
ausjke 12y ago
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 12y ago
  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?
cwyers 12y ago
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-November/014808.html http://lists.freedesktop.org/archives/systemd-devel/2013-Nov... 2) http://lwn.net/Articles/555922/ http://lwn.net/Articles/555922/

54 points by anon1385 12y ago

justizin 12y ago

Awesome.

0xndc 12y ago

This seems just a bit excessive for an init system.

agildehaus 12y ago
Good, because systemd isn't just an init system.
- allegory 12y ago
  Which is the problem. Edit: I can see the systemd love is strong in here...
- worklogin 12y ago
  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!"

AceJohnny2 12y ago

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 12y ago
> 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 12y ago
  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 12y ago
    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 12y ago
      I would guess making DNS resolution follow connection paths means DNS-over-Tor becomes something that just happens automatically.
dmm 12y ago
systemd offers great features but they all come as a part of the same giant ball of mud. Look at what happened to udev. In 2012 the udev codebase was added to the systemd source tree. At the time it was promised that using udev separately would continue to be supported[1]. Once kdbus is merged into the kernel using udev without systemd will amount to implementing a separate userspace kdbus[2]. This is happening with the release of 3.17 this year. Nothing will be broken out. systemd is a blackhole. Nothing escapes. systemd is good and useful but the trend here is clear. [1] http://article.gmane.org/gmane.linux.hotplug.devel/17392 http://article.gmane.org/gmane.linux.hotplug.devel/17392 [2] http://www.phoronix.com/scan.php?page=news_item&px=MTczNjI http://www.phoronix.com/scan.php?page=news_item&px=MTczNjI

kbar13 12y ago

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

vidoc 12y ago

On track to beat Pulseaudio's record!

ddalex 12y ago

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 ?

srslack 12y ago
>Package management should be done through a central place where application can be vetoed, like an app store. There's no need, https://en.wikipedia.org/wiki/PackageKit https://en.wikipedia.org/wiki/PackageKit exists >Monolithic* software is always better than small separate tools that do only one thing, right? Even in the linked post, it's referencing seperate daemons that "do one thing."
evol262 12y ago
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 12y ago
  Monolithic and modular aren't mutually exclusive.
  - evol262 12y ago
    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.

namecast 12y ago

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.

strictfp 12y ago

Systemd henceforth considered harmful in many ways

agumonkey 12y ago

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

vezzy-fnord 12y ago

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 12y ago
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!

nilved 12y ago

Will version 217 make me tea and drive my car?

deleted 12y ago
[deleted]
viraptor 12y ago
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 ;)
- allegory 12y ago
  RMS will jump in and it'll be GNU/Linux/SystemD
- nilved 12y ago
  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.

kolev 12y ago

I have to agree with most points in here though: http://boycottsystemd.org/ http://boycottsystemd.org/

allegory 12y ago

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 12y ago
How is BSD less monolithic than systemd?
- allegory 12y ago
  https://www.freebsd.org/cgi/man.cgi?rc%288%29 https://www.freebsd.org/cgi/man.cgi?rc%288%29
- Sanddancer 12y ago
  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.

peterwwillis 12y ago

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.

ausjke 12y ago

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 12y ago
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?

cwyers 12y ago

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-November/014808.html http://lists.freedesktop.org/archives/systemd-devel/2013-Nov... 2) http://lwn.net/Articles/555922/ http://lwn.net/Articles/555922/