Can someone provide context for this? I am not familiar with Debian and do not know the back-story.
Also, I assume this is not directly related to the recent resignation[0] of Heen. But does the resignation of two people (whose resignations were deemed worthy of being voted to near the top of the HN front page) within a few day span suggest concernening structural issues or is this just poisson statistics at work?
I get that there's a lot of politics in Debian. I also get that systemd is a controversial topic, but is this really a vote that just came out with the result that no vote was needed?
How many votes will there be about systemd in Debian that will turn out inconclusive?
Also, I have yet to see a single article of somebody running into all the various horror scenarios envisioned by adversaries of systemd. I mean: Multiple distros have already switched and there still aren't that many blog posts about systems dying in flames because of the switch.
I would so love for this discussion to happen based on technical merits and (by now actually available) real world experiences than FUD (on both sides)
The outcome of the vote was something roughly like, "The General Resolution (GR) process is not the right venue to resolve this issue". The GR process has traditionally been used rarely, and mainly for "meta" things (deciding how Debian Developers are approved, that kind of thing). So it's not a huge surprise that sentiment against involving the GR process in the "init wars" was high.
All GRs also have a meta-option of "more discussion needed". Sort of a "no confidence" vote on all the candidates/options although in actual use unless it comes in first, when ranking it creates a border something like "absolutely positively no way". Technically the "no GR needed" people were abusing the system and should have just put "more discussion needed" as their highest rank. Its the same concept but this is a "funny" rephrasing of the same concept.
Perhaps the only thing everyone on all sides can agree on is funny, is that "further discussion" didn't get many votes. Somewhere last night I read a quote about there's hundreds on each side but only nine masochists who voted for "further discussion"
I think this is the last vote related to systemd for a while.
There can only be a single default init system obviously, so a vote was required there. It was a hot topic, no need to rehash this.
The second vote, initiated by Ian Jackson, was controversial from the start. A lot of people were tired about the init topic and wanted to move on, and didn't want the GR. And they got the majority here: the result of the vote is "General Resolution is not required". This is the majority clearly expressing it's now time to move on. And to be honest I'm happy about this, although I'm just a Debian user and do not vote. With this, it's now unlikely to be another vote.
And this desire to move on can be now felt on all sides of the argument, hence the resignations and people moving to other things.
I just want to point out that except for Joey Hess (really sorry about that) all are still remaining part of Debian. They just move out of the TC (or systemd maintainership) but are still DD, working on some parts of Debian.
And now, hopefully, everyone can cool off and move to other things too.
If adopting systemd actually broke everything, then of course they'd be doing something else instead. The anti-systemd crowd looks at this issue the way you might look at someone who took a working piece of software, and then did a completely correct transformation of all loops and conditionals to use bare gotos.
It's not incorrect to do that. Nothing crashes. It might actually even be faster or use less memory if you were sufficiently clever about it. However, the argument is that you just bought yourself a future full of pain and misery for not a big enough present gain.
Look at poor technical decisions from the past. The earliest browsers were encouraged to be liberal in what they accepted (an adaptation of Postel's law to HTML parsing). I think a lot of people today regard that as a decision that probably held the internet back by a decade -- think of the time we wasted writing compatibility layers and artificially restricting what our web pages could do. But it wasn't immediately obvious that that was the case. It took 10 or 15 years for the implications of that decision to really hit home.
What happens next is not a collapse of the world. It's a slow accrual of follow-up decisions that are needed to keep the lights on, until one day you look at the Eldritch horror you've had to build over 10 years and go, "Jesus, that was a bone-headed idea." Maybe they're completely wrong in opposing it, but systemd isn't anywhere near old enough to have decided that just yet.
Someone needs to dedicate an academic thesis to documenting how systemd advocates pulled off their coup, and what improvements are needed to OSS governance structures to prevent a repeat. By the time the pain becomes visible, no one will remember how the actual decision got made.
Yes definitely, and the thesis should discuss in detail the role of the Illuminati in getting systemd adopted, and provide a by-the-minute protocol of what went down at Area 51.
I don't think there's any vast conspiracy to understand or try to prevent. sysvinit has actual problems, and systemd solves many of them. I'm one of the ones who finds it ugly/inelegant/gross aesthetically, but it did address issues people wanted addressed.
And there wasn't a faultless alternative either. It's not like upstart or sysvinit was so good that you need to invent anything to explain why systemd won out. It won out because people either don't share my mild aversion to its design or because they chose functionality on Linux over elegance/portability/fill-in-your-own-thing. And hey, that's a Pareto-optimal choice as well.
One i found some months back when the whole systemd issue got my attention was of someone that ended up doing a parallel arch install to read the journald logs.
Going from memory the problem seemed to be that he could not run the required command to get the logs dumped into readable form without systemd running as pid1. And systemd was refusing to boot for no apparent reason.
Thats the kind of thing that will get seasoned admins, that are used to cat being all you need to get at the logs, backing away with a "no way, no how".
This “binary logs!” thing is approaching FUD-like levels. “The logs” will not be binary. The logs will be where they have always been, in the format they have always been in. Sure, journald has some binary logs of its own, but it puts all the log messages also into the normal syslog daemon, so nothing changes.
As far as I can tell, the whole brouhaha started when there was a bug in the packaging of syslog-ng so it would not start properly after installing systemd. Since syslog-ng was not running, the only logs left were journald’s binary logs, and people assumed that “systemd ate my log files!”. No. It was a bug, the bug was not even in systemd, your log files will always be where you want them.
Unless you uninstall your syslog daemon, but then you are on your own.
Either I'm using journald to log to a binary format, or I'm having journald forward everything to syslog. If I'm trying to avoid binary logs in the first place, then there's really no point for journald to be running--just forward directly to syslog in the first place. Journald is just dead weight in this use-case.
They are related in the sense that are all fall-out of the struggle to integrate or block systemd in Debian and/or how it exposed some problems with the Debian constitution.
It's a shame to see that so much talent is lost and frustrated over what in my eyes seems to be a small issue. systemd and Upstart are both a large improvement over the System V init scripts. So, it's quite logical that it should be replaced at some point. Since systemd seems to have the most traction in other major distributions and upstream software, it makes sense to make that the default, while making it still possible to switch to Upstart et al. if someone wants to (at the risk of losing support for some upstream software).
If it turns out in three years that systemd is a dead-end, rip it out, and use whatever is better then. Distributions did that with devfs, the old hotplug scripts, egcs (which was merged back in mainline), etc.
I get the impression which is admittedly informed by very cursory examination of the issues that ripping systemd out may be far more difficult than ripping say, Upstart. Systemd seems to have taken the approach of owning far more than just the Systemv init stuff and that removing it might entail sweeping changes to huge parts of a linux distribution. Systemd does seem to be pushing somewhat of a lock-in strategy and for many in the linux community that rubs them the wrong way.
I get the impression which is admittedly informed by very cursory examination of the issues that ripping systemd out may be far more difficult than ripping say, Upstart.
Definitely. But this is probably true for many things at a low-level in the stack. E.g., it would also be hard to replace D-BUS or the Linux kernel (as evidenced by the fact that Debian/KFreeBSD will probably not be in Jessy).
I agree that it is a worry. But you can never make progress without taking any risks. We have tried 'fully isolated init' for years and it does not really work for modern systems/applications.
We have tried 'fully isolated init' for years and it
does not really work for modern systems/applications.
I keep hearing this but I haven't seen any concrete reasons why it would be true. I'm curious what those reasons are. As I said I don't personally care that much as I work far enough up the stack to not be affected for the most part.
I think it's not a problem primarily with "init" itself, but for example that systemd provides you with the capability of starting a service "after network is up" so it needs to be able to tell "when network is up". That's much easier to do if there's a canonical (from systemds POV) way to tell "what's networks state". That again leads to "bah, let's do that ourselves" so there's now an optional systemd component that does this, that, this and people start relying on those - systemd-logind is a requirement for gnome. You could write a replacement for systemd-logind that offers the same functionality, but as long as nobody does, you're stuck with systemd.
The way I see it is that the systemd developers just plowed a way through the undergrowth and produced a suite of components that provide functionality that's appealing for people to build on. That's an offering that was accepted and now other people complain that the "systemd people are forcing their system on us and I want sysV init". The right course of action would be "meh, don't like systemd, I'll build a better offering." Talk is cheap, code is what counts.
I very much like systemd. It's documentation is actually long, but clear and well structured. The init component is much simpler than the mess of shell scripts used before. There certainly are problems and issues with it, but I've met problems and issues with about any kind of software I had to deal with so far (including my own), so I take that as a given.
Your response only makes sense if your alternatives are: (1) systemd, (2) sysvinit and (3) a horrible death.
I know dozens of init systems that do much more, markedly better than systemd, and are modular so you can easily replace them when the time for a new technology comes. systemd is very recent, and still its opinionated architecture is showing inflexible to changes.
(1) systemd
(2) write and advocate the usage of a different init system.
(3) a horrible death
I'm certainly not opposed to having a better alternative, but the systemd people managed to write something that is better than sysvinit and made the package good enough to get people to use it. Now people complain that they're taking over the linux world by force, but they actually don't. They just provide something people want - it's not that they forced the gnome people at gunpoint to use systemd.
I happen to like modern daemontools-like init systems a lot, (runit, s6) but I use various init systems depending on what I want, and that's great IMO.
The problem is that systemd is that is being forcefully pushed to all distros. For instance, by merging udev with systemd. We want to keep all the alternatives available.
I don't see any force involved. udev is their code. Don't like how they use it - fork.
I understand your pain, I sometimes don't like the direction things that I use move or the ways they change, but I'm not sitting at the sidelines complaining about being pushed around. I get to use stuff others provided for free, I'm grateful for that and I either fork/change it or move on to something else. I'm not in a position to tell them what they should be spending their time on.
Lennart Poettering could just stop developing and supporting udev any second, that's his personal decision and I couldn't say "he forced me to use windows" and I don't see anybody else could.
Don't like the (maybe) coming systemd dependency for udev? Build the code to set up the bus yourself or pay someone or wait until someone knowledgeable gets sufficiently fed up and builds something. Same for the gnome dependency on systemd: Either accept it or contribute the time to make it work without while retaining the features it has.
Not only udev, they roadmap is to pack the whole system so as to remove any difference between linux installs, their words, not mine. Currently, we can fork udev, but in the future, are you telling my to fork the whole operating system? And all applications that unnecessarily depend on said system? That would require millions of dollars, at least.
Also, Windows can also be forked, by distributing patches instead of binaries. So that argument is a red herring, DOS has been forked before, and every proprietary application, but that doesn't mean I can't ask other developers a bit of respect for those of us who are using other init systems, I will maintain my software, just let me do that. All the discourse about democracy around GNU/Linux wasn't supposed to be summed up as "Fork or GTFO".
> Currently, we can fork udev, but in the future, are you telling my to fork the whole operating system? And all applications that unnecessarily depend on said system? That would require millions of dollars, at least.
Yes, indeed, I do. Because most applications will not unnecessarily depend on systemd, but rather because the dependency provides some (perceived) benefit to the developers. And if the developers decide that the benefit is worth the dependency, they'll do it. And if you want to prevent that future, you need to provide something that offsets the benefit - write the test and compat code to support gentoo, write the docs, provide the money (or other incentive) for the developers to do so. That's how it works. You don't have to do all of that yourself, you can form a group, build your own distro, run a fundraiser, whatever you choose. But you don't get to sit back and complain and hope the world changes for you and neither do I.
There's no democracy in the OSS scene, users don't get to decide what the software they use looks like and even maintainers or other software have no vote. It's more like a market - we use what's best for our personal cause. You pick and choose and the software with the most users will prevail, others either hold their ground or disappear (ConsoleKit).
Who are this developers you keep talking about? When Microsoft bundled IE, WMP with Windows, we said, OK, developers decided that the benefit is worth the dependency, they'll do it, but we didn't like that, I'm not talking about legal issues, what I'm saying is this is an attack to the GNU/Linux philosophy. If GNU/Linux closed its source and went proprietary, you would say exactly the same things: Fork or GTFO. But I would say, this is not right. I just don't want systemd bundled with necessary GNU/Linux components, like the Linux kernel, in the future. As simple as that.
All this discussion doesn't and won't preclude me from do all the things you said under "preventing the future".
People developing software. For example the gnome folks. You, me. (don't know about you, but I have services that use systemd for starting and supervising the service)
> If GNU/Linux closed its source and went proprietary, you would say exactly the same things: Fork or GTFO.
Yes, actually, yes. If Linus decided that all future development he wants to do is now closed source, I either have the option to fork and continue in the open or GTFO. I'm not the one to decide what he can to in his time. There's be a number of legal issues surrounding that, for example that he can't take the current kernel code, but if he decides that within the given framework he closes his development, fine with me. If Linus decides that he thinks that a deep integration between the kernel and systemd is the way forward for his project, I have to accept that. I may not like it, but unless I do something to change it I can't force it any other way.
The beauty of OSS is that you can exactly do that - take the last public version and make something better, something that's more the way you like it, no matter what the original owner thinks, says or does.
Not if Linus decided that, if the Linux Foundation decided that they wanted to switch the license to proprietary. See the mailing list message of Linus against deep integration between the kernel and systemd!
> The beauty of OSS is that you can exactly do that - take the last public version and make something better, something that's more the way you like it, no matter what the original owner thinks, says or does.
Read my previous comment: The beauty of proprietary software is that you can exactly do that - take the last public version, patch it and make something better, something that's more the way you like it, no matter what the original owner thinks, says or does. :)
> Not if Linus decided that, if the Linux Foundation decided that they wanted to go commercial. See the mailing list message of Linux against deep integration between the kernel and systemd!
Why not? Do you pay them for their time? I don't. So who am I, what do they owe me? Nothing. Not even a new free version of linux.
>Read my previous comment: The beauty of proprietary software is that you can exactly do that - take the last public version, patch it and make something better, something that's more the way you like it, no matter what the original owner thinks, says or does. :)
No, actually you can't. You're not entitled to unless you specifically sought a license that permits it. All Open Source Licenses grant you that permission.
Well, if Microsoft could, and did, port IE and Office to UNIX, why would the free and open software people have a problem in allowing more user choice? Why would they need to hard depend on software designed to be non-replaceable? With most free software organizations set up as nonprofit, we must hold them to a higher standard to ensure their continuity under the legal framework.
> No, actually you can't. You're not entitled to unless you specifically sought a license that permits it
> Well, if Microsoft could, and did, port IE and Office to UNIX, why would the free and open software people have a problem in allowing more user choice?
No, why? If they port it and even if they provide it closed source binary only, I'd still believe that an open source browser and office packet are fundamentally more in societies interest, but they're certainly entitled to build and distribute IE and Office for linux/unix/catOS and I'm not entitled to tell them to stop. Given the license of pretty much all linux distributions I think nobody would be. Just as microsoft allows the distribution of OpenOffice and Firefox for Windows. They don't have to like it.
>> No, actually you can't. You're not entitled to unless you specifically sought a license that permits it
> Please take a look at 17 U.S. Code § 117.
I'm not going to discuss american law with you, but please note that this paragraph puts severe restrictions on redistribution of copies, while the GPL does not. I'm not a law scholar, much less an american law scholar but I don't think this means what you think it does.
I'll tell you one thing, I know nothing about you, but this person is considered by many the best programmer in the world, one thing is certain, compared to the good done to the world, he's various levels above you and me, he's the creator of daemontools, the way it follows the unix philosophy has been an inspiration, I'll refer you to this page about software law http://cr.yp.to/softwarelaw.html
It seems you don't read my comments, because I've edited binaries, and distributed patches of proprietary software, that's not illegal, only I didn't distribute the binary or code without permission. Let me tell you, having systemd source doesn't help me at all because it's a megalithic blob.
Is the GPL a good thing? Yes, BUT just because you license your junk with the GPL you don't deserve a Nobel peace price. You seem to think that had Hitler released a hello world program with a GPL license he would be a saint, and can't be criticized, "fork or shut up", you say?
Please note that the link you posted says exactly what I was stating:
> As long as you're not distributing the software, you have nothing to worry about.
You're not allowed to redistribute the software, modified or not. GPL or any other OSS license grants you the the permission. (and no, distributing software under GPL does not make you a saint or even a good person. See Reiser)
No shit, I don't distribute the GNU/Linux software either, too big and inconvenient (GB) compared to a patch (bytes).
>> GPL or any other OSS license grants you the the permission
The sysvinit alternatives that I know and use, all use an OSS license, most of them less restrictive (BSD or MIT). I use free (as in freedom) software; that's why systemd is harmful to me, always trying to create incompatibilities with other open source programs lacking a multi-million corporation backer.
Better in some ways, worse in others. If systemd were unequivocally better in all areas, nobody would be complaining. By saying what you said, you're subtly but deliberately telling every one of those people that their concerns are irrelevant and/or a result of their ignorance. This is the systemd developers' M.O. and a large part of the reason why there's so much drama over systemd.
Right, "better" is a relative term in software. I'm not disputing that there certainly are problems in systemd, but as a package I still think that systemd does more things "better" than sysvinit than it does things worse. There's certainly a lot of room for improvement - build upon it and create and advocate an init system that is better than systemd in more areas than it is worse.
> This is the systemd developers' M.O.
So far I've mostly seen "we believe this is better and we'll build it this way, like it or leave." That's certainly opinionated, but hey, they're totally entitled to have that view (why would they build it if they thought it's worse?!) My view and your view may differ, but we don't get to complain unless we provide something that we think is better and get a lot of people to agree on that.
>I'm not disputing that there certainly are problems in systemd, but as a package I still think that systemd does more things "better" than sysvinit than it does things worse.
The community seems pretty evenly split on this point, with folks like myself taking the opposite view: systemd is a regression in so many fundamental areas that its improvements in things like boot times and init script syntax just are not worth the tradeoffs that it imposes. I don't care if the frogurt is free when it's full of potassium benzoate.
Sure, if that's your view, I'm fine with that. If the people that build the distro-of-choice for me decide that frogurt is the best init system for the distro they want to build, I'll either swallow that or move on to something that uses guaranteed potassium-benzoate-free-frogurt as init, but I'm not going to tell them that they're not allowed to do this. Because they are. You don't have to like it, you don't have to eat it but they're free in their choice just as you are free to build something else.
>You don't have to like it, you don't have to eat it but they're free in their choice just as you are free to build something else.
And I'm also free to correctly identify that their poor leadership decisions are ruining a wonderful piece of software and causing the community, including Ian fucking Jackson, to abandon the group that made it possible.
If there are really "dozens of init systems" out there that "do much more, markedly better than systemd, and are modular" how come exactly zero of them have been adopted by any Linux distro of note?
Thanks for the detailed response. It makes a certain amount of sense.
The right course of action would be "meh, don't like
systemd, I'll build a better offering." Talk is cheap,
code is what counts.
This statement seems to ignore Upstart though. Which is again from a very cursory examination exactly that. A better and more modular init without some of the complaints of systemd and yet is not gaining the mind share.
Well, ubuntu used upstart and moved away, redhat/centos the same (though the centos 6.5 version of upstart was horribly outdated and crappy in terms of features). I actually kinda liked upstart, but I prefer systemd.
Upstart's event-based model was semi-broken and AFAIR the original author admitted as much. (I believe he posted a message stating this to a maining list, but I cannot find it ATM.)
Exposing the event model directly to the jobs also made reasoning about the current system state (which is what actually matters, not how we got there) tended to make upstart jobs a lot more complicated than necessary. (This is from memory, it's been ages since I actually looked at upstart jobs.)
> systemd provides you with the capability of starting a service "after network is up" so it needs to be able to tell "when network is up"
That's not that hard once you have proper dependency-driven init, Gentoo's done it for a long time. You just need some way for the networking scripts to tell init that they're started now. Traditionally they'd do it by forking into the background once they're done starting just like any other init script. It's a bit harder if the network might not become available until after startup but not that much so.
> It's a bit harder if the network might not become available until after startup but not that much so.
That rarely happens in server environments. I wonder how much of the recent debates about init systems is caused by the the rise of mobile consumer devices and developers' desire to cater to them.
I care when my laptop takes more than a few seconds to start up, but I really don't care when one of my cloud servers takes a few minutes to start up. Network not ready yet? Meh, we could just sleep(10) and try again.
In fact, the whole series is a recommended reading. Anyway, all these features requirer tighter integration with other components than SysV init. E.g. Linux' cgroups, services that support socket activation, integration with the logging system for status information, etc.
Also, a lot of techniques in systemd were already pioneered in launchd on OS X since Tiger.
Because minimal boot time is way more important than predictable, repeatable functionality. It's totally cool if some other daemon lies about whether or not my service is actually listening while just happily buffering into /dev/null. This is all brilliant stuff and a huge step forward over UNIX.
You should educate yourself about FUD, I recommend the Halloween documents, where they explain the unfeasibility of FUD tactics against an open source project, and that if someone tries to do it they won't get anywhere.
Yeah, but inetd was just about TCP sockets. systemd also supports unix-socket activation, which can block the client when the buffer is full, preventing data loss. I agree that TCP socket activation is iffy (though I still use inetd for non-critical stuff), but unix-socket activation seems safe to me.
What offended about his post, out of curiosity? The Rube Goldberg analogy (I found that rather apt), or the "Professor Lucifer Butts" aspect of it (which I'll also confess to finding not the least apropos nickname for a certain Red Hatted German)?
I was chiding your comment for being rude, not salacious.
The first meaning of "scabrous" in my dictionary is "having a rough surface", and that's how I meant it. There's a long tradition of using that word to describe rough-and-tumble discourse, and it seemed fitting. You didn't just smack another user, you smacked them with a pointy implement (a link to an insulting image). That's not ok on HN. Neither is smacking people without a pointy implement. And telling another user "You're a liar and a coward, and you know it" is right out—a bannable offense, although we didn't ban you for it.
I'm insisting on this more than usual, because we don't want the pugilistic approach that is popular in some related (by subject matter, at least) online communities to take root here. When commenting on HN, please eliminate incivility from what you post.
This is a well thought out and complete response, it's just unfortunate that an image illustrating an overcomplicated system to solve a simple problem has elicited this censure; instead of the comment, in response to another user throwing a personal insult against an OSS hacker, where I call this user "a coward".
Your position about the place we want HN to be is clear, but I still believe the image is not insulting or offending anybody in any way. Those who flagged it, could they have misinterpreted it as an insult to the developers? An insult to the users? An inappropriate "scabrous" picture based on the URL? Or just as an attack to a program that needs our praise?
You're right. The "liar/coward" comment was the much greater offense, but that one was flag-killed.
I realize now that I was being too cute pulling out the old "scabrous" to make what is really an obvious and mundane point, and ended up confusing things. Sorry. I get bored sometimes and throw in variations which HN moderation comments are obviously not the place for. Let me try to be clearer.
There's nothing at all wrong with that image per se. It's great. I've made more than my share of Rube Goldberg analogies and know exactly where you're coming from. Had you linked to the same image in a thoughtful comment about overcomplicated systems, with no trace of incivility, of course it would be fine. It was only a problem in this context, i.e. a drive-by potshot in an inflamed discussion on a polarized topic.
Because systemd is, although people argue this point, essentially monolithic.
Sure, in theory it's modular, but the module dependencies are so intertwined that good luck using any of the modules without the entire thing - or writing so many compatibility shims that you might as just write the module yourself. And that's even assuming a compatibility shim can be written without essentially reimplementing the entire module. It prevents incremental replacements. And it keeps expanding to pull more and more essentially unrelated functionality into itself.
It's "you're stuck with this architecture unless you redo the whole darn thing". And, again, systemd keeps getting larger and larger. As you say, it isn't that hard to replace sysvinit. But to replace systemd you need to replace / write shims for far more things. (Your window manager? I wish I was joking...)
I'm confused by the Window manager comment. As far as I understand, essentially, ConsoleKit development was stopped, and work on systemd-logind etc began as a better way forward, rather than rewriting ConsoleKit.
During this timeframe, GNOME developed integration with systemd-logind, similarly to how it developed ConsoleKit support beforehand. And in fact the ConsoleKit backend was supported for a while afterwords. But this is no longer the case as nobody was willing to support it and maintain it in upstream GNOME. So it was removed.
So I'm confused by the comment. Your insinuation seems to be this is somehow the fault of systemd for requiring a shim for things like GNOME, if you want them to work without systemd itself as PID 1. But the reality is that any software which has an API dependency that you want to replace is either going to A) need a shim or B) need a replacement that is also supported by the project. And the ship already sailed on option #2 - ConsoleKit held on until upstream decided to remove the bitrot.
I find this line of argument very weird. Indeed, this whole scenario seems to be a story of exactly how FOSS often works and how we envision it to work: people do the work, and in some cases they may compete with or achieve superiority over another project. And other people adopt that work and use it for their own work later on. And people may develop replacements that are or are-not compatible as they see fit.
It's probably very true that GNOME and systemd developers worked together to reach agreements on systemd-logind, so it could be used by both and they could understand each others needs. But why is it systemd's fault if nobody stepped up to maintain ConsoleKit, and systemd's fault if GNOME decided to remove support for something they saw as bitrot? Am I missing something extremely key here? Or do you consider this nobody's fault and just something that happened?
Stopped by Poettering, because there was corner cases where Consolekit could not reach. In essence, Perfect became the enemy of Good (tho that consolekit was ever good outside the fevered minds of some control freak in a uniform is anyones guess).
Systemd is seemingly deliberately designed to be difficult to replace. And it causes problems on some Debian platforms right now - as someone who was about to install Debian/kFreeBSD on a server, I am now very worried about the project's future.
Yep. right around the announcement of the GR there was a bug reported where installing one package would result in pam-systemd getting pulled in, and then it would cascade until sysv was replaced by systemd. I do wonder how many such bugbears there will be before there is a collective "fuck this" and just a blanket mandate of requiring systemd components everywhere...
I'm starting to wonder if this is a problem with modern culture in general -- all over the place I'm seeing less "let's try our different approaches and see who has the best end result" and more "I will rape you to death with a flaming donkey for not running your project my way". It's like nobody wants to do any work to demonstrate that their way is superior, they just want to sit back and bitch about how the other way is inferior, until the other team gives up and our overall result is nothing :-/
(See also: both sides on pretty much any political issue in the past few years)
Downvote all you want, but this expression needed a reaction !
Of course English being not my mother tongue I didn't have enough vocabulary to express my distress at the mental picture that exploded in my brain when I read those words.
I thought "dude" conveyed best my disgust, puzzlement and amazement :-)
Both sides did lots of work to make their solution better and each side had a sizable list of legitimate advantages over the other. The ultimate decision came down to a subjective value judgement about which advantages were more important and inevitably wound up ignoring about half of those honestly held priorities (not to mention the work that went into Upstart). I don't see how it could have happened any other way.
It's sad that people resigned over it but the pain itself seems unavoidable from where I'm sitting.
> the pain itself seems unavoidable from where I'm sitting.
If there's enough time and energy in the community to be throwing death threats around, surely there is enough energy to maintain debian/systemd and debian/upstart as separate distros, both of which live happily ever after, sharing the 99.999% of code and infrastructure that they have in common? Then if one side really IS technically superior, people will naturally end up moving to that one and the other will die a gentle natural death, no personal attacks and resignations needed.
(For example, see what happened when Canonical wanted Debian to be more apple-like -- they didn't send death threats to Debian developers, they just did the work that they wanted to see done, and now both projects are a great success)
That was the Linux community of old. These days it seems it is the old hats that is required to fork if they want to maintain their tried and true ways rather than risk their systems to a massive switchover.
A better political analogy would be comparing the talking heads on propaganda TV channels vs the lobbyists and corporate donors who actually run the .gov.
There's some strife at both levels, the level of discourse is quite a bit different as is the level of publicity, and the level of actual impact.
You could be correct about modern culture and public non participant trolling culture. But there are more groups involved than just that (loud) group.
I have to assume this is Arch-specific, because I can't anything that basic as util-linux including a dependency on a specific init tool (and given there are still distros using other inits than systemd and still working fine...)
As a sysadmin and developer I don't understand this systemd-hate. If you ever have written a /etc/init.d script for a python non-daemoning script running in a virtualenv, or something to the same effect, you'd notice the improvement over SysV init scripts.
Upstart is nice too, but as a Linux desktop user I love socket activation: I can have cups, avahi and other optional/non-critical daemons "active" but not actually using any resource, until effectively used by some other process.
>If you ever have written a /etc/init.d script for a python non-daemoning script running in a virtualenv, or something to the same effect, you'd notice the improvement over SysV init scripts.
These are solved problems. You're creating a bunch of low level OS spaghetti because you don't want to have to write a shell script for your software? That is not a responsible decision-making process, that's moving the mountain to you.
Countless subtle race conditions and security issues in the shell spaghetti that makes up real-world init scripts indicate that it's not a "solved problem".
I look forward to seeing what these people will all create now they're not involved in Debian. It's not a good situation, but it does mean there's talent free to tinker with new ideas.
Debian has ports to FreeBSD and HURD; systemd doesn't support anything but Linux. I would assume that this would make systemd a non-starter in Debian (especially since there are no technical reasons systemd couldn't be ported).
There are also other issues. Yes, sysvinit doesn't parallelize scripts or do automatic dependencies. If that's all systemd fixed, I'm sure everyone would be for it. But systemd seems to be consuming everything in its path (logging, cron, etc), ignoring the well-proven and time-tested design tenet of "do one thing well".
I think Debian's supported parallel script execution and dependency resolution on top of sysvinit for a while anyway. It's not a true dependency-based init because the dependencies are resolved at configuration time rather than runtime, but whether that matters depends on what you're doing.
That's a bit of an overstatement; it's responsible for very few technical decisions in Debian, and doesn't normally have even a theoretical ultimate-decision-maker role of regularly reviewing or steering them. Their only role is technical dispute-resolution, and they are supposed to wade into even that as minimally as possible. Most technical decisions are made by a mixture of individual package maintainers, the Debian Project Leader and release-management team, and informal consensus-building. To the extent there's an "ultimate" technical decision-maker, I would say for the majority of issues, the release team working with the project leader functions in that role.
systemd is designed to work with Red Hat's way of doing things. For example, they've never supported upgrading to new distro releases from within the running system - you're supposed to either boot from the install CD or reboot into a special pre-boot environment - whereas that's the normal way of upgrading Debian. So systemd is designed under the assumption that major upgrades will only happen through that special preboot environment.
I would like to point out that of the 5 people being talked about here (Colin Watson, Russ Allbery, Ian Jackson, Joey Hess, and Fog Heen), only one of them has actually resigned from Debian as a whole in any real sense (Joey Hess). Colin Watson is still on the TC for the time being, Colin, Russ, and Ian are all still acting in their other roles as DDs, maintainers, what have you, and Fog Heen has only indicated that he no longer is the maintainer of systemd. Four of these five people have expressed an intention to continue being involved in Debian, just not necessarily in all of the same roles they have been.
This is a confidence builder for migrating my two servers to FreeBSD from Debian. I don't have a problem with systemd from a technical perspective but I do have a big problem with politics getting in the way of progress or forcing hands.
Depending on what you're interested in, I don't think you need to be involved in politics in the Debian world. I've been a minor participant for years and haven't run into much. A huge proportion of decisions, even some fairly complex ones, are made without fanfare. Most of that happens in the discussion threads of individual bugs, on the various collaborative-maintainership mailing lists, at Debcon, etc. There are definitely issues that do have a lot of fanfare, but they are fairly uncommon.
Why that? AFAIK, they were not allowed to use the name firefox since their version of firefox contains or used to contain unofficial patches and mozilla forbids the use of the name "firefox" in that case.
Renaming was one of the options, dropping the patches the other.
Some do, but they have them Mozilla-approved. Vendor-specific patches are allowed in a product called "Firefox", if Mozilla approves the patches before release. I believe Red Hat is one vendor that does that. Debian won't agree to include a package that needs third-party approval of modifications, though.
That is the 4th criteria of the Open Source definition at work. I think it is a good rule, and makes sense. Mozilla is sharing their code, but doesn't want their name to be used for code they didn't approve.
Yeah, that's one of the 1% or so of politically-tinged bits of the project. The ones I can recall from the past few years are: systemd, ffmpeg vs. libav, libjpeg vs. libjpeg-turbo, and whether to ship GFDL-licensed documentation with invariant sections. Fortunately I don't really care about any of those. :-) The systemd debate is the only one of those that's actually a bit interesting to follow imo.
One quasi-political issue that has somewhat more pervasive importance is the general relationship between Debian packages and the Ubuntu packages derived from them, which occasionally is a point of friction if the maintainers have different goals. In most cases it isn't a big problem though, afaict. There are reasonable number of cases where it's even the same maintainer.
In May 2004, a Debian packet maintainer (Eduard Bloch) started to send repeated personal insults to Jörg Schilling after one of Bloch's patch requests against mkisofs was rejected because it was full of bugs.
In March 2006, a group of Debian maintainers started to attack the cdrtools project.
The latter attacks have been based on the fact that cdrtools was licensed under the GPL. As a result, on May 15th 2006 most projects from the cdrtools project bundle have been relicensed under CDDL (giving more freedom to users than the GPL does). At the same time, an important amount of additional code (DVD support code from Jörg Schilling and a Reed Solomon decoder from Heiko Eißfeldt) has been added to the freely published sources.
In summer 2006, the attacks from the group of Debian maintainers escalated and in September 2006, these people created something they call a fork from cdrtools. They soon added a lot of bugs and this way turned the "fork" into a questionable experiment. The last work on this "fork" has been done eight months later on May 6th 2007, then the leader of the attacks stopped his efforts on the fork and instead started to advertize for nerolinux. During the Debian project activity, the source code distributed by Debian was modified in a way that violates GPL and Copyright and makes it impossible to legally distribute this "fork" called "cdrkit". There is no license problem with the original cdrtools.
Ok, we can add that: there was also a debate about a cd-r/cd-rw app, spanning a period roughly 7-10 years ago. I'm not arguing that there has never been an acrimonious debate regarding a Debian package, just that it involves a vanishingly small proportion of packages. So few that I mostly only hear about these things via places like Slashdot (or a comment like this one).
Ok, I agree with you entirely, just a quick response because I was quoting and so have the responsibility to avoid distorting other people's words. This didn't happen 7-10 years ago, that's when it started, but this continued happening until 2 or 3 years ago.
I hope all is clear now.
"""
Ask your Linux distributor to include recent originals instead of broken forks.
Tell them that you like to decide yourself which program you choose. Whether it is the fork or whether it is the original program depends on which package works better.
[...]
The following Linux distributions currently work against the freedom of their users:
Debian, RedHat, Fedora
If you know of other unfree distributions, please report.
The following Linux distributions currently grant their users the freedom to select the better CD/DVD/Blu-Ray writing software:
There was no debate; the developer of cdrtools was just an asshole who (for example) refused to let users specify their CD-ROM drive by its actual /dev entry because he thought Linux should use (scsibus,target,lun) to identify devices like Solaris did. Eventually he fucked up the licensing of cdrtools enough that distros couldn't legally distribute it, Debian forked the last legally-distributable version under a new name, and all the other distros switched to their fork.
> Except that most distros DID distributed it UNALTERED, like Slackware, Gentoo, OpenSuSE, Ark Linux.
Only the ones small enough that they don't worry about getting sued. It's not just Debian developers that think there's a licensing issue that means they can't legally distribute it; the FSF and Red Hat's legal department also agree[1], and I believe even the authors of the CDDL (the GPL-incompatible license he's releasing most of cdrtools under) think that he's wrong.
> Only the ones small enough that they don't worry about getting sued
You got it backwards. Precisely only the big commercial distros with mighty legal teams (Debian, RedHat, Fedora) could afford to get away with violating the GPL, and stealing the name of the original project for the fork symlinks. Try to name your toy project something even remotely similar to redhat or debian and you'll be crushed like a bug.
Here I see powerful entities taking advantage of an individual hacker.
""" During the Debian project activity, the source code distributed by Debian was modified in a way that violates GPL and Copyright and makes it impossible to legally distribute this "fork" called "cdrkit". """
""" The GPL preamble (see also Urheberrecht §14 below) disallows modifications in case they are suitable to affect the original author's reputation. As Debian installs symlinks with the original program names and as many people still believe that the symlinks with the original program names are the original software, Debian does not follow the GPL.
GPL §2a requires to keep track of any author and change date inside all changed files. This is not done in the fork.
[...]
GPL §3 requires the complete source to be distributed if there is a binary distribution. The Debian fork tarball does not include everything needed to compile the cdrtools fork (complete source) and Debian does not give a written offer to deliver the missing parts. """
> Try to name your toy project something even remotely similar to redhat or debian and you'll be crushed like a bug.
In Debian's case at least, I don't think there's an objection to third-party projects or forks using names derived from the name "Debian", so long as they aren't actually identically the name "Debian". For example, there is a distribution called "Illumian" which is made up of the Illumos base OS and a Debian-derived userspace.
Besides, I don't really see a trademark issue here. The term "cdr" preexists both of the projects, and is owned by neither of them. A person named their software after a fairly generic derivative of this term, "cdrtools". And now they are complaining that someone else named their software a different generic derivative, "cdrkit"? Do they claim that nobody else should be able to use the prefix "cdr" followed by a noun? Given that they did not even invent the prefix "cdr", that seems like quit a stretch. That's like someone who named their backup product "Backup Tool" complaining that a different product is named "Backup Kit". Sorry, but you don't own the word "backup".
They did that so that scripts which run "cdrecord" or "mkisofs" continued to work, which I'm pretty sure is allowed under trademark law (trademarks don't apply to functional elements - if it wasn't for this, Oracle and Microsoft could kill off any third-party reimplementation of Java or many Windows APIs quite easily). If you run "cdrecord --version" it tells you that it's actually Wodim.
Then be happy: the result of the vote is a clear majority of Debian developers saying "no more politics on this init topic" (by rejecting this GR as uneeded).
In all group of a given size there's bound to be some amount of politics, even if it's desirable to keep it low. What's specific to Debian is that 1) it's big 2) it's fully open. That makes any emotionally loaded discussion noisy and widely heard. One just has to understand, accept and keep cool about this. Sausage taste best when you don't know how they're made for sure, but I still like the Debian sausage anyway ;)
>the result of the vote is a clear majority of Debian developers saying "no more politics on this init topic"
No, it's a thin majority of devs saying, "lets not make a decision of any kind, so please continue fighting these political battles amongst yourselves".
Just wait for Jessie, you'll see. Package dependencies are going to become the next huge political football.
Eh, if you're worried about politics of the form of resignations/splits/forks and their impact on technical and social decisions, I'm not sure where in free software you can go. The BSD world has had its share of strong disagreements and resignations, which is why for example Theo de Raadt is no longer a NetBSD developer, and Matthew Dillon is no longer a FreeBSD committer. Though the BSD scene is as bit more stable at the moment than it was a few years ago.
> Eh, if you're worried about politics of the form of resignations/splits/forks
Splits, forks, and resignations sure do happen. However, it doesn't require votes, committees, lobby groups, rants, arguments and flamewars on blogs, bugs and mailing lists, complete with news coverage of the drama. It doesn't need to drag on forever... I think that's the part that makes it very much look like politics.
Ladies and gentlemen, this is open source at work. Open source empowers people and if you don't like it some way, you have the power to move on.
There are so many other platforms that this will never be possible on. Don't like something in Windows, tough. Don't like something in OS X, tough. Don't like something in Linux, xBSD, etc? Fork or go home.
I'm excited to see what happens next and if it will be folded back into Debian in the future.
I'm sorry but I really don't understand this comment. If you don't like something in an open-source project you can walk away, but if you don't like something in a proprietary project you can't?
Also kind of the opposite of the open source 'Don't like it? Fix it yourself' mantra. (of course there's lots of truth in that, but people sometimes throw this at me when filing bug reports for a project I know nothing about except how to use it, not even the language it is written in, which make them come over as extremist crusaders:)
We used to say "linux is about choice". It was a point of pride for Debian that it ran on dozens of platforms - multiple architectures, multiple kernels even - that multiple desktop environments were available, multiple MTAs, multiple webservers, all fully supported, all benefiting from the shared infrastructure and spirit of collaboration. Debian runs on enormous Itanium servers and tiny ARM chips, and it doesn't need a fork to do so.
It's sad to see an end to this era - and it's an end that's been brought not by Dr Jackson (who's been part of Debian for decades) but by SystemD abusing the spirit of openness, following the letter of open source but not the spirit of open standards, of allowing a diversity of solutions to blossom and letting users mix and match whatever best suits their needs.
There will be a fork; there are enough people who care about good engineering not to let this lie (unless they all turn to FreeBSD). But it's sad that it's come to this, and it shouldn't have happened this way.
If everyone has their own forks that's a lot of wasted effort compared to everyone having their own packages but using shared distribution infrastructure.
Actually one of the biggest problems with systemd is its refusal to cooperate with other system components. Need a binary log format? Let's write our own! Need a database? Let's embed our own! Interoperate with ConsoleKit? Nah, we'll just reimplement a replacement.
Given that the second most prolific committer to the ConsoleKit git repository is a certain Lennart P. it is reasonable to assume that the systemd people did not decide to implement logind from scratch because of NIH syndrome.
Would not the traditional option be for the systemd proponents to form, and then demonstrate that their alternative works? Then people could move over at their leisure?
I ran something called InitNG for a while under Gentoo, and I know there are people running Gentoo's openrc on Debian (though technically that still uses sysvinit as PID 1, it just replaces the service management layer running on top of it). Most Docker containers are running something different from the standard init, though what exactly they use varies. And so on.
YEp, i don't think people know how minimal the core of "sysv" really is. There is one binary, init, that do the initial (heh) lifting. From there on it hands things over to one or more files. These can be binaries, scripts, or a mix of both.
Are you serious? sysvinit's modular architecture allows an easy substitution with other alternatives, that's why you can replace it with say systemd and have a working system.
I think you missed the point. Prior to systemd, Debian was truly the universal operating system in the sense that it ran on just about anything, and you could swap out the kernel (not a trivial thing to do, but possible) for the FreeBSD kernel, for example. Because systemd is Linux-only, this is no longer possible. Because the list of smaller userspace utilities dependent on systemd is growing faster every day, it's likely that Debian will end up being no different from Arch, Fedora, RedHat, or Mandriva overall, apart from the package manager. Basically GNU/Linux is becoming GNU/systemd/Linux.
Some people don't have a problem with that, some do. In the end it's not about choosing an init system; indeed, I think a lot of the arguments and opposition to systemd would go away if systemd were interchangeable with any other init. But that's not the case; if your distro of choice has decided to go with systemd, then you're running systemd or you're not booting (yes, there are shims in Debian right now but they exist only for migration purposes).
How so? Debian runs on more architectures and with more flexibility (prior to current events) than any other GNU/Linux. NetBSD also runs on just about anything, including toasters, but systemd isn't an issue there since it won't work on any BSD. I'm not sure why you would think that I was confused about it at all.
Alternative init systems are a very old idea implemented over and over for decades.
The "innovation" of systemd is product tying it deeply to Gnome. Nobody is willing to kick out Gnome, so they can make everyone else do whatever they want. Including, say, making it impossible to run any other init system.
By analogy it would be like product tying emacs into python, such that you can't install or run vi if you have python installed at the upstream level, because the default location for python temp files is now /usr/bin/vi. Well, I guess you could stop shipping python, or cave in and remove vi. This is the "innovation" that is new in systemd. Merely being an advanced init is really old stuff.
And if it was done commercially, an antitrust lawsuit may have been considered. It is that kind of tying that got MS into hot water regarding IE after all.
To argue the other side, if you don't like something in OS X or Windows, you can type "vim my_os.cpp" and start implementing your own version from scratch.
If three years from now, everything from Firefox to GNU tar depends on systemd, then your open-source Linux is in the same boat.
[Edit: Just to be clear, I don't expect that to happen. I'm just pointing out why people get upset when systemd encroaches on very large numbers of system components.]
I'm very concerned, systemd becomes system-Destruction, people are leaving for BSDs likely because of it too.
It's very sad to watch this, systemd is too intrusive with the strong support from the OSS Microsoft, that is, the Redhat behind the scene. No other project can be so controversial so fast, it's really bad.
I followed a link to webarchive and, coincidentally, ended up on the slashdot homepage from about 2000 I think, RedHat was becoming a threat to Linux, just like Microsoft, and it's interesting to me how well they predicted the future, they noticed that GPL, open source... (as Microsoft's github account shows) wouldn't stop a company from maneuvering, entrenching its position and dominating the marketplace.
If all these people dropping out of Debian is due to systemd, somebody needs to step up and force some kind of compromise. (I have no clue who; does Debian have a Dictator For Life position?) I may not like systemd, but I sure as shit would find some way to coexist with it rather than drive people away from a project.
> If all these people dropping out of Debian is due to systemd, somebody needs to step up and force some kind of compromise.
That's what Ian Jackson proposed - that while systemd would be the default, Debian would fully support users using other systems (bugs that only affected SysV users would be considered equally critical). He was voted down, hence his resignation. The systemd folks don't seem to be interested in compromise.
From what I gathered following the discussion the problematic option was actually "no package that depends on systemd and does not provide an alternative that works with sysV is permitted". That would require that somebody provides the code to make the alternative way viable, work that neither the upstream would do nor the maintainers were willing to shoulder. It's fine to make that demand, but if you do, IMHO you should also step forward and say "and because this is what we propose, we will be providing said code."
Yes. Saying “We permit systemd to exist in Debian, but we will not permit any packages which uses systemd’s extra features or advantages.” is hardly a compromise.
why not? If a package leverages functionality that only systemd provides and users want to have install package, they have to bite that bullet and install systemd.
What are the alternatives? You can't force the upstream or the package maintainer to invest the extra work to make the package work without systemd, you're not providing the required work either and you certainly don't want the user to be on the loosing side because you don't like systemd.
> you certainly don't want the user to be on the loosing[sic] side because you don't like systemd.
Debian has a long and glorious tradition of standing on principle to the user's (at least short-term) detriment. Look at the way they used to ship KDE programs (especially in the days before GPLed Qt), or the way they still package tomcat, or their approach to multimedia codecs.
Why not? This thing here, where a package fails to work without another specific package, is called a dependency, and that is is the normal way to do things. Just because you don’t like package A does not allow you to “compromise” by allowing A but not allowing B, C or D to have a dependency on A.
Anyone knows how this could be done in practice? I mean, in programming you'd solve a problem like this by defining a proper set of interfaces and making sure each implementation adheres to it. Form what I read in this thread, part of the problem seems to be there is no such interface and hence developpers depeninding on an init system have to choose A or B or do twice the work.
From what I understand of systemd, it's more a factor of there being an entirely new inter-process communication mechanism, combined with a lot of custom applications. And because it's this top-down monolithic design, either you use systemd as your init, or you get none of the functionality of the custom programs... so it's all-or-nothing.
On top of that, the people who don't want to use it are against the idea of supplanting the core technology they're used to. So you have this one camp that's all "fuck yeah new technology", and another camp that's like "get that shit out of my box."
In a way it's like GNOME vs KDE, but almost at the very heart of the operating system. You just have to pick one and go with it, or you don't really get the benefit of either.
The 'set of interfaces' you mention should (imho) be patches to systemd to allow it to work as not-pid-1, so that you can still take advantage of its contributory applications without having to supplant your init system. That way you could use 'a gtk application in a kde workstation', but with systemd and sysvinit.
If I had a penny for every Debian bust-up I've read about on LWN...
Debian will survive. That constitutional document and those processes people like to moan about all the time, are the same document and processes that ensured Debian's success, solidity and continuous development. For every great engineer stepping down, I'm sure Debian will attract new talent who wants to make a difference. For every controversial decision like on systemd, there will be a time when that decision will be either vindicated or corrected. Like the Linux kernel, the Debian project is now too big to die because of a single but controversial technical choice.
systemd is not an init system, that's how it started, but they state they want to comprise a whole OS.
Debian may seem too big to die, but they are slowly being commoditized away, because RedHat is known to offer better sales force, better service and support:
How do you differentiate your product if your core mission is to ensure
that your product operates exactly as your competition? The bottom
line is that you don't
"because RedHat is known to offer better sales force, better service and support"
And tremendously longer support periods.
Right now I'm helping a non-profit move from squeeze and XCP/XenCenter (which is CentOS), which I initially set up for them, to wheezy. And we're looking rather enviously at the RHEL/CentOS support periods. Even before this systemd debacle, something else was looking likely for when wheezy support ends.
Don't quote me on this, but I recall reading from official channels that the last Debian version without mandatory systemd is going to see its support period indefinitely extended for a long time. Good luck! :)
If it's anything like the squeeze LTS experiment it's not going to be suitable for a number of people. There are a number of things they've been forced to abandon for various reasons.
And per the above experiment, it's not something you can depend on, not something you can build your plans around.
> because RedHat is known to offer better sales force, better service and support
When did Debian ever offer support or sales? Debian is not a corporation, it works under a different paradigm. Debian will be the last Linux distribution to die, and it might even survive as a non-Linux OS. As long as there are people who can benefit from a free open-source operating system, and people willing to dedicate their time to make it possible, Debian will live on.
That's precisely the point, it's part of the quote, the more Debian standardizes on the upcoming systemd distro, it'll get erased by RedHat real fast, who offers a differentiating advantage.
How do you differentiate your product if your core mission is to ensure
that your product operates exactly as your competition? The bottom
line is that you don't .... Theoretically, you could have a better
sales force or better service and support .... Yet these are the assets
of the larger, entrenched companies.
> As long as there are people who can benefit from a free open-source operating system
As if Debian were the only free open-source OS... Not even considering only GNU/Linux, where Slackware was first (why not also last?).
> and people willing to dedicate their time
A complete OS will take much more than that, if Debian loses relevance, people will leave. What differentiating advantage to choose Debian over CentOS or Fedora? Debian will have to fight that battle, being or not a corporation is irrelevant.
I hope Debian endures, but you have to understand that systemd standardization is not going to be positive to Debian relevance.
It's the only free open-source OS backed by an explicitly democratic approach, enshrined in its constitution. It's "the GNU System that works, will always be Free, and will give an equal say to any developer" (at least in theory). All the other distributions are owned by a specific group of people (or in the RedHat case, by shareholders) and/or are not Free. That's the Debian differentiator that RedHat will never be able to match, no matter how many "community editions" they sponsor.
> What differentiating advantage to choose Debian over CentOS or Fedora?
Those are both owned by a corporation.
> being or not a corporation is irrelevant
I respectfully disagree there. You just have to look at the evolution of the Linux ecosystem to see how "being or not a corporation" makes a huge difference. History is littered with corpses of Linux vendors. In fact, there is an argument for big Linux projects being naturally incapable of making money as corporations in the long run, a concept that was seriously challenged only by RedHat and Ubuntu at this point.
> you have to understand that systemd standardization is not going to be positive to Debian relevance.
My point is, if that's the case, the project will likely have the necessary strength to reconsider and correct this choice later on. It's not like they can "run out of money" or something like that; they have such a huge mindshare that it would take ages to dissipate, and votes seem to indicate that most developers don't really care about the init system that much. If things come to worst, Jesse will just go down in history as a terrible release (wouldn't be the first...) and the project will move on.
If anything, it's downstream projects that have to worry (i.e. Ubuntu) since they have to differentiate in a competitive market, but they seem to have already adopted systemd, so...
> "being or not a corporation" makes a huge difference
Take a look at Mozilla, they implemented DRM, otherwise they could have lost relevance, they explained.
Now Debian must commit resources just making everything work with every new "innovation" brought by systemd. RedHat will dictate the pace and the terms, Debian will follow, and once the future "systemd + linux OS" integration has been declared standard, they can't correct the decision, they will be stuck with "systemd OS" forever.
I think this is only the beginning. The Linux community is in the midst of an identity crisis. Linux has a well established history of fragmentation. Fragmentation represents choice, flexibility, modularity and so forth. It also represents control for the individual user. For a long time, this was considered Linux's biggest strength. It was the anti-Windows. However, in the past few years a unification movement has grown, largely inspired by OSX. I think GNOME has pushed the hardest in this direction, systemd is just the latest battle. The success of Ubuntu has also added fuel to the unification fire as it continues to break away from the old guard and build their own unified experience (Unity). While I think unification has its merits, it will continue to meet significant resistance as long as there is still a large contingent of fragmentists (just made that term up). I think it will come to a head in the near future and the Linux community will break into two sides; the unification side and the fragmentation side. The irony is that the unification side stands as much a chance of fragmentation, since it appears Ubuntu will continue to move away from GNOME. But so is the nature of OSS.
That means today is the last time I install a debian-derivative on a machine.
I mean, I had switched to gentoo for other reasons, but when the founder steps down over systemd, this means we're seeing a quiet war being waged. And it isn't by the guy who put the Ian in Debian.
203 comments
[ 3.3 ms ] story [ 242 ms ] threadAlso, I assume this is not directly related to the recent resignation[0] of Heen. But does the resignation of two people (whose resignations were deemed worthy of being voted to near the top of the HN front page) within a few day span suggest concernening structural issues or is this just poisson statistics at work?
[0] https://news.ycombinator.com/item?id=8617874
Vote: https://lists.debian.org/debian-devel/2014/11/msg00891.html
How many votes will there be about systemd in Debian that will turn out inconclusive?
Also, I have yet to see a single article of somebody running into all the various horror scenarios envisioned by adversaries of systemd. I mean: Multiple distros have already switched and there still aren't that many blog posts about systems dying in flames because of the switch.
I would so love for this discussion to happen based on technical merits and (by now actually available) real world experiences than FUD (on both sides)
Perhaps the only thing everyone on all sides can agree on is funny, is that "further discussion" didn't get many votes. Somewhere last night I read a quote about there's hundreds on each side but only nine masochists who voted for "further discussion"
There can only be a single default init system obviously, so a vote was required there. It was a hot topic, no need to rehash this.
The second vote, initiated by Ian Jackson, was controversial from the start. A lot of people were tired about the init topic and wanted to move on, and didn't want the GR. And they got the majority here: the result of the vote is "General Resolution is not required". This is the majority clearly expressing it's now time to move on. And to be honest I'm happy about this, although I'm just a Debian user and do not vote. With this, it's now unlikely to be another vote.
And this desire to move on can be now felt on all sides of the argument, hence the resignations and people moving to other things. I just want to point out that except for Joey Hess (really sorry about that) all are still remaining part of Debian. They just move out of the TC (or systemd maintainership) but are still DD, working on some parts of Debian.
And now, hopefully, everyone can cool off and move to other things too.
It's not incorrect to do that. Nothing crashes. It might actually even be faster or use less memory if you were sufficiently clever about it. However, the argument is that you just bought yourself a future full of pain and misery for not a big enough present gain.
Look at poor technical decisions from the past. The earliest browsers were encouraged to be liberal in what they accepted (an adaptation of Postel's law to HTML parsing). I think a lot of people today regard that as a decision that probably held the internet back by a decade -- think of the time we wasted writing compatibility layers and artificially restricting what our web pages could do. But it wasn't immediately obvious that that was the case. It took 10 or 15 years for the implications of that decision to really hit home.
What happens next is not a collapse of the world. It's a slow accrual of follow-up decisions that are needed to keep the lights on, until one day you look at the Eldritch horror you've had to build over 10 years and go, "Jesus, that was a bone-headed idea." Maybe they're completely wrong in opposing it, but systemd isn't anywhere near old enough to have decided that just yet.
And there wasn't a faultless alternative either. It's not like upstart or sysvinit was so good that you need to invent anything to explain why systemd won out. It won out because people either don't share my mild aversion to its design or because they chose functionality on Linux over elegance/portability/fill-in-your-own-thing. And hey, that's a Pareto-optimal choice as well.
One i found some months back when the whole systemd issue got my attention was of someone that ended up doing a parallel arch install to read the journald logs.
Going from memory the problem seemed to be that he could not run the required command to get the logs dumped into readable form without systemd running as pid1. And systemd was refusing to boot for no apparent reason.
Thats the kind of thing that will get seasoned admins, that are used to cat being all you need to get at the logs, backing away with a "no way, no how".
As far as I can tell, the whole brouhaha started when there was a bug in the packaging of syslog-ng so it would not start properly after installing systemd. Since syslog-ng was not running, the only logs left were journald’s binary logs, and people assumed that “systemd ate my log files!”. No. It was a bug, the bug was not even in systemd, your log files will always be where you want them.
Unless you uninstall your syslog daemon, but then you are on your own.
https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBA...
https://lwn.net/Articles/621895/ https://lwn.net/Articles/621003/ https://lwn.net/Articles/620879/ https://lwn.net/Articles/620878/ https://lwn.net/Articles/619749/
They are related in the sense that are all fall-out of the struggle to integrate or block systemd in Debian and/or how it exposed some problems with the Debian constitution.
It's a shame to see that so much talent is lost and frustrated over what in my eyes seems to be a small issue. systemd and Upstart are both a large improvement over the System V init scripts. So, it's quite logical that it should be replaced at some point. Since systemd seems to have the most traction in other major distributions and upstream software, it makes sense to make that the default, while making it still possible to switch to Upstart et al. if someone wants to (at the risk of losing support for some upstream software).
If it turns out in three years that systemd is a dead-end, rip it out, and use whatever is better then. Distributions did that with devfs, the old hotplug scripts, egcs (which was merged back in mainline), etc.
Personally I don't really care much either way.
Definitely. But this is probably true for many things at a low-level in the stack. E.g., it would also be hard to replace D-BUS or the Linux kernel (as evidenced by the fact that Debian/KFreeBSD will probably not be in Jessy).
I agree that it is a worry. But you can never make progress without taking any risks. We have tried 'fully isolated init' for years and it does not really work for modern systems/applications.
The way I see it is that the systemd developers just plowed a way through the undergrowth and produced a suite of components that provide functionality that's appealing for people to build on. That's an offering that was accepted and now other people complain that the "systemd people are forcing their system on us and I want sysV init". The right course of action would be "meh, don't like systemd, I'll build a better offering." Talk is cheap, code is what counts.
I very much like systemd. It's documentation is actually long, but clear and well structured. The init component is much simpler than the mess of shell scripts used before. There certainly are problems and issues with it, but I've met problems and issues with about any kind of software I had to deal with so far (including my own), so I take that as a given.
I know dozens of init systems that do much more, markedly better than systemd, and are modular so you can easily replace them when the time for a new technology comes. systemd is very recent, and still its opinionated architecture is showing inflexible to changes.
(1) systemd (2) write and advocate the usage of a different init system. (3) a horrible death
I'm certainly not opposed to having a better alternative, but the systemd people managed to write something that is better than sysvinit and made the package good enough to get people to use it. Now people complain that they're taking over the linux world by force, but they actually don't. They just provide something people want - it's not that they forced the gnome people at gunpoint to use systemd.
The problem is that systemd is that is being forcefully pushed to all distros. For instance, by merging udev with systemd. We want to keep all the alternatives available.
I understand your pain, I sometimes don't like the direction things that I use move or the ways they change, but I'm not sitting at the sidelines complaining about being pushed around. I get to use stuff others provided for free, I'm grateful for that and I either fork/change it or move on to something else. I'm not in a position to tell them what they should be spending their time on.
Lennart Poettering could just stop developing and supporting udev any second, that's his personal decision and I couldn't say "he forced me to use windows" and I don't see anybody else could.
Don't like the (maybe) coming systemd dependency for udev? Build the code to set up the bus yourself or pay someone or wait until someone knowledgeable gets sufficiently fed up and builds something. Same for the gnome dependency on systemd: Either accept it or contribute the time to make it work without while retaining the features it has.
Also, Windows can also be forked, by distributing patches instead of binaries. So that argument is a red herring, DOS has been forked before, and every proprietary application, but that doesn't mean I can't ask other developers a bit of respect for those of us who are using other init systems, I will maintain my software, just let me do that. All the discourse about democracy around GNU/Linux wasn't supposed to be summed up as "Fork or GTFO".
Yes, indeed, I do. Because most applications will not unnecessarily depend on systemd, but rather because the dependency provides some (perceived) benefit to the developers. And if the developers decide that the benefit is worth the dependency, they'll do it. And if you want to prevent that future, you need to provide something that offsets the benefit - write the test and compat code to support gentoo, write the docs, provide the money (or other incentive) for the developers to do so. That's how it works. You don't have to do all of that yourself, you can form a group, build your own distro, run a fundraiser, whatever you choose. But you don't get to sit back and complain and hope the world changes for you and neither do I.
There's no democracy in the OSS scene, users don't get to decide what the software they use looks like and even maintainers or other software have no vote. It's more like a market - we use what's best for our personal cause. You pick and choose and the software with the most users will prevail, others either hold their ground or disappear (ConsoleKit).
All this discussion doesn't and won't preclude me from do all the things you said under "preventing the future".
People developing software. For example the gnome folks. You, me. (don't know about you, but I have services that use systemd for starting and supervising the service)
> If GNU/Linux closed its source and went proprietary, you would say exactly the same things: Fork or GTFO.
Yes, actually, yes. If Linus decided that all future development he wants to do is now closed source, I either have the option to fork and continue in the open or GTFO. I'm not the one to decide what he can to in his time. There's be a number of legal issues surrounding that, for example that he can't take the current kernel code, but if he decides that within the given framework he closes his development, fine with me. If Linus decides that he thinks that a deep integration between the kernel and systemd is the way forward for his project, I have to accept that. I may not like it, but unless I do something to change it I can't force it any other way.
The beauty of OSS is that you can exactly do that - take the last public version and make something better, something that's more the way you like it, no matter what the original owner thinks, says or does.
> The beauty of OSS is that you can exactly do that - take the last public version and make something better, something that's more the way you like it, no matter what the original owner thinks, says or does.
Read my previous comment: The beauty of proprietary software is that you can exactly do that - take the last public version, patch it and make something better, something that's more the way you like it, no matter what the original owner thinks, says or does. :)
Why not? Do you pay them for their time? I don't. So who am I, what do they owe me? Nothing. Not even a new free version of linux.
>Read my previous comment: The beauty of proprietary software is that you can exactly do that - take the last public version, patch it and make something better, something that's more the way you like it, no matter what the original owner thinks, says or does. :)
No, actually you can't. You're not entitled to unless you specifically sought a license that permits it. All Open Source Licenses grant you that permission.
> No, actually you can't. You're not entitled to unless you specifically sought a license that permits it
Please take a look at 17 U.S. Code § 117.
No, why? If they port it and even if they provide it closed source binary only, I'd still believe that an open source browser and office packet are fundamentally more in societies interest, but they're certainly entitled to build and distribute IE and Office for linux/unix/catOS and I'm not entitled to tell them to stop. Given the license of pretty much all linux distributions I think nobody would be. Just as microsoft allows the distribution of OpenOffice and Firefox for Windows. They don't have to like it.
>> No, actually you can't. You're not entitled to unless you specifically sought a license that permits it
> Please take a look at 17 U.S. Code § 117.
I'm not going to discuss american law with you, but please note that this paragraph puts severe restrictions on redistribution of copies, while the GPL does not. I'm not a law scholar, much less an american law scholar but I don't think this means what you think it does.
It seems you don't read my comments, because I've edited binaries, and distributed patches of proprietary software, that's not illegal, only I didn't distribute the binary or code without permission. Let me tell you, having systemd source doesn't help me at all because it's a megalithic blob.
Is the GPL a good thing? Yes, BUT just because you license your junk with the GPL you don't deserve a Nobel peace price. You seem to think that had Hitler released a hello world program with a GPL license he would be a saint, and can't be criticized, "fork or shut up", you say?
> As long as you're not distributing the software, you have nothing to worry about.
You're not allowed to redistribute the software, modified or not. GPL or any other OSS license grants you the the permission. (and no, distributing software under GPL does not make you a saint or even a good person. See Reiser)
>> GPL or any other OSS license grants you the the permission
The sysvinit alternatives that I know and use, all use an OSS license, most of them less restrictive (BSD or MIT). I use free (as in freedom) software; that's why systemd is harmful to me, always trying to create incompatibilities with other open source programs lacking a multi-million corporation backer.
Better in some ways, worse in others. If systemd were unequivocally better in all areas, nobody would be complaining. By saying what you said, you're subtly but deliberately telling every one of those people that their concerns are irrelevant and/or a result of their ignorance. This is the systemd developers' M.O. and a large part of the reason why there's so much drama over systemd.
> This is the systemd developers' M.O.
So far I've mostly seen "we believe this is better and we'll build it this way, like it or leave." That's certainly opinionated, but hey, they're totally entitled to have that view (why would they build it if they thought it's worse?!) My view and your view may differ, but we don't get to complain unless we provide something that we think is better and get a lot of people to agree on that.
The community seems pretty evenly split on this point, with folks like myself taking the opposite view: systemd is a regression in so many fundamental areas that its improvements in things like boot times and init script syntax just are not worth the tradeoffs that it imposes. I don't care if the frogurt is free when it's full of potassium benzoate.
And I'm also free to correctly identify that their poor leadership decisions are ruining a wonderful piece of software and causing the community, including Ian fucking Jackson, to abandon the group that made it possible.
Except they've been adopted, systemd has been mandatory only in some bigger more commercial distros.
Why isn't it considered a viable alternative?
Exposing the event model directly to the jobs also made reasoning about the current system state (which is what actually matters, not how we got there) tended to make upstart jobs a lot more complicated than necessary. (This is from memory, it's been ages since I actually looked at upstart jobs.)
read comments #6 and #8 on this 5 year old unfixed bug and weep: https://bugs.launchpad.net/upstart/+bug/447654
in comment #7 on this (unfixed) bug Scott says it could be solved by having upstart use cgroups instead of ptrace to track processes: https://bugs.launchpad.net/upstart/+bug/406397
That's not that hard once you have proper dependency-driven init, Gentoo's done it for a long time. You just need some way for the networking scripts to tell init that they're started now. Traditionally they'd do it by forking into the background once they're done starting just like any other init script. It's a bit harder if the network might not become available until after startup but not that much so.
That rarely happens in server environments. I wonder how much of the recent debates about init systems is caused by the the rise of mobile consumer devices and developers' desire to cater to them.
I care when my laptop takes more than a few seconds to start up, but I really don't care when one of my cloud servers takes a few minutes to start up. Network not ready yet? Meh, we could just sleep(10) and try again.
http://0pointer.de/blog/projects/socket-activation.html
Socket activated containers:
http://0pointer.de/blog/projects/socket-activated-containers...
Resource management:
http://0pointer.de/blog/projects/resources.html
Better service information:
http://0pointer.de/blog/projects/systemctl-journal.html
In fact, the whole series is a recommended reading. Anyway, all these features requirer tighter integration with other components than SysV init. E.g. Linux' cgroups, services that support socket activation, integration with the logging system for status information, etc.
Also, a lot of techniques in systemd were already pioneered in launchd on OS X since Tiger.
Because minimal boot time is way more important than predictable, repeatable functionality. It's totally cool if some other daemon lies about whether or not my service is actually listening while just happily buffering into /dev/null. This is all brilliant stuff and a huge step forward over UNIX.
2. Socket activation do 𝐧𝐨𝐭 buffer into /dev/null; that is simply FUD.
And the purpose of systemd, as near as I can tell, appears to be making my system into a Windows box, complete with binlogs.
You should educate yourself about FUD, I recommend the Halloween documents, where they explain the unfeasibility of FUD tactics against an open source project, and that if someone tries to do it they won't get anywhere.
You're a little late; inetd(1) first appeared in 4.3BSD, c. 1986.
We stopped using inetd for reasons. Modern services don't work this way, nor should they.
There are some online communities in which that kind of thing is ok. HN is not one of those.
The word 'scabrous' means "dealing with salacious or indecent material". Feel free to inspect the image, I guarantee it's safe for work.
The first meaning of "scabrous" in my dictionary is "having a rough surface", and that's how I meant it. There's a long tradition of using that word to describe rough-and-tumble discourse, and it seemed fitting. You didn't just smack another user, you smacked them with a pointy implement (a link to an insulting image). That's not ok on HN. Neither is smacking people without a pointy implement. And telling another user "You're a liar and a coward, and you know it" is right out—a bannable offense, although we didn't ban you for it.
I'm insisting on this more than usual, because we don't want the pugilistic approach that is popular in some related (by subject matter, at least) online communities to take root here. When commenting on HN, please eliminate incivility from what you post.
Your position about the place we want HN to be is clear, but I still believe the image is not insulting or offending anybody in any way. Those who flagged it, could they have misinterpreted it as an insult to the developers? An insult to the users? An inappropriate "scabrous" picture based on the URL? Or just as an attack to a program that needs our praise?
I realize now that I was being too cute pulling out the old "scabrous" to make what is really an obvious and mundane point, and ended up confusing things. Sorry. I get bored sometimes and throw in variations which HN moderation comments are obviously not the place for. Let me try to be clearer.
There's nothing at all wrong with that image per se. It's great. I've made more than my share of Rube Goldberg analogies and know exactly where you're coming from. Had you linked to the same image in a thoughtful comment about overcomplicated systems, with no trace of incivility, of course it would be fine. It was only a problem in this context, i.e. a drive-by potshot in an inflamed discussion on a polarized topic.
It's "you're stuck with this architecture unless you redo the whole darn thing". And, again, systemd keeps getting larger and larger. As you say, it isn't that hard to replace sysvinit. But to replace systemd you need to replace / write shims for far more things. (Your window manager? I wish I was joking...)
During this timeframe, GNOME developed integration with systemd-logind, similarly to how it developed ConsoleKit support beforehand. And in fact the ConsoleKit backend was supported for a while afterwords. But this is no longer the case as nobody was willing to support it and maintain it in upstream GNOME. So it was removed.
So I'm confused by the comment. Your insinuation seems to be this is somehow the fault of systemd for requiring a shim for things like GNOME, if you want them to work without systemd itself as PID 1. But the reality is that any software which has an API dependency that you want to replace is either going to A) need a shim or B) need a replacement that is also supported by the project. And the ship already sailed on option #2 - ConsoleKit held on until upstream decided to remove the bitrot.
I find this line of argument very weird. Indeed, this whole scenario seems to be a story of exactly how FOSS often works and how we envision it to work: people do the work, and in some cases they may compete with or achieve superiority over another project. And other people adopt that work and use it for their own work later on. And people may develop replacements that are or are-not compatible as they see fit.
It's probably very true that GNOME and systemd developers worked together to reach agreements on systemd-logind, so it could be used by both and they could understand each others needs. But why is it systemd's fault if nobody stepped up to maintain ConsoleKit, and systemd's fault if GNOME decided to remove support for something they saw as bitrot? Am I missing something extremely key here? Or do you consider this nobody's fault and just something that happened?
(See also: both sides on pretty much any political issue in the past few years)
Dude ...
Of course English being not my mother tongue I didn't have enough vocabulary to express my distress at the mental picture that exploded in my brain when I read those words.
I thought "dude" conveyed best my disgust, puzzlement and amazement :-)
I don't hate you though.
It's sad that people resigned over it but the pain itself seems unavoidable from where I'm sitting.
If there's enough time and energy in the community to be throwing death threats around, surely there is enough energy to maintain debian/systemd and debian/upstart as separate distros, both of which live happily ever after, sharing the 99.999% of code and infrastructure that they have in common? Then if one side really IS technically superior, people will naturally end up moving to that one and the other will die a gentle natural death, no personal attacks and resignations needed.
(For example, see what happened when Canonical wanted Debian to be more apple-like -- they didn't send death threats to Debian developers, they just did the work that they wanted to see done, and now both projects are a great success)
There's some strife at both levels, the level of discourse is quite a bit different as is the level of publicity, and the level of actual impact.
You could be correct about modern culture and public non participant trolling culture. But there are more groups involved than just that (loud) group.
Userland utils like wget depending on a specific init package is a large improvement over sysvinit? Nope.
On Arch at least, wget depends on util-linux (package containing kernel tools like mount, dmesg etc.): https://www.archlinux.org/packages/extra/x86_64/wget/ And util-linux depends on systemd: https://www.archlinux.org/packages/core/x86_64/libutil-linux...
I have to assume this is Arch-specific, because I can't anything that basic as util-linux including a dependency on a specific init tool (and given there are still distros using other inits than systemd and still working fine...)
Upstart is nice too, but as a Linux desktop user I love socket activation: I can have cups, avahi and other optional/non-critical daemons "active" but not actually using any resource, until effectively used by some other process.
These are solved problems. You're creating a bunch of low level OS spaghetti because you don't want to have to write a shell script for your software? That is not a responsible decision-making process, that's moving the mountain to you.
I swear a earlier discussion here on this very site had someone honestly suggest the usage of strace to figure out why systemd failed to boot.
[wget]-depends-[libuuid1]-recommends-[uuid-runtime]-depends-[libsystemd0]
Ph’nglui mglw’nafh Cthulhu R’lyeh wgah’nagl fhtagn
Windows has even more traction, how about replacing all distributions with windows then?
Systemd has been very good for me in Arch and in OpenSUSE for me. I feel like it is a much better tool for my needs.
There are also other issues. Yes, sysvinit doesn't parallelize scripts or do automatic dependencies. If that's all systemd fixed, I'm sure everyone would be for it. But systemd seems to be consuming everything in its path (logging, cron, etc), ignoring the well-proven and time-tested design tenet of "do one thing well".
https://teythoon.cryptobitch.de/posts/on-portability-of-init...
Besides, none of these are release architectures, so why should their limitations restrict what features >99.9% of Debian users have available?
The Technical Committee seems much more like an advisory board and the forum for and arbiter of the tiny number of contentious issues.
They're not involved in, informed of or responsible for the vast majority of technical decisions.
systemd was created by well intentioned people, solving a real issue but being a bit too aggressive and attempting to rewrite everything.
Renaming was one of the options, dropping the patches the other.
One quasi-political issue that has somewhat more pervasive importance is the general relationship between Debian packages and the Ubuntu packages derived from them, which occasionally is a point of friction if the maintainers have different goals. In most cases it isn't a big problem though, afaict. There are reasonable number of cases where it's even the same maintainer.
In March 2006, a group of Debian maintainers started to attack the cdrtools project.
The latter attacks have been based on the fact that cdrtools was licensed under the GPL. As a result, on May 15th 2006 most projects from the cdrtools project bundle have been relicensed under CDDL (giving more freedom to users than the GPL does). At the same time, an important amount of additional code (DVD support code from Jörg Schilling and a Reed Solomon decoder from Heiko Eißfeldt) has been added to the freely published sources.
In summer 2006, the attacks from the group of Debian maintainers escalated and in September 2006, these people created something they call a fork from cdrtools. They soon added a lot of bugs and this way turned the "fork" into a questionable experiment. The last work on this "fork" has been done eight months later on May 6th 2007, then the leader of the attacks stopped his efforts on the fork and instead started to advertize for nerolinux. During the Debian project activity, the source code distributed by Debian was modified in a way that violates GPL and Copyright and makes it impossible to legally distribute this "fork" called "cdrkit". There is no license problem with the original cdrtools.
I hope all is clear now.
""" Ask your Linux distributor to include recent originals instead of broken forks.
Tell them that you like to decide yourself which program you choose. Whether it is the fork or whether it is the original program depends on which package works better.
[...]
The following Linux distributions currently work against the freedom of their users:
Debian, RedHat, Fedora
If you know of other unfree distributions, please report.
The following Linux distributions currently grant their users the freedom to select the better CD/DVD/Blu-Ray writing software:
Slackware, Gentoo, OpenSuSE, Ark Linux
Except that most distros DID distributed it UNALTERED, like Slackware, Gentoo, OpenSuSE, Ark Linux.
> There was no debate; the developer of cdrtools was just an asshole [...]
Abusing anonymity to vilify an open source developer who works to give us the best software?
You're a liar and a coward, and you know it.
Only the ones small enough that they don't worry about getting sued. It's not just Debian developers that think there's a licensing issue that means they can't legally distribute it; the FSF and Red Hat's legal department also agree[1], and I believe even the authors of the CDDL (the GPL-incompatible license he's releasing most of cdrtools under) think that he's wrong.
[1] https://www.redhat.com/archives/fedora-legal-list/2009-July/...
You got it backwards. Precisely only the big commercial distros with mighty legal teams (Debian, RedHat, Fedora) could afford to get away with violating the GPL, and stealing the name of the original project for the fork symlinks. Try to name your toy project something even remotely similar to redhat or debian and you'll be crushed like a bug.
Here I see powerful entities taking advantage of an individual hacker.
""" During the Debian project activity, the source code distributed by Debian was modified in a way that violates GPL and Copyright and makes it impossible to legally distribute this "fork" called "cdrkit". """
""" The GPL preamble (see also Urheberrecht §14 below) disallows modifications in case they are suitable to affect the original author's reputation. As Debian installs symlinks with the original program names and as many people still believe that the symlinks with the original program names are the original software, Debian does not follow the GPL.
GPL §2a requires to keep track of any author and change date inside all changed files. This is not done in the fork.
[...]
GPL §3 requires the complete source to be distributed if there is a binary distribution. The Debian fork tarball does not include everything needed to compile the cdrtools fork (complete source) and Debian does not give a written offer to deliver the missing parts. """
In Debian's case at least, I don't think there's an objection to third-party projects or forks using names derived from the name "Debian", so long as they aren't actually identically the name "Debian". For example, there is a distribution called "Illumian" which is made up of the Illumos base OS and a Debian-derived userspace.
Besides, I don't really see a trademark issue here. The term "cdr" preexists both of the projects, and is owned by neither of them. A person named their software after a fairly generic derivative of this term, "cdrtools". And now they are complaining that someone else named their software a different generic derivative, "cdrkit"? Do they claim that nobody else should be able to use the prefix "cdr" followed by a noun? Given that they did not even invent the prefix "cdr", that seems like quit a stretch. That's like someone who named their backup product "Backup Tool" complaining that a different product is named "Backup Kit". Sorry, but you don't own the word "backup".
In all group of a given size there's bound to be some amount of politics, even if it's desirable to keep it low. What's specific to Debian is that 1) it's big 2) it's fully open. That makes any emotionally loaded discussion noisy and widely heard. One just has to understand, accept and keep cool about this. Sausage taste best when you don't know how they're made for sure, but I still like the Debian sausage anyway ;)
No, it's a thin majority of devs saying, "lets not make a decision of any kind, so please continue fighting these political battles amongst yourselves".
Just wait for Jessie, you'll see. Package dependencies are going to become the next huge political football.
Splits, forks, and resignations sure do happen. However, it doesn't require votes, committees, lobby groups, rants, arguments and flamewars on blogs, bugs and mailing lists, complete with news coverage of the drama. It doesn't need to drag on forever... I think that's the part that makes it very much look like politics.
Any project of more than 2 people has politics.
http://cgit.freedesktop.org/systemd/systemd/commit/?id=036ee...
LINE_MAX is a POSIX thing: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limi...
There's no one putting a silly limit on password length there.
I worked that out in 2 mins flat. Bear in mind I haven't even looked at the systemd source code before.
Edit: you know I've actually read some of that code and it's pretty nice.
There are so many other platforms that this will never be possible on. Don't like something in Windows, tough. Don't like something in OS X, tough. Don't like something in Linux, xBSD, etc? Fork or go home.
I'm excited to see what happens next and if it will be folded back into Debian in the future.
It's sad to see an end to this era - and it's an end that's been brought not by Dr Jackson (who's been part of Debian for decades) but by SystemD abusing the spirit of openness, following the letter of open source but not the spirit of open standards, of allowing a diversity of solutions to blossom and letting users mix and match whatever best suits their needs.
There will be a fork; there are enough people who care about good engineering not to let this lie (unless they all turn to FreeBSD). But it's sad that it's come to this, and it shouldn't have happened this way.
Some people don't have a problem with that, some do. In the end it's not about choosing an init system; indeed, I think a lot of the arguments and opposition to systemd would go away if systemd were interchangeable with any other init. But that's not the case; if your distro of choice has decided to go with systemd, then you're running systemd or you're not booting (yes, there are shims in Debian right now but they exist only for migration purposes).
Highly recommend to read this excellent mail by Russ Allbery on portability and Debian's history:
https://lwn.net/Articles/618322/
Alternative init systems are a very old idea implemented over and over for decades.
The "innovation" of systemd is product tying it deeply to Gnome. Nobody is willing to kick out Gnome, so they can make everyone else do whatever they want. Including, say, making it impossible to run any other init system.
By analogy it would be like product tying emacs into python, such that you can't install or run vi if you have python installed at the upstream level, because the default location for python temp files is now /usr/bin/vi. Well, I guess you could stop shipping python, or cave in and remove vi. This is the "innovation" that is new in systemd. Merely being an advanced init is really old stuff.
If three years from now, everything from Firefox to GNU tar depends on systemd, then your open-source Linux is in the same boat.
[Edit: Just to be clear, I don't expect that to happen. I'm just pointing out why people get upset when systemd encroaches on very large numbers of system components.]
It's very sad to watch this, systemd is too intrusive with the strong support from the OSS Microsoft, that is, the Redhat behind the scene. No other project can be so controversial so fast, it's really bad.
That's what Ian Jackson proposed - that while systemd would be the default, Debian would fully support users using other systems (bugs that only affected SysV users would be considered equally critical). He was voted down, hence his resignation. The systemd folks don't seem to be interested in compromise.
What are the alternatives? You can't force the upstream or the package maintainer to invest the extra work to make the package work without systemd, you're not providing the required work either and you certainly don't want the user to be on the loosing side because you don't like systemd.
Debian has a long and glorious tradition of standing on principle to the user's (at least short-term) detriment. Look at the way they used to ship KDE programs (especially in the days before GPLed Qt), or the way they still package tomcat, or their approach to multimedia codecs.
On top of that, the people who don't want to use it are against the idea of supplanting the core technology they're used to. So you have this one camp that's all "fuck yeah new technology", and another camp that's like "get that shit out of my box."
In a way it's like GNOME vs KDE, but almost at the very heart of the operating system. You just have to pick one and go with it, or you don't really get the benefit of either.
The 'set of interfaces' you mention should (imho) be patches to systemd to allow it to work as not-pid-1, so that you can still take advantage of its contributory applications without having to supplant your init system. That way you could use 'a gtk application in a kde workstation', but with systemd and sysvinit.
Debian will survive. That constitutional document and those processes people like to moan about all the time, are the same document and processes that ensured Debian's success, solidity and continuous development. For every great engineer stepping down, I'm sure Debian will attract new talent who wants to make a difference. For every controversial decision like on systemd, there will be a time when that decision will be either vindicated or corrected. Like the Linux kernel, the Debian project is now too big to die because of a single but controversial technical choice.
Debian may seem too big to die, but they are slowly being commoditized away, because RedHat is known to offer better sales force, better service and support:
And tremendously longer support periods.
Right now I'm helping a non-profit move from squeeze and XCP/XenCenter (which is CentOS), which I initially set up for them, to wheezy. And we're looking rather enviously at the RHEL/CentOS support periods. Even before this systemd debacle, something else was looking likely for when wheezy support ends.
And per the above experiment, it's not something you can depend on, not something you can build your plans around.
When did Debian ever offer support or sales? Debian is not a corporation, it works under a different paradigm. Debian will be the last Linux distribution to die, and it might even survive as a non-Linux OS. As long as there are people who can benefit from a free open-source operating system, and people willing to dedicate their time to make it possible, Debian will live on.
As if Debian were the only free open-source OS... Not even considering only GNU/Linux, where Slackware was first (why not also last?).
> and people willing to dedicate their time
A complete OS will take much more than that, if Debian loses relevance, people will leave. What differentiating advantage to choose Debian over CentOS or Fedora? Debian will have to fight that battle, being or not a corporation is irrelevant.
I hope Debian endures, but you have to understand that systemd standardization is not going to be positive to Debian relevance.
It's the only free open-source OS backed by an explicitly democratic approach, enshrined in its constitution. It's "the GNU System that works, will always be Free, and will give an equal say to any developer" (at least in theory). All the other distributions are owned by a specific group of people (or in the RedHat case, by shareholders) and/or are not Free. That's the Debian differentiator that RedHat will never be able to match, no matter how many "community editions" they sponsor.
> What differentiating advantage to choose Debian over CentOS or Fedora?
Those are both owned by a corporation.
> being or not a corporation is irrelevant
I respectfully disagree there. You just have to look at the evolution of the Linux ecosystem to see how "being or not a corporation" makes a huge difference. History is littered with corpses of Linux vendors. In fact, there is an argument for big Linux projects being naturally incapable of making money as corporations in the long run, a concept that was seriously challenged only by RedHat and Ubuntu at this point.
> you have to understand that systemd standardization is not going to be positive to Debian relevance.
My point is, if that's the case, the project will likely have the necessary strength to reconsider and correct this choice later on. It's not like they can "run out of money" or something like that; they have such a huge mindshare that it would take ages to dissipate, and votes seem to indicate that most developers don't really care about the init system that much. If things come to worst, Jesse will just go down in history as a terrible release (wouldn't be the first...) and the project will move on.
If anything, it's downstream projects that have to worry (i.e. Ubuntu) since they have to differentiate in a competitive market, but they seem to have already adopted systemd, so...
Take a look at Mozilla, they implemented DRM, otherwise they could have lost relevance, they explained.
Now Debian must commit resources just making everything work with every new "innovation" brought by systemd. RedHat will dictate the pace and the terms, Debian will follow, and once the future "systemd + linux OS" integration has been declared standard, they can't correct the decision, they will be stuck with "systemd OS" forever.
I mean, I had switched to gentoo for other reasons, but when the founder steps down over systemd, this means we're seeing a quiet war being waged. And it isn't by the guy who put the Ian in Debian.