Systemd Is The Future Of Debian

[interested]

Interesting, now Jackson is starting a new round of T/L/whatever discussions:

https://lists.debian.org/debian-ctte/2014/02/msg00443.html

Though now we have a diversity of opinions. Jackson is pushing for the original L. Nussbaum says it's too vague. Packard proposed saying noting at all (option NOOP?). Allbery agreed to Packard but also proposed his last draft.
Langasek may also propose his own last draft, and then suddenly we have many options with no clear idea of what could win, as it would almost be that everyone votes for their own draft...

Jackson is also giving only time until Friday, on the grounds that the TC should have had enough time to discuss this already (completely ignoring the fact that the TC was idling waiting for him to return), and also (and most likely the real reason for such haste) out of rampant fear of "facts on the ground".

Whatever the reason behind that Ian Jackson are pursuing this IMHO rather extreme suggestion, I think he isn't doing the Debian developers any favours; they will be forced to remove good features from their programs by dictate from the CTTE. That can't be inspiring work to do for volunteer developers that maintain a favourite package.

Some programs will be banned entirely from Debian, like the upcoming GUI journald log-viewers because they rely on systemd being PID1. I think his suggestion also make it impossible to run Wayland with user privileges, so it has to be root with all the problems that gives. Even if Debian developers are making, or are involved in making programs that require systemd as PID1, their work will be banned from Debian. And this is despite Debian CTTE have decided on systemd as PID1.

It will frustrate Upstream DE developers no end; eg. KDE SC 5/Plasma 2, will have full systemd integration (user, session management etc), but also exist in a sysvinit version with fewer features. Basically supporting the new Linux developing stack: systemd, cgroups, Wayland (and kdebus) in one version, and legacy sysvinit X.org in the other. But if this suggestion goes through, they will have to support a new, Debian only, stack too, that is a neutered mix of new and legacy. Not nice at all.

All in all, this will leave Debian users with fewer programs to use, and more deliberately crippled programs, and much of the future Linux development being banned from Debian.

The suggestion is an extreme top-down steering of Debian developers, and it is really hard to see any reason behind his suggestion of banning systemd dependent programs. Jackson is completely silent about this.

[GreatEmerald]

Whatever the reason behind that Ian Jackson are pursuing this IMHO rather extreme suggestion, I think he isn't doing the Debian developers any favours; they will be forced to remove good features from their programs by dictate from the CTTE. That can't be inspiring work to do for volunteer developers that maintain a favourite package.

Some programs will be banned entirely from Debian, like the upcoming GUI journald log-viewers because they rely on systemd being PID1. I think his suggestion also make it impossible to run Wayland with user privileges, so it has to be root with all the problems that gives. Even if Debian developers are making, or are involved in making programs that require systemd as PID1, their work will be banned from Debian. And this is despite Debian CTTE have decided on systemd as PID1.

It will frustrate Upstream DE developers no end; eg. KDE SC 5/Plasma 2, will have full systemd integration (user, session management etc), but also exist in a sysvinit version with fewer features. Basically supporting the new Linux developing stack: systemd, cgroups, Wayland (and kdebus) in one version, and legacy sysvinit X.org in the other. But if this suggestion goes through, they will have to support a new, Debian only, stack too, that is a neutered mix of new and legacy. Not nice at all.

All in all, this will leave Debian users with fewer programs to use, and more deliberately crippled programs, and much of the future Linux development being banned from Debian.

The suggestion is an extreme top-down steering of Debian developers, and it is really hard to see any reason behind his suggestion of banning systemd dependent programs. Jackson is completely silent about this.

I don't think L has much chance of passing at this point. Ever since the second vote I'm yet to see anyone other than Jackson being in favour of it (although several people have not expressed their opinions yet). It's also of note that Allbery's proposal is using a different power than Jackson's. It is not clear whether the TC is supposed to be allowed to give advice on this point, since the question was never actually put to the TC. Jackson's intention of setting policy is pretty much inappropriate, since policy setting should only happen in worst cases, on top of nobody asking the TC for that.

And if it did somehow pass, upstream DE developers wouldn't be frustrated at all. They wouldn't bat an eye. But Debian package maintainers would be doubly frustrated, if not outright leave the project.

[Delgarde]

but kfreebsd port motherfuckers tell everyone else to help them do their port

But they're not. The subject of the non-Linux ports hasn't really been a big factor in this long argument. Several of the port maintainers have chimed in with their views on how it will affect them, but the conclusion seems to have been that if the choice of init system on Linux isn't usable on the ports, they can live with that.

[Delgarde]

I'd say "a troll".

Quite a persistent one, too... went through half a dozen mail accounts being banned before giving up...

[justmy2cents]

Your machine and your window manager is crap. I can getter similar or better performance with a 8 year old integrated graphics gpu and Kwin.

i7 4770, 16GB and gtx 760 crap? yea, i guess so. damn Raspberry-Pi is too much power to compete with anyway. same as mighty 8 year old machine.

what you don't realize it seems is the fact that NO compositor can take away the deficiency of XOrg. on resize XOrgs paints 1st and then asks client to paint something there. there is always at least 1 frame of that. ask author of KWin if you like, he'll tell you the same (ohh, wait they already say that https://community.kde.org/KWin/Wayland ). wayland cuts out that middleman and so every frame is perfect.

on http://www.youtube.com/watch?v=F6PFjoYuml0 you can listen to long time XOrg developer on why Wayland and how broken XOrg really is. also, here is a video of more on Wayland/R-Pi, doing more tricks http://www.youtube.com/watch?v=1RTk77JRAKw

problem can only be solved if people admit to its existence. and strange thing is that while developers admit they worked on deficient solution and want better, users like you don't.

[Rallos Zek]

and this is bad, the less proprietary software, the better. It's like saying that permissive licenses are better than gpl because in gpl only the copyright owner can make non-free versions of it

Right On!


1234567890

[interested]

I don't think L has much chance of passing at this point. Ever since the second vote I'm yet to see anyone other than Jackson being in favour of it (although several people have not expressed their opinions yet). It's also of note that Allbery's proposal is using a different power than Jackson's. It is not clear whether the TC is supposed to be allowed to give advice on this point, since the question was never actually put to the TC. Jackson's intention of setting policy is pretty much inappropriate, since policy setting should only happen in worst cases, on top of nobody asking the TC for that.

And if it did somehow pass, upstream DE developers wouldn't be frustrated at all. They wouldn't bat an eye. But Debian package maintainers would be doubly frustrated, if not outright leave the project.

No expert on Debian inner workings, but neither Jackson's ballot nor Allbury's amendment to it, have been put to the TC, but then again, several of the CTTE members are also Policy members. I even think several CTTE members was actually in the process of discussion the implications of the CTTE decision, in order to reach a compromise. Rather messy.

I don't think that Jackson's L-coupling have much chance in a GR either, it is too extreme. His GR proposal will probably slightly softer. If he plays it well, he can split the opposition to gather around a compromise text leaning in his direction, like he tried with the first ballot. So even if his proposal looses the GR, the winning proposal will be much closer to his aim than if he hadn't sponsored a GR.

Well, I do think upstream would be frustrated about a third, Debian only stack. How would the precious few upstream developers handle Debian bugs if none, or only few of them actually would develop or test this stack? I mean, which developer would voluntarily run a distro, that deliberately crippled the developers program?

[GreatEmerald]

Well, I do think upstream would be frustrated about a third, Debian only stack. How would the precious few upstream developers handle Debian bugs if none, or only few of them actually would develop or test this stack? I mean, which developer would voluntarily run a distro, that deliberately crippled the developers program?

Not really. Handling Debian-specific bugs is easy: CLOSED DOWNSTREAM (or, alternatively, CLOSED WORKSFORME). Not their problem in the slightest. And yes, why would they run Debian to begin with? There are far more good options to choose from (especially since Debian is the last to the party). And, once again, that just means a lot of problems for downstream maintainers, not upstream developers.

[carewolf]

i7 4770, 16GB and gtx 760 crap? yea, i guess so. damn Raspberry-Pi is too much power to compete with anyway. same as mighty 8 year old machine.

NVidia is crap on Linux. I have optimus myself, but get much smoother desktop performance if I force it to Intel mode even though NVidia mode is 4-10 times faster in games (plus that right now I have to reboot to switch mode because nvidia still doesn't have decent optimus support in Linux).

I know about the deficiencies of XOrg, but the comparison video you posted was still completely idiotic and has nothing to do with any of the issues.

[carewolf]

Not really. Handling Debian-specific bugs is easy: CLOSED DOWNSTREAM (or, alternatively, CLOSED WORKSFORME). Not their problem in the slightest. And yes, why would they run Debian to begin with? There are far more good options to choose from (especially since Debian is the last to the party). And, once again, that just means a lot of problems for downstream maintainers, not upstream developers.

Yes, just so no to people who wants to help you and improve your project. That will make your software great.

I love input from Debian developers. They are usually the reason things work on all kinds of weird hardware and specific configurations that I would never bother to test myself.