First of all, there are two types of German engineering. Good engineering and over engineering. And there is a fine line between them. And it looks like Mr. Poettering crossed it. However, it could also be German advertising and that is either bad or worse. In general, you do not build bloated components. In old Unix days these where called programs and could be combined in various ways including pipes and files. In GNU days many of these programs were bundled together in one archive, but stayed separate. Now with systemd I am puzzled, is he really integrating that thing in the init system? Integrating something which does not belong to a init system? In that case he is nuts and definitely over engineering. Or he has just created a new program and just bundles it in the same package as systemd. Then this is acceptable, however, a little weird. It would be like bundling systemd with a sound service. Session separation or VM separation is a task of the operating system. And you may write any number of tool to call the necessary OS functions, but PLEASE keep them out of components which have nothing to do with that.
What do you mean by process manager? The OS kernel manages processes and threads. I know certain term in CS are used differently in multiple contexts. However, in domain close to the OS kernel, confusion should be avoided.
The OS kernel really do much to manage process and threads. Consider this example: A is a daemon which depends on B which depends on C. C encounters a problem and needs to restart. What should the system do about A? Linux prior to systemd lacked any standards for this and every daemon had to handle this sort of thing on its own on top of init.
Let's make it worse. Assume A is going to follow process B's lead and process B needs to know why C crashed to decide what to do. a) How does process B find out w
"It would be like bundling systemd with a sound service."
Lennart created or was a significant early contributor to the Pulse audio project, so I won't be surprised if the sound service was already bundled with systemd.
The road to ruin is always in good repair, and the travellers pay the
expense of it.
-- Josh Billings
Strange path he is taking (Score:2)
First of all, there are two types of German engineering. Good engineering and over engineering. And there is a fine line between them. And it looks like Mr. Poettering crossed it. However, it could also be German advertising and that is either bad or worse. In general, you do not build bloated components. In old Unix days these where called programs and could be combined in various ways including pipes and files. In GNU days many of these programs were bundled together in one archive, but stayed separate. Now with systemd I am puzzled, is he really integrating that thing in the init system? Integrating something which does not belong to a init system? In that case he is nuts and definitely over engineering. Or he has just created a new program and just bundles it in the same package as systemd. Then this is acceptable, however, a little weird. It would be like bundling systemd with a sound service. Session separation or VM separation is a task of the operating system. And you may write any number of tool to call the necessary OS functions, but PLEASE keep them out of components which have nothing to do with that.
Re: (Score:1)
" Then this is acceptable, however, a little weird. It would be like bundling systemd with a sound service."
then THIS happens:
Then this is acceptable, however, a little weird. It would be like combining systemd with a sound service.
... it will be YOUR fault!!
Re: (Score:2)
systemd is not an init system. It is a process manager. Initialization is just one state it has to manage.
Re: (Score:2)
What do you mean by process manager? The OS kernel manages processes and threads. I know certain term in CS are used differently in multiple contexts. However, in domain close to the OS kernel, confusion should be avoided.
Re: (Score:2)
The OS kernel really do much to manage process and threads. Consider this example: A is a daemon which depends on B which depends on C. C encounters a problem and needs to restart. What should the system do about A? Linux prior to systemd lacked any standards for this and every daemon had to handle this sort of thing on its own on top of init.
Let's make it worse. Assume A is going to follow process B's lead and process B needs to know why C crashed to decide what to do.
a) How does process B find out w
From the same developer who created Pulse audio (Score:2)
"It would be like bundling systemd with a sound service."
Lennart created or was a significant early contributor to the Pulse audio project, so I won't be surprised if the sound service was already bundled with systemd.