Live data from Hacker News

Systemd v218

lists.freedesktop.org

11–20 of 65 posts

Re: Systemd v218

#11

Why should an init.d replacement have something even remotely to do with PPPoE? What ever happened to orthogonal design?

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.

Re: Systemd v218

#12

Why should an init.d replacement have something even remotely to do with PPPoE? What ever happened to orthogonal design?

It doesn't.

Systemd's pid 0 process does not do anything with or about PPPoE. Networkd does. Networkd is a daemon which manages the network configuration and PPPoE makes sense in that context.

Re: Systemd v218

#13
post #10
post #7

Earlier quoted context omitted.

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

Maybe systemd as a project should try a rebranding campaign. The init daemon is only one of its many tools now.

This still smells funny. The fact that the whole project is handle as one may make the communication between developers and also program component too easy (coupling). Personally I'm a bit overwhelmed by all the 'special strings', flags and options added at each release.

Re: Systemd v218

#14
post #12

Why should an init.d replacement have something even remotely to do with PPPoE? What ever happened to orthogonal design?

It doesn't. Systemd's pid 0 process does not do anything with or about PPPoE. Networkd does. Networkd is a daemon which manages the network configuration and PPPoE makes sense in that context.

But can networkd operate without systemd sitting as pid0?

Btw, that very line is why we have these debates. There is no clear way to indicate if you are talking about just the init part or the whole of systemd. This in large part because the name has stayed while the goals have constantly shifted.

And sometimes i wonder if the proponents wants it this way, as they can play the "superior" card by constantly "correcting" detractors on the difference. Fueling further the impression that the discussion is not technical but political...

Re: Systemd v218

#15
post #6

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

systemd - the emacs of init systems.

Not at all. Emacs is significantly extensible. systemd has no notion of a plugin or module system, or anything like that. Other init schemes do, though.

Re: Systemd v218

#16
post #10
post #7

Earlier quoted context omitted.

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

Maybe systemd as a project should try a rebranding campaign. The init daemon is only one of its many tools now.

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

Re: Systemd v218

#17

Why should an init.d replacement have something even remotely to do with PPPoE? What ever happened to orthogonal design?

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

Re: Systemd v218

#18

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…

> So it's trying to obsolete the Linux distribution?

You say it like that would be a bad thing.

Re: Systemd v218

#19
post #6

Earlier quoted context omitted.

systemd - the emacs of init systems.

Not at all. Emacs is significantly extensible. systemd has no notion of a plugin or module system, or anything like that. Other init schemes do, though.

Systemd has a DBus API. http://www.freedesktop.org/wiki/Software/systemd/dbus/

Re: Systemd v218

#20

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.

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 approach of Linux, is definitely a good thing. Trying to erect unshakable foundations around what is just an OS kernel will only stifle the marketplace of ideas.

Of course, wanting a fully integrated OS is most certainly not a bad thing. This can be done either by using a BSD, or on the individual distribution level if it's sufficiently advanced.

Post reply on HN