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

51–60 of 65 posts

Re: Systemd v218

#51

Post by digi_owl »

UnoriginalGuy wrote: post #27
vezzy-fnord wrote: post #20

Earlier quoted context omitted.

systemd is targeting the totally wrong layer of the stack for such a thing. What makes a distribution is its package manager. We already have solutions like Nix for this, though they sadly might not break the mainstream if Lennart's proposed btrfs volume scheme comes into fruition. I'd say that experimentation and divergence in systems and application software, particularly if it's easily enabled thanks to the bazaar…

There's no reason third party components couldn't slot into systemd. It is quite modular. It is just a different method of intercommunication, not the end of intercommunicating modular components.

Who do i hear Hotel California playing in my head?

Re: Systemd v218

#52

Post by digi_owl »

sztanpet wrote: post #7
davecheney wrote: post #5

When will this madness stop? Will systemd not be satisfied til it has subsumed the universe into one great pid 1 singularity?

I think you are mistaking systemd pid1 and systemd the project, this is not in pid1 but in the networkd component.

I have come to suspect that the systemd devs are fueling that confusion, so that debates can disintegrate into a mess of arguments over semantics.

Re: Systemd v218

#53

Post by digi_owl »

panzi wrote: post #34
stefantalpalaru wrote: post #16

Earlier quoted context omitted.

Yeah, they should call it "Linux for Workgroups".

That name is already taken: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...

Would not be the first time systemd has overloaded something kernel related...

Re: Systemd v218

#54

Post by drdaeman »

eggnet wrote: post #37
drdaeman wrote: post #26

Earlier quoted context omitted.

I'm worried about "without an external pppd daemon" part. There's no point in PPPoE without PPP. And if they say "without external pppd" this means they're going to ship a full-fledged PPP daemon.

The linux kernel has had native PPPoE support since 2.4. https://wiki.debian.org/PPPoE

Yes, that's the difference with rp-pppoe.so (using kernel module to handle encapsulation, userspace code only sets up the sockets) and pppd's pty option (got it a bit wrong in my other comment in this thread, believed it's a pipe, thanks for correcting) with separate process to do so. It doesn't really matter.

More than this, Linux kernel has kernel-mode PPP. But still a few parts of PPP, and all accompanying control protocols (especially authentication-related ones like EAP - you don't want that beast in the kernel!) are done in userspace.

Re: Systemd v218

#55

Post by drdaeman »

digi_owl wrote: post #49
drdaeman wrote: post #24

I don't get it (and don't want to download and read systemd source). Could someone explain? The docs say: > native PPPoE library has been added to sd-network, systemd's library of light-weight networking protocols. This library will be used in a future version of networkd to enable PPPoE communication without an external pppd daemon. (emphasis mine) Usually, it works like this - a separate entity (either as a separat…

Likely the existing pppd don't play well with systemd's automagical detection of network status, and the unit files that depend on that.

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 picture and pppd isn't a good fit. Then, okay.

Re: Systemd v218

#56

Post by digi_owl »

drdaeman wrote: post #55
digi_owl wrote: post #49

Earlier quoted context omitted.

Likely the existing pppd don't play well with systemd's automagical detection of network status, and the unit files that depend on that.

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 reimplementing the parts of ppp they need for their existing use case.

Re: Systemd v218

#57

Post by asveikau »

digi_owl wrote: post #50
vezzy-fnord wrote: post #20

Earlier quoted context omitted.

systemd is targeting the totally wrong layer of the stack for such a thing. What makes a distribution is its package manager. We already have solutions like Nix for this, though they sadly might not break the mainstream if Lennart's proposed btrfs volume scheme comes into fruition. I'd say that experimentation and divergence in systems and application software, particularly if it's easily enabled thanks to the bazaar…

Poettering has already laid out his vision for obsoleting package managers. Thinks Docker style containers, applied to the whole distro. Every lib or program put in its own BTRFS based container image, and via union mount magic (managed by systemd, natch) "always" (looking forward to the blog entries about its failures) given a proper run time environment.

Sounds like an idea that functions well in a niche and seems like complete nonsense in others.

The great thing about the historical diversity in Linux is that, contrary to the complaints of "pointless" differences by folks in this thread, the various distros represent honest differences of opinion about what's good in a system. If you want to do silly things with loopback mounts and containers, there's room for that in the universe, but it would be wrong to impose it on those who don't want or need it.

Re: Systemd v218

#58

Post by asveikau »

vezzy-fnord wrote: post #17
sztanpet wrote: post #11

Earlier quoted context omitted.

You are also conflating the "init.d" replacement with the project that is aiming to provide basic OS building blocks. networkd is quite orthogonal to pid1, what it is not orthogonal to is that nowadays almost every system needs network connectivity so bringing up the network is part of the basic system. And systemd (the project) is trying to be the basic building blocks from which you can build an OS out of.

basic OS building blocks Is a meaningless phrase. bringing up the network is part of the basic system I'm not even sure what the implication is here. That such a thing was not possible before systemd? And systemd (the project) is trying to be the basic building blocks from which you can build an OS out of. So it's trying to obsolete the Linux distribution? You're going to have to define some terminology first, I'm af…

I think you hit it on the head to point out that the phrase is meaningless. The whole systemd phenomenon is very Freudian, right down to its name, it's as if systemd fans seek a single component to point at and call "the system", to worship as pater familias. "The system" will not only free you from being precise about what components serve what purpose, it will end all arguments and bring order to their lives in a way that decentralized purpose built components will not.

Maybe they should just use OS X and be done with it.

Re: Systemd v218

#59

Post by asveikau »

pantalaimon wrote: post #18
vezzy-fnord wrote: post #17

Earlier quoted context omitted.

basic OS building blocks Is a meaningless phrase. bringing up the network is part of the basic system I'm not even sure what the implication is here. That such a thing was not possible before systemd? And systemd (the project) is trying to be the basic building blocks from which you can build an OS out of. So it's trying to obsolete the Linux distribution? You're going to have to define some terminology first, I'm af…

> 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 their problem solved simply because they are scratching at the same itch from two angles? Sounds kind of like software fascism to me.

Re: Systemd v218

#60

Post by EmanueleAina »

vezzy-fnord wrote: post #17
sztanpet wrote: post #11

Earlier quoted context omitted.

You are also conflating the "init.d" replacement with the project that is aiming to provide basic OS building blocks. networkd is quite orthogonal to pid1, what it is not orthogonal to is that nowadays almost every system needs network connectivity so bringing up the network is part of the basic system. And systemd (the project) is trying to be the basic building blocks from which you can build an OS out of.

basic OS building blocks Is a meaningless phrase. bringing up the network is part of the basic system I'm not even sure what the implication is here. That such a thing was not possible before systemd? And systemd (the project) is trying to be the basic building blocks from which you can build an OS out of. So it's trying to obsolete the Linux distribution? You're going to have to define some terminology first, I'm af…

"Basic OS building blocks" means that systemd aims to provide low-level tools that you can reliably depend on across distributions. In particular those pieces that are currently implemented through distribution-specific init scripts of various quality and robustness.

Network configuration in particular varies greatly from distribution to distribution, having a common, shared system would be a great improvement over the status quo.

Post reply on HN