Slashdot Mirror
Joey Hess Resigns From Debian
An anonymous reader writes: Long-time Debian developer Joey Hess has posted a resignation letter to the Debian mailing list. Hess was a big part of the development of the Debian installer, debhelper, Alien, and other systems. He says, "It's become abundantly clear that this is no longer the project I originally joined in 1996. We've made some good things, and I wish everyone well, but I'm out. ... If I have one regret from my 18 years in Debian, it's that when the Debian constitution was originally proposed, despite seeing it as dubious, I neglected to speak out against it. It's clear to me now that it's a toxic document, that has slowly but surely led Debian in very unhealthy directions."
No need to peek, if your interest is piqued you can just look, it's pretty public.
In fact, someone on the Phoronix forums posted a bunch of links to Joey's debian-devel posts which seems to bear this out.
Especially the first one is a clanger. If you can't support systemd on technical grounds without getting threats, something is very toxic indeed.
And no, that first post is not directly related to the Debian Constitution. That the idiotic GR trying to override the Technical Committee decision two weeks before the Jessie freeze is inspired by this kind of drivel, and that the Constitution makes these kind of purely political overrides of the technical decisions possible is rather evident though.
From what I read there, stuff like https://lists.debian.org/debia... (trying to make technical decisions via politics when there actually is no disagreement between devs which needs any help with the decision-making) also contributed to his decision to quit.
The longest lived linux distribution has no constitution. It's based on the idea of making sure it works well for the leader of the project. Surprisingly, Slackware is gaining, not losing, users due to this.
Of course, it doesn't hurt that Patrick Volkerding seems to prefer something other than systemd.
systemd on Debian is a dependency for most desktop applications even if one avoids Gnome 3. Installing GIMP, for example, will pull in systemd libs.
During that "lengthly consultation process", nearly all of the for systemd was based on the advantages that systemd, as an init system, offer over competing init systems. In the months since Debian committed to systemd, Poettering has been increasingly vocal that he wants systemd to be more than an init system. That is why there is a renewed call for debate.
Joey Hess did not propose such a vote, Ian Jackson did.
In fact, Joey Hess endorsed an alternative which basically states "we need no stinking GR".
https://www.debian.org/vote/2014/vote_003#amendmentproposerc
Based on what I've read....
His departure has to do with the interruptions to the release cycle by introducing arguments about technical minutia in sub-projects as requiring a GR vote to decide. Technical arguments being decided by the ignorant masses, versus the specific groups (which anyone from the GR can join) who have the specific job of making those decisions. At least that's one way to look at it.
This is not the first time and probably will not be the last that Debian technical decisions will be handed up to the popular vote, completely subverting the whole specialized delineation of teams within Debian. GR votes are being taken (again) for the specific purpose of avoiding losing a technical argument by appealing to a larger group, which also impacts the Debian release cycle. Normally, such votes would be delayed in the interest of the distro, but this is allowed by the Debian constitution. I would believe, such an act (appealing to the GR) was supposed to be limited to hotly debated and controversial topics (like systemd) but not implementation details (which is what is happening)...much less so close to the release date.
He is stating that he expects it to continue. He's not interesting in taking up this fight as a call to amend the constitution. He obviously feels alone in calling out that it's counterproductive to argue over details so close to a release. He's just done with a community that cares about who wins arguments or following strict process procedures rather than respectfully, making deadlines that users and commercial interests depend on (or at least use as an indicator of a stable project).
https://lists.debian.org/debia...
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
Thanks systemd.
BINGO. In spite of Joey being on the 'winning' side of the systemd debate, his resignation seems to be a direct reaction to the schism that systemd has driven into the linux community. As someone far brighter than me said:
Read the whole piece. It's one of the best round-ups of the state of the debate.
(And by 'debate', I mean 'debacle' of course.)
Crumb's Corollary: Never bring a knife to a bun fight.
Of course, you don't know Joey Hess. Being one of the most equanimous, quiet hard-working, involved-everywhere guys I have had the privilege to work with (I am a DD since 2003, and Joey has been one of my role models in the project... Of course, even if our skillsets are quite different) He is not quitting because of "not getting his way".
I disagree strongly about this being an "implementation detail", IMO it's a question of fundamental strategy. What this GR really comes down to is when the choice comes down to denying admins the choice in init systems or refusing new upstream versions bevause systemd's tendrils have dug too deep in the upstream project which side should Debian take?
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
You now have a massive piece of log-corrupting shit sitting between your events and your real log system because the systemd ball of tar is written by a hack that doesn't understand interfaces.
Another turn in the wrong direction, in my opinion, is Wayland, which breaks many highly useful (to users) capabilities provided by X11.
If Keith Packard thinks Wayland is a good idea, I'm inclined to trust him. And, he does.
Perhaps you don't fully understand what Wayland is or why the senior X11 developers think it is a good idea. Please read through this and see if it changes your mind:
http://www.phoronix.com/scan.php?page=article&item=x_wayland_situation&num=1
lf(1): it's like ls(1) but sorts filenames by extension, tersely
"You mean a disconnect like the fact that you can pretty trivially 100% a couple of servers running feature extracting daemons processing text based logs at the moment for a small cluster of machines?"
No. I see that you still don't see the problem with switching from a push to a pull based system, despite your tangents into text vs binary, etc.
You have illustrated my point.
"Where has this absurd notion that text logs are efficient come from?"
I'll entertain your straw man for a bit. You are talking about transmission and storage efficiency, these have not been a serious concern in quite some time due to increased bandwidth and storage capacity. And I say this as someone who works on a system that has 1TB for receiving uncompressed log data, and sees single systems sending well over 20GB a day.
With logs it is much more important for them to be:
1. Portable. eg: there is more than one size of byte and byte ordering. The generating systems architecture and platform can change over time and it should not impact the next point.
2. Archival. The file needs to be read back, maintaining all information, years from now, despite changing systems and requirements.
3. Accurate. There should be a minimum of processing over the entire life-cycle, whereby errors can occur.
4. Integration friendly. On large log infrastructure, the initiating machine's log format is only the first step of the log's life. It must be usable by many other tools.
" rsyslog in TCP mode is how you achieve this currently"
False. It is possible to lose messages even with TCP mode. This is why rsyslog introduced RELP. And if you knew about this then you'd also know that rsyslog supports compressing the log stream over the network, rendering the size efficiency argument rather moot. Since you should be encrypting your network transit anyway, you;d know that enabling compression is a single line config. (I've never seen an un-compressed encrypted stream)
"Of course rsyslog also reads systemd journals natively."
You're being intentionally misleading by saying that and completely ignoring the caveats and warnings about using this.
(See: http://www.rsyslog.com/doc/master/configuration/modules/imjournal.html)
No, if you read his contributions to the thread, he's generally neutral to positive on systemd, and seems to consider most of the whining to be sore losers rehashing shit that's already been discussed ad nauseam multiple times.
He also specifically attacks the notion of using a GR to set technical directions, and he stated a profound dissatisfaction with people raising the GR 2 short weeks before Jessie was supposed to freeze for release.
He's not leaving "because of systemd", unless you're saying that he's somehow showing solidarity with the whiners by slagging off all the whiners abusing the GR process to make political points are being enabled by a toxic Debian constitution.
systemd is designed to give Linux a full featured process manager like you have on mainframes. Speeding booting is a side benefit.
___
As for your comment about arbitrary verbs systemd should be handling each process, that's its job. There shouldn't be any functionality in both places after conversion.
Let's number the responses:
1. For your complaints about lack of arbitrary verbs in init scripts I don't really see much of this as a problem. When systemd's settings do what they are supposed to there is no duplicate functionality elsewhere. This is true for the distros I've seen it used. Far LESS scripting to start the system.
2. Systemd is not about boot time, actually I saw at least one example showing it's slower than upstart. But if you think that's the reason systemd exists you have a lot of reading to do.
3. Binary logging is a useful feature IMO. But hey you can't please everyone. Oh wait you can, a single setting change will give you standard syslog compatibility. Who knew!