Users/Developers Threatening Fork Of Debian GNU/Linux

[gens]

Hum, not clear to me. I knew systemd managed dependencies slightly differently from upstart, but to be honest I don't know the actual difference.
Is that linked to socket activation? (when talking to a service, input is queued until service ready, service is started, service talks to dependency service 2, repeat for service 2)?

that was my thought as well

note that i thought about socket activation for use in an init
in practice (best case) it is no where near how it is explained on the blog (blog explains it as "start everything at once and let it resolve itself")
well.. it can be in general, but there are many details that basically make it the same as the "double fork then exit the first fork when ready to provide the service or exit with error if, well, error" approach that almost all daemons do anyway (i think udev doesn''t)

[Tentacle]

Step 1: Come up with a definition of ``one thing''.

That is open to interpretation, indeed. Take a look at the modern flagship product of the UNIX world: the ZFS. It's a filesystem in the strict sense + volume manager + RAID + snapshotter + backup thing, all rolled into one monolithic "one thing" binary. You can't take out one subelement and use it elsewhere standalone, like you can with, for example, mdadm + lvm + ext4 (or if you're using BSD, geom + vinum + ufs + whatever the counterparts are)

[darkcoder]

systemd has its good and bad releases like all software, but I personally haven't encounter a systemd bug that blocked my system or became so annoying that had no other choice that to install something else. Got those kind of bugs in kernels (around 2 years ago all distributions released with the same kernel refuse to boot), on desktops (KDE 4 early days crash extravaganza), but not with systemd.

Also if systemd wasn't stable enough for the Enterprise, RedHat will not have it included in RHEL 7.

<Sarcasm>
Do a single job and do it well, then I have 2 examples of single job getting done:
* then Bash with the latest 10y bug wasn't doing it right
* OpenSSL library with their bugs, among other things that end up with a fork
</Sarcasm>

[jrch2k8]

that was my thought as well

note that i thought about socket activation for use in an init
in practice (best case) it is no where near how it is explained on the blog (blog explains it as "start everything at once and let it resolve itself")
well.. it can be in general, but there are many details that basically make it the same as the "double fork then exit the first fork when ready to provide the service or exit with error if, well, error" approach that almost all daemons do anyway (i think udev doesn''t)

this article should clear some doubts about upstart and cgroups functionality

http://0pointer.de/blog/projects/systemd.html (the pid1 article is fairly complete)

[darkcoder]

Like people have commented, programs are adding systemd support to get the new features. While most of that software still has that support optional, the increasing market of systemd will only means that eventually those features in programs will became required.

My only concern is other markets like BSD, Mac. They will probably have to develop an alternative, since they cannot use systemd directly because of GPL. And yes, while currently systemd is not GPL-3 the one incompatible with BSD license, authors have the right to change it whenever they like. BSD end up with a problem with an old software with GCC, I really doubt they will take the same chance again with another GPL-2 software in their main app pool.

Also systemd indirectly have been doing something Linux Administrators and users asked a long time ago. Unify the way you deal with the system. Because damn companies keep moving and renaming configuration files and adding administration tools the way they think was correct, doing decisions sometimes against upstream developers.

And an offtopic conclusion. The open source community is killing itself. While competition is good, and having choices is good, spreading all that work between different smaller communities due to politics (license issues), egos, or reluctant to change (yes you are like those that hate Win8 because only the menu) is a waste of time, and coding resources.

[gens]

this article should clear some doubts about upstart and cgroups functionality

http://0pointer.de/blog/projects/systemd.html (the pid1 article is fairly complete)

as i said, that blog is extremely imprecise and some times just plain wrong
for example the (now missing) picture that shows how socket activation "works" did not explain in any way how socket activation works and was wrong (incomplete=wrong)
best case socket activation would mean a process runs its startup (__libc_start, reading configs and such) then waits for the process it depends on to start completely
it is practically the same as normal start up because it reading that config/locale/whatever files would make the other process it depends on to fully start start slower
edit: it would also mean nonlinear disk access

stop giving me links
especially ones to propaganda material

[TheBlackCat]

for example the (now missing) picture that shows how socket activation "works" did not explain in any way how socket activation works and was wrong (incomplete=wrong)
best case socket activation would mean a process runs its startup (__libc_start, reading configs and such) then waits for the process it depends on to start completely
it is practically the same as normal start up because it reading that config/locale/whatever files would make the other process it depends on to fully start start slower

How could the explanation be wrong if there wasn't an explanation?

[gens]

Unless the process it is waiting for has already started, in which case it doesn't have to wait. That is the big difference in terms of performance.

if the process already started then socket activation, again, brings nothing to the table
same "performance"
and as explained systemd starts things from root to leaves, not the other way around

[jrch2k8]

Like people have commented, programs are adding systemd support to get the new features. While most of that software still has that support optional, the increasing market of systemd will only means that eventually those features in programs will became required.

My only concern is other markets like BSD, Mac. They will probably have to develop an alternative, since they cannot use systemd directly because of GPL. And yes, while currently systemd is not GPL-3 the one incompatible with BSD license, authors have the right to change it whenever they like. BSD end up with a problem with an old software with GCC, I really doubt they will take the same chance again with another GPL-2 software in their main app pool.

Also systemd indirectly have been doing something Linux Administrators and users asked a long time ago. Unify the way you deal with the system. Because damn companies keep moving and renaming configuration files and adding administration tools the way they think was correct, doing decisions sometimes against upstream developers.

And an offtopic conclusion. The open source community is killing itself. While competition is good, and having choices is good, spreading all that work between different smaller communities due to politics (license issues), egos, or reluctant to change (yes you are like those that hate Win8 because only the menu) is a waste of time, and coding resources.

i would not worry about other markets because is all irracional fear from systemd opposition as the last stand argument when all else fails but the actual fact is Mac OS X will never use systemd and because they will most likely implement themselves in launchd the feature they like of systemd in their own kernel to keep control of it(remember quartz, core api, apple sound server, etc.) (i don't think that is wrong is their OS after all, so they can do whats best for them) and in the case of BSD i will not worry because they have their stack, their license, their init system, their package format, their repository format and any external attempt to change those have failed miserably and even the smallest detail of implementation between linux and BSD kernel developers end most of the time in 2 different implementations because they won't agree.

Even if you think application developers will suffer from using systemd specifics when porting to BSD, don't worry they do already since a long time ago because BSD API is similar but is not at the same time to linux code, so to port you need #ifdef everywhere anyway (try pass a file descriptor to sockets with the same code in BSD and Linux and you will get what i mean, is similar but not similar enough internally to avoid kernel specialisation)

[TheBlackCat]

How could the explanation be wrong if there wasn't an explanation?

For the record, as you can see this post was edited. gens replied to an earlier version, which as he correctly points out was wrong.