Debian Now Voting On Init System Coupling

[Scimmia]

udev lives in the same source tree as systemd.

udev and systemd used to be separate projects, living in separate source trees.
But now udev and systemd is married.

Wrong. Yes, they are in the same code tree, but the udev binary has absolutely no relationship to systemd. It it completely and totally separate and can be used with any init system.

[Guest]

Please explain me one thing about upstart - why many people claims that is has high code quality standards?

From my POV it's BS - because:
- it has only few kb's of tests
- even ubuntu AFAIK uses classic sysvinit scripts because upstart jobs cannot be parallelized and whole dependency system is broken

And yeah - systemd should have more tests that covers almost 100% of code - that's what I call high code quality standards.

[NotMine999]

Not So Sure The Ballot Was Well Written

Phoronix: Debian Now Voting On Init System Coupling

Debian's technical committee have moved onto voting over the operating system's default init system to now voting whether they should issue any guidance concerning the coupling of packages for specific init systems(s)...

http://www.phoronix.com/vr.php?view=MTYxMjY

After having read the Debian ballot posting at the URL included in the article, I am not so sure that the ballot was well written. I see and understand the "L" for "loose coupling" option. I see and understand the "N" for "no TC resolution" option. I see and understand the "FD" for further discussion option. Then I see and don't understand the "A" for "advice" option. Perhaps I am reading something into the ballot, or not, but the "L" and "A" options seem too similar to me. I would have proposed a "T" for "tight coupling" option and not the "A" for "advice" option. Perhaps this is Ian Jackson "being difficult" or "being obtuse" or whatever? I don't know.

I read the "L" option to say a package may depend or may not depend on a specific init system as PID1. I read the "N" option to say "don't bother us" or "we don't care" or "we don't have an opinion right now". I read the "FD" option to say "we want more time to discuss this". I read the "A" option to say about the same thing as the "L" option. So, I am not surprised that the "N" option is being chosen, but I would have hoped the technical committee would have taken a more honest and intellectual approach and voted in the direction of "FD". By voting "FD" they can hash out the problem they are trying to solve and hash out better ballot wording. By voting "N" they appear to be avoiding the issue at the moment (because I guess they could vote on this again at a later date) without saying so.

If I were a package maintainer I might say, "Direction? What direction? Sounds like I get to do as I please?"

[uid313]

If cost was the major concern, Mir or Upstart wouldn't exist in the first place. They chose to write new software that deviated from their upstream, incurring both development cost and package maintenance cost. They've now decided that Upstart isn't worth the continued cost, which tells me that even they don't believe in it as strongly as many of it's Internet proponents.

Canonical had no choice.
SysV init was a legacy, outdated piece of shit system.
If they wanted to be taken seriously and have Ubuntu Server be a serious contender in the enterprise they needed something better than SysV init, and since nothing existed back then, they had no choice to write it themselves.

It's really not feasible to turn off those extra features without writing entire new code paths. Basically an entire new system.

Maybe if it were written an interface that could be implemented by classes, and that methods and constructors took an interface (abstract type) instead of a concrete type as parameter.
But I don't know.

Software does not depend on systemd. It depends on a well documented, stable API that can be implemented anywhere. Upstart and systemd both implemented what was needed to keep compatibility with sysvinit scripts, systemd's successor will just do the same.

Then maybe that API interface should have been defined with input from Upstart and OpenRC and maybe standardized.

[Serge]

In regards to the voting: Due to the chairman's casting vote, I believe that it is mathematically impossible for any outcome other than "N: No TC resolution on this question at this time" to win regardless of how the last two TC members vote (unless the prior voters change their votes as well).

[GreatEmerald]

Yeap, as I mentioned in another thread, the voting is pretty much over and NOOP is the winner. It may not be so only if someone changes their vote.

In related news, I now started the third case of the discussions' adaptation in Ace Attorney format (this goes up to and including Watson's position statement). Here are the links to all three parts:
http://aceattorney.sparklin.org/jeu.php?id_proces=57684 - case 1
http://aceattorney.sparklin.org/jeu.php?id_proces=57899 - case 2
http://aceattorney.sparklin.org/jeu.php?id_proces=58428 - case 3

Whose burden is it to restore compatibility?

Is it the burden of the init system to provide an implementation of the logind service that desktop environments can use? Logind's public API is well documented.
Or is it the burden of the desktop environment to program specific solutions for other init systems that lack the required functionality?

Ian is trying to push the latter. No matter the upstream decision, maintainers have to add and maintain support - which is quite a lot to ask of a maintainer. Packages of new desktop environments cannot be added until they support multiple solutions.
This would of course relieve inferior init systems of the burden of stepping up and providing useful features. Ian would like that.

Well, actually you're not completely right. Jackson is pushing for either Debian's program maintainers (packagers) or Debian's systemd maintainers to add that support. Which makes it even more ludicrous. See my case 2, Allbery's cross-examination, one of the middle statements.

[kigurai]

Maybe if it were written an interface that could be implemented by classes, and that methods and constructors took an interface (abstract type) instead of a concrete type as parameter.
But I don't know.

You know, throwing these terms around does not really strengthen your point at all. It is painfully obvious that you have at best some minor programming experience.
Go write awesome code and learn things instead. That is way more useful.

[psychoticmeow]

With systemd, you get udev, logind, journald, etc.
It is one monolithic system with lots of dependencies.

How many times do people need to call you out on your bullshit before you stop posting it in every single systemd thread?

For a laugh, some idiot posted his conspiracy theory to the Debian mailing list: https://lists.debian.org/debian-ctte.../msg00569.html

He thinks that because the US Military has/had the largest installation of Red Hat Linux, that Red Hat is therefore aiding the NSA in spying. Yes, I'm sure Red Hat is going to compromise their software for all their other customers just because it suits the military, and therefore some shadowy nonsense, the NSA.

[gens]

How many times do people need to call you out on your bullshit before you stop posting it in every single systemd thread?.

what bullshit ?
try installing logind or udev or anything without systemd
try then insult, you idiot

[Scimmia]

what bullshit ?
try installing logind or udev or anything without systemd
try then insult, you idiot

logind would be a problem because it has a dependency on systemd, but as mentioned, udev is fine.

You missed the whole point, though, systemd is not monolithic, so that claim is bullshit. That's like saying Fedora is monolithic, because Gnome depends on X, which depends on the graphics drivers, which depend on the kernel. They're separate, ie the OPPOSITE of monolithic.