Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd v218

lists.freedesktop.org

Post reply on HN
Print view View original

61–65 of 65 posts

Re: Systemd v218

#61

Post by EmanueleAina »

asveikau wrote: post #59
pantalaimon wrote: post #18

Earlier quoted context omitted.

> So it's trying to obsolete the Linux distribution? You say it like that would be a bad thing.

You and others speak as if nobody ever had a reason to make their distro work differently. That they're just all evildoers who change stuff for no reason. Maybe you can say there is some of that, or that it emerges as a net result, but in a lot of cases people have honest differences of opinion about the right thing to do. So if person 1 has idea A and person 2 has idea B, you're going to deny one of them to get thei…

Many of the current incompatibilities between distributions are not due to evil reasons but mostly historical ones. The vast majority of distribution maintainers, ie. those who should care most about those differencies, already think that it should be time to get rid those differencies and this is the reason systemd has seen such widespread adoption.

Package management is already a sufficiently big differentiator that there's no need for separate network configuration systems.

Re: Systemd v218

#62

Post by EmanueleAina »

digi_owl wrote: post #46
Symmetry wrote: post #36

Earlier quoted context omitted.

I think he's asking if you could launch networkd from, say, a traditional init or Upstart. EDIT: Or if not, that's what I'm curious about.

Bingo. No other init but systemd has a sprawling set of sub-daemons that duplicate existing daemons for features (but not interfaces), and insist on only working with systemd as the running init.

No, networkd relies on systemd udev integration and unit activation system.

Since systemd needed a way to understand networking enough to activate units only on certain network settings (no need to fire up avahi if no real network interfaces are available) factoring out a daemon to react to devices coming and going to configure them wasn't too much work.

You may thing that networkd duplicates some NetworkManager features, but it's a rather different, lower-level beast and they can work together just fine.

I'm not sure which other daemons systemd duplicates, care to elaborate?

timesyncd does not duplicate ntpd, it is just a client daemon (it's closer to a daemonised ntpdate), hostnamed, localed, machined do not duplicate anything, logind is the ConsoleKit successor addressing the known, unfixable issues in the latter.

timesyncd, hostnamed, localed may arguably be made to work on non-systemd systems with little effort (as they already do in the systemd-shims package), logind relies on the systemd-as-pid1 due to the need to set up cgroups (in preparation to the single hierarchy change planned by kernel people) but with some more work it can be made to work without systemd (see the systemd-shims package again). I'm not sure if networkd is shipped by systemd-shims, let me know if you care enough to check.

Re: Systemd v218

#63

Post by asveikau »

EmanueleAina wrote: post #61
asveikau wrote: post #59

Earlier quoted context omitted.

You and others speak as if nobody ever had a reason to make their distro work differently. That they're just all evildoers who change stuff for no reason. Maybe you can say there is some of that, or that it emerges as a net result, but in a lot of cases people have honest differences of opinion about the right thing to do. So if person 1 has idea A and person 2 has idea B, you're going to deny one of them to get thei…

Many of the current incompatibilities between distributions are not due to evil reasons but mostly historical ones. The vast majority of distribution maintainers, ie. those who should care most about those differencies, already think that it should be time to get rid those differencies and this is the reason systemd has seen such widespread adoption. Package management is already a sufficiently big differentiator tha…

> The vast majority of distribution maintainers, ie. those who should care most about those differencies, already think that it should be time to get rid those differencies

Sounds made up.

> and this is the reason systemd has seen such widespread adoption.

It seems more like a few very influential players are in favor and the smaller people must follow suit if they want to be compatible. The latter part doesn't seem nearly as voluntary as you suggest.

Re: Systemd v218

#64

Post by drdaeman »

digi_owl wrote: post #56
drdaeman wrote: post #55

Earlier quoted context omitted.

Why not just spawn pppd from networkd? They can write a full-fledged pppd replacement, but can't just have pppd as a child process and happily control it? (May possibly need a tiny patch or two, but that's barely an issue) I'd get it if one needs some very tight integration, but pppd is self-sufficient, fairly controllable and well-tested. Looks like NIH syndrome to me. But maybe I'm missing something from the pictur…

I'm no insider, so all i can say is that i suspect http://ewontfix.com/15/ holds the key. Existing pppd would have to be using one of simple, forking, oneshot or idle to indicate that it is up. And quite possible they have deemed that too unreliable for whatever use case they have. The other options would be to modify the existing pppd to use dbus or notify. And at that point they may well have gone with reimplementi…

My memory is a bit blurry, but IIRC with `nodetach` option pppd would fit "simple" category or its derivatives well.

Teaching it to notify via dbus is as trivial as passing a bunch of `connect /usr/lib/networkd/ppp/ip-down`-type options or writing a simple plugin library to do dbus messaging or `sd_notify` calls. Available plugin API hooks should allow for anything necessary to have a good understanding of pppd's state and provide a good amount of control over it (link state changes, authentication, IP address negotiation, idling etc) when necessary: http://ftp.samba.org/pub/unpacked/ppp/PLUGINS

I'm almost certain there's no need to write a whole new pppd from scratch.

Re: Systemd v218

#65

Post by EmanueleAina »

asveikau wrote: post #63
EmanueleAina wrote: post #61

Earlier quoted context omitted.

Many of the current incompatibilities between distributions are not due to evil reasons but mostly historical ones. The vast majority of distribution maintainers, ie. those who should care most about those differencies, already think that it should be time to get rid those differencies and this is the reason systemd has seen such widespread adoption. Package management is already a sufficiently big differentiator tha…

> The vast majority of distribution maintainers, ie. those who should care most about those differencies, already think that it should be time to get rid those differencies Sounds made up. > and this is the reason systemd has seen such widespread adoption. It seems more like a few very influential players are in favor and the smaller people must follow suit if they want to be compatible. The latter part doesn't seem…

If you believe that this sounds made up you don't have to trust me, check directly with them in the appropriate venues (ie. IRC or mailing lists). Most of the Debian Developers I know are quite sure that how to configure network interfaces is definitely not the most awesome distribution differentiator, and are seriously aware of the big limitations of the current solution.

Also I don't know who you're referring to with "influential players" vs. "smaller people". How such "influential players" are forcing "smaller people" to do things they don't want? Care to elaborate?

Post reply on HN