Systemd Is Working Towards Its Own Super Fast DHCP Server, Client

[curaga]

"Everyone" who does a serious networking daemon needs to 'reinvent' a DHCP server (as outlined above, there are usecases even if you just use it in a limited setting). But 'reinvent' is a pretty strong word. We are just talking about implementing a specification, a pretty simple one at that. My current DHCP server code is 500 lines of code, so we are not talking about some monstrosity here. If you don't want to use networkd for your networking needs, that's fine, it is optional, but trying to say that we should not have this or that feature in networkd doesn't make much sense (unless you have some very good reasons).

You know what is the response to that. It starts with "implying it was necessary to reinvent a serious networking daemon".

[uid313]

while i agree on most, last 3 remarks are valid for unix, not linux. only people who didn't realized that fact, promote them. linux would already break all those 3 rules by monolithic kernel.

"Do one thing and do it well" is Unix philosophy.
Separation of concerns is not Unix philosophy, it is a general design principle.
Single responsibility principle is not Unix philosophy, it is a object-oriented design best practice.

[erendorn]

"Do one thing and do it well" is Unix philosophy.
Separation of concerns is not Unix philosophy, it is a general design principle.
Single responsibility principle is not Unix philosophy, it is a object-oriented design best practice.

And so "1 binary for 1 purpose" is somehow in contradiction with these principles?
I don't get it.

[justmy2cents]

"Do one thing and do it well" is Unix philosophy.
Separation of concerns is not Unix philosophy, it is a general design principle.
Single responsibility principle is not Unix philosophy, it is a object-oriented design best practice.

and all point to "do one thing and do it well" which is basis of unix philosophy and sound/solid development practice (other 2 are nothing but calling boot... trunk and repeating 1st rule in different context. you unfortunately reused all 3 in the same).

but, more importantly, was any of those... founding principle of linux which must be followed? kernel would disagree

[uid313]

And so "1 binary for 1 purpose" is somehow in contradiction with these principles?
I don't get it.

No, but my point is that it is not just some Unix thing.
It is not limited to Unix only.

This is for Linux (and all other high quality projects) to follow.

[Ericg]

No, but my point is that it is not just some Unix thing.
It is not limited to Unix only.

This is for Linux (and all other high quality projects) to follow.

This IS "do one thing and do it well", Curaga. Its you and a couple other people around here who can't seem to wrap your head around the idea that Systemd (project) and systemd (PID 1 binary) are two different things. This is about extending systemd-networkd, not systemd.

[V10lator]

Do one thing and do it well, anyone?

You might want to read: http://www.johndcook.com/blog/2010/0...y-breaks-down/

[justmy2cents]

You might want to read: http://www.johndcook.com/blog/2010/0...y-breaks-down/

actually, that article is flawed BS, well at least in 2010 when it was published, but it would be correct in 80's. author assumes "ls | grep something" as the only implementation of "do one thing and do it well". meantime, times have passed and modularizing something can take very different forms.

stream piping in command line is just oldest trick in the book
microkernel for example... each module follows exactly "do one thing and do it well" while communication follows its internal protocol on how to dispatch data
various ipcs, where i'll name dbus... offers introspective data communication from one app to another and with kdbus when we get 0copy this will be even more so effective way to follow that rule since it will enable to pass large data without tragic loss of performance to follow unix rule

now, funny thing is if you look at systemd as you should. but, 1st the problem of systemd where this article actually gave me other idea on the problem

1st and most common misconception is the part where project was unfortunately named really poor, there is project called systemd and pid1 called systemd which often leads to confusion to anyone who didn't delve deeper to not know which one they refer to. just naming project something like systemd-project would avoid that naming inconsistancy, since it would contain systemd subproject which is actually pid1. other like networkd, hostnamed would then become visible as separate services. so, how could anyone right now discern this title "systemd implementing someultraserviced"? by normal, in head it connects to pid1 unfortunatelly instead of project since he runs systemd. that is why so many people think systemd-journald is something they are forced to run, instead of thinking... hey, it's a service i can disable it http://forums.fedoraforum.org/showthread.php?t=292543

now, the 2nd funny part once you understand the naming misfortune
- systemd pid1 is actually pretty small and has exact plan on what it does and what it doesn't. ok, that's more or less unix like
- services (at least most up until now) publish dbus spec of how they behave and what they do to serve exact following of unix principle

as far as i see there is only one problem present in systemd beside poorest naming of the project. no clear definition when do you stop reinventing the wheel under systemd services umbrela

[finalzone]

You might want to read: http://www.johndcook.com/blog/2010/0...y-breaks-down/

Even better: http://lwn.net/Articles/576078/

One of the big weaknesses of the "do one job and do it well" approach is that those individual tools didn't really combine very well. sort, join, cut, paste, cat, grep, comm etc make a nice set of tools for simple text-database work, but they all have slightly different ways of identifying and selecting fields and sort orders etc. You can sort-of stick them together with pipes and shell scripts, but it is rather messy and always error prone.

[V10lator]

actually, that article is flawed BS

The article contains quotes from Doug McIlroy, the one who also wrote the Unix philosophy. So are you implying that he talks BS about his own philosophy?

author assumes "ls | grep something" as the only implementation of "do one thing and do it well".

It's just an example. Most likely inspired by this quote, which is also part of the philosophy: "Write programs to handle text streams, because that is a universal interface."

now, funny thing is if you look at systemd as you should.

I guess we agree here: Systemd does follow the Unix philosophy.

1st and most common misconception is the part where project was unfortunately named really poor, there is project called systemd and pid1 called systemd which often leads to confusion to anyone who didn't delve deeper to not know which one they refer to.

But this has nothing to do with the Unix philosophy. Confused users are, well, confused users. They should stop talking if they don't understand what they are talking about.

Anyway, one more article why Unix philosophy is broken: http://lwn.net/Articles/576078/