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."
In fact, he is very supportive of systemd, as evidenced by many of his mailing list posts. Here's one example: https://lists.debian.org/debia... Pure speculation: He is fed up with people like Ian Jackson abusing the constitution to push their agenda.
My impression of Debian has always been that they take themselves very seriously, especially compared to other distributions. They seem to have a very thought out management structure and inner politics that probably rival large companies. Years ago I remember reading some discussion and coming to the somewhat painful realization that open source now has and possibly even needs PHBes. My guess is that it has continued to (de)volve down the political line, and become the same broken mess s most political systems eventually become.
I've largely stopped following day to day open source politics, and mostly ignore what goes on with Debian, Mozilla, and more and more Apache, but seeing big names rage quit always peeks my interest (yeah yeah, I'm human too!). I'd love if some bored slashdotter could give a quick summary of what the heck is actually going on this time, or point at a (hopefully not too biased) article outlining recent Debian shenanigans.
When Debian pushed Gnome3 and the community didn't like it they moved forward with it as the default desktop anyway. Now there is the systemd debacle. A large number of people have voiced their disapproval, but No, Debian is going to go down that route anyway.
GNOME3 and SystemD are a natural choice because the developer community behind them is so large. Hopefully that leads to software which has less glitches, less vulnerabilities, new features are implemented faster, documentation is up to date, and quality assurance works. These days open source projects are so complex that you really need the pure manpower. This is probably the direction which we are even more heading towards in the future.
Aha, i get your point, like equally nobody uses a Linux desktop neither, what a bunch of wasted efforts is that! Right?..
I've spent way too much time over the past month reading threads on the developers' list related to Joey's proposed vote. Basically, he was advocating a policy which stated that no package shall be dependent upon one particular init system, the situation which has been in place all along. Unfortunately, what it's really come down to is total commitment to systemd or not, not only for Debian but essentially for the Linux community in general. There are many developers who are modifying packages to totally depend upon systemd and its ever expanding list of services, and they have made it clear that they will not consider alternatives. What's become equally clear to me is that the developers in general, and the systemd proponents in particular, are completely unconcerned about the impact upon the user community, the server segment which has almost no concern for improvements such as reduced boot time, or pretty much anything outside of the development community.
Perhaps in the long run this will all work out, but as a long-time (17 years) Debian user and longer-time (30 years) UNIX guy, I'm very skeptical. Too many things being aggregated into a single system, too many dependencies upon large packages which are almost certain to prove susceptible to security and reliability defects, and a lead developer with a poor track record, monstrous ego and an alienating personality. At this point, it seems that a fork of Debian is almost inevitable, though that effort appears to me to be more likely to simply dilute the overall effort than bring any resolution.
What's perhaps most frustrating to me is that systemd is but one of several changes to the ecosystem which are being made with little regard for the consequences. We've seen how well the Gnome3 desktop has been received by the user community, with essentially no concern from the developers. The loss of a desktop manager is an inconvenience, however there are many applications based upon GTK which are essentials, and these are being adversely affected. Another turn in the wrong direction, in my opinion, is Wayland, which breaks many highly useful (to users) capabilities provided by X11. I'd be OK if Wayland continues to be an alternative to X11, however I suspect that, like systemd, it will become an avalanche once Red Hat and any other major distribution adopts it as a default.
As I wrote above, perhaps in the long run it will all be good, and the consequences of people like Joey Hess departing will not be detrimental. We shall see.
-- MC --
The problem is that users can't be allowed to decide which desktop environment or init system to use. They can only request particular features and then developers decide which DEs or whatever to use to implement them. That's the only way it can work. Otherwise you'll have no developers and maintainers, period. And who will implement stuff then?
Gnome3, systemd, wayland, pulseaudio etc might (or might not) be good ideas. But they should probably not be introduced before they are completely bug-free -- or at least more bug-free then the thing they will replace. (And they should be better designed than the thing they are trying to replace.)
This has not always been the case. Actually, this has rarely been the case. They have been introduced as the new hip thing despite bugs and design flaws.
And considering that the *ix world is full of people who don't like change - it's one of the main selling points - changing things because it's hip, doesn't solve the problem, introduces new bugs and introduces the well known problem of update-your-legacy-system-or-don't-update-your-machine-ever-again doesn't really sit well with everyone.
You outlined your scepticism, thought processes, and the "general concern" standpoint that is so often lost in political vs. technical (or "politechnical") battles involving the "monolithic systemd" approach and I share your sentiments completely. Maybe that's because, like you, I'm an "oldish UNIX guy" (1990 and counting), and a lot of us have been around long enough to see the negative effects of "change for the sake of change" (which, in my opinion, systemd suffers greatly from); a lot of software today suffers from that driving force, so I shouldn't exclusively pick on systemd.
The author of uselessd said "many of the more technically competent people with views critical of systemd have been rather quiet in public, for some reason". The reason is that most of us in those positions do not have the time, energy, or interest to partake in long-winded uphill battles when our jobs, responsibilities, and lives tend to already be inundated with energy-depleting tasks; the last thing we need is to voluntarily enter into a near-religious debacle when we could just switch distros or flavours (e.g. Linux vs. BSD) and continue to do what we've done for a long time (and continue to do it well). Thus, our scepticism is justified -- we are not "against" change, we just don't make hasty decisions.
If the users don't like what the developers are doing, the developers are free to leave.
You've gotta be fucking kidding me. The opposite is true with most open-source projects, as it should be. Those who do the free work get to decide what they work on, and if they want to pander to user's demands. No developer would want to work for free in the way you're describing. Also, developers are users too.
Can nobody do anything about this chap on an ego trip?
First, he didn't do what was necessary for audio; but made a huge, convoluted "Eierlgende Wollmilchsau" from it (I guess, he knows what that is!) that pops up and tells me all the while that I have plugged in some headphone or some; but doesn't remember, ever, despite of all my efforts, that, no, I don't want the internal sound card after each reboot, thank you very much! So I have been telling my machine for the last 2 years, whenever I boot, exactly that, and again. After each reboot. Thank you very much!
He seems to like all the convoluted stuff - against all Unix philosophy, by the way - and the stuff that usurp the rest of the world. How can a maniac be such unstoppable?
Even the init stuff of systemd requires the Linux kernel, so it is incompatible with Debian's commitment to a diversity of systems. In any event, systemd is not modular by any reasonable definition. All of those "separate binaries" expect to be talking to each other, and the uselessd developer found he had to go far back in the systemd versioning to be able to use just the init system components without the rest.
systemd is designed to prevent duplicated boilerplate in init scripts -- but it won't support arbitrary verbs in its init scripts so best practice is to put those functions in auxiliary scripts elsewhere. Which will mean you have to duplicate long sets of the same functionality in both places. Yay for systemd!
systemd is designed to minimize how long you spend booting. Given how often I reboot, if systemd costs me even one more minute to deal with over the course of a year, systemd has actively failed to save me time.
systemd brings binary logging to Linux, which is good because I was talking to Nobody Ever, and Mr. Ever had a lot to say about how big a help the Windows Event Viewer is in sorting out issues.
I guess Debian was a great thing to learn Unix on and I'll really miss it.
Yahoo! Pipes are awesome. How awesome? http://pipes.yahoo.com/jesdynf/slashdot
systemd has become de facto mandatory, practically overnight. We weren't having this debate every other day last year.
This is a clear sign of something immature being shoved down our throats. My point is simple: it has not followed the traditional path of gaining third-party acceptance before becoming enshrined as a de facto standard in one of the most major distributions around. This (and I am NOT trolling) is much like Bennet Hasselton using Slashdot's front page as his personal blog; it is an option unavailable to the rest of us, and it is unclear why he should be so specially privileged.
There is no clear and compelling reason for replacing a host of services (69 services!) with entirely new code under the aegis of "making an init system" (one service). First and foremost, the amount of unaudited code is staggering. This is a security nightmare. The NSA is busy laughing all the way to the bank, because they didn't have to lift a finger to vastly increase the amount of attack surface on the average Linux system.
More importantly, it has been allowed to work itself into a position where we are unable to avoid it without sacrificing features we use routinely (and this applies across many groups of people with varying interests and use patterns). This is a clear loss of freedom of choice. Calling it "not mandatory" is disingenuous at best and an outright lie in many cases.
I should add to this that Debian has built a reputation, over more than a decade, for being a conservative, rock-solid stable distro. By adopting new packages which are less stable than their predecessors, Debian, more so than other distros, seriously erodes its reputation.
IMO: the article is wrong. Many of the reason that systemd is hated are technical. And those technical reasons have expressed, and then ignored, many times.
Please speak for yourself. We developers are often horrible at recognizing what users want, but we are often excellent at recognizing poorly engineered software and systemd reeks of poor engineering. I'm all for tighter integration of components in the operating system so long as they make sense, but systemd tightly couples all kinds of components that should be optional and, in general, pisses all over basic engineering principles such as KISS. I started out very neutral in the systemd debate, but the more I learn about how it is implemented, the more I understand why there are so many people who vehemently oppose it.
Shut down your machine. Now mount /var/log on a machine running Fedora 18. Now tail -50 /var/log/* to find out why your first machine won't boot.
When you've done that, you can speak again.
"It is trivial to export systemd log files to such a centralized logging server by using "systemd-journal-gatewayd", "
That is a pull based system, ie: it allows you to retrieve logs from the generating server. It is in no way a replacement for push based logging to a central server.
The fact that you suggested this as a viable alternative demonstrates the huge disconnect between system admins and systemd advocates. It'd be nice if existing solved "problems" weren't re-solved without fully understanding the original problem.
It's like reinventing the wheel, based on you only ever seeing a bike travel down stairs. Then wondering why people complain about the fact that you decided a square wheel would be better. A square wheel may very well provide better traction on the stairs, but you've missed the bigger picture.
> So in other words the massive egos are butthurt that in a FOSS environment the USERS get a say in things?
I think that's an unfair characterization.
Any USER can join the technical committee. How is it constructive to have a TC vote bypassed on an issue on the basis of a TC member similarly rejecting the process, as a method to bypass an unfavorable outcome? The toxicity is not the community, it's the process. Once set (by the constitution), it has been effectively unalterable. I do not DISAGREE with this process, I simply recognize the unfairness of it all, from his point of view.
Those "egos" are the egos of people who are part of the technical committee. As Joey asks, why even have one now? Well, because it's taken time to get to this point and it just happened to be close to a release. He thinks technical decisions should be limited to the TC and anything related to those decisions (like the following practices) should also be from the TC. It's not just about this one incident, it's about a consistent waste of time in the TC that he worked to be a part of. He doesn't want to be a USER level contributor either, so he's walking. It's just altogether unfortunate that the community no longer fits his tastes and it's not uncommon for people to leave commercial jobs under the same circumstances.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
Indeed. It is basically a decision about whether Debian becomes a monolith (and installation without systemd is exceedingly painful or impossible) or whether it retains large freedoms for its users to configure things, like, for example, the init-system. Now, monoliths do have advantages (if done really well, something basically nobody manages), but they also have severe disadvantages, like the concentration of power and and with it, decisions not being based on technical merit anymore. For a commercial project that, it can still be worth it. For a non-profit venture, it is toxic.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
For me, the not-caring about corrupted logs was the kicker. Nobody with even the least bit of interest in security and stability will _ever_ tolerate something like that. The logs are critical and _must_ be complete, if technically possible.
Poettering is an incompetent hack or has a nefarious agenda. (Personally, I think he is a pansy for others with the nefarious agenda...)
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Well, no.
He is a casualty of the way systemd is "resisted" -- by political (non-developer) manouvering, death threats, insults and lies.
Watch this Heartland Institute video
Becomes a monolith? Before Jessie sysvinit was essential.
Watch this Heartland Institute video
"Or, you might check the issue tracker and you will find that network logging is on the to-do list."
And this quite says it all.
Despite still lacking basic features and obviously being a moving target, someone wants it as the default for such an important component as the init system for the Stable version of one of the most used and respected distributions known, among other things, for not adding variations once frozen (remember the thing about "moving target"?).
"RELP is TCP based with another layer of protocol over the top."
You could say the same about HTTP or any other application level protocol, so I don't know what your point was trying to be. Syslog is a protocol and a message format. RELP replaces the protocol but keeps the message format. The stack looks like:
TCP -> SYSLOG -> Syslog message
TCP -> RELP -> Syslog message
Disk buffering is there as a final effort to guard against transport issues and lost messages. If you're relying on it for normal logging activity you are doing it wrong. (eg: what happens if the buffer integrity is unreliable?)
"Text logs are in no way portable."
Tell me that when you've dealt with multiple binary logging formats and, worse, multiple versions and schemas.
" People think they're portable because they can read them"
And that is a huge strength when it comes to archival. In ten years time you look at some random binary format and hope that there's sufficient documentation to work out how to read it and import it into the systems of the time. With text logs you simply read them. And I'll also point out that structured log data doesn't stop the issue of having to pull apart the log message into the fields you are interested in. There's always a limit to the structure, and developers will add their own to the message content, you only need to look at how different developers use the windows event logs. Therefore structured logs doesn't solve this problem.
"back to the broadest conceivable category of things it could be and hoping some version update doesn't change the format"
You realise that this is not unique to text logs, but applies equally to structured data. I'd suggest it's worse for structured data, because humans are good at seeing patterns in text.
"This is why we have log aggregation systems - no one wants to keep tons of redundant data, they want to sort it into their indexed, databased format that actually provides useful information."
Putting aside the fact that most log aggregation systems are basically indexing systems onto the original text record. Following from the previous point, have you ever migrated from one log aggregation system to another? Did you bother trying to convert the poorly documented proprietary database system to the new poorly documented proprietary database system. Or did you simply feed the stored text based logs into the new system? Now imagine trying to pull logs out of the 10 year old unsupported system that doesn't even install on current platforms.
"Seriously this fetish the community has with every new thing being 110% feature compatible and complete with the old the moment it hits github is getting tired."
The strawman argument is what's getting tired.
1) No one asks for your petty project to be 110% feature compatible with anything when it hits github.
2) What people asks is for THINGS ALREADY RELIABLY WORKING, being at least as good as the old thingie PRIOR TO BE PROMOTED TO A PRODUCTION ENVIRONMENT.
3) For it to be accepted into a production environment, the new thingie has not only to be as good as the old thing but BETTER by a factor that makes it worthy the expenditure in relearning and readapting old systems and people to the new thing. And then add an extra margin to cope with the risk that in the end things may not end as expected.
I know it's in the human nature but what it's tiring is for each new generation know-it-alls to throw away the experience and knowledge of the ones that came before and then even telling they "find tired" when told, no boy, you don't know it all.
Because you just went on to prove the entire point I was making by talking all about extra network protocols and daemons all created to make networked syslog reliable while you're in the middle of complaining about using a separate daemon to make journald network exportable.
You have no point at all apart from making a whole load of noise to make it look like you have one.
At this point, I have no idea what you think the problem is other then "oh my god journald is new and scary".
Not an argument I'm afraid, but this is the kind of non sequiturs that systemd critiques usually boil down to once its proponents have exhausted all the nonesense.
Sys admins demand logs they can read under as many circumstances as possible and the ability to take logs off a machine promptly in the event it is compromised. systemd fails conclusively on both counts. The point, and the end.