Ian Jackson Resigns from Debian Technical Committee(lists.debian.org)

127 pointsby onestone12 anni fa199 comments

lists.debian.org

Ian Jackson Resigns from Debian Technical Committee

https://lists.debian.org/debian-ctte/2014/11/msg00091.html

10 comments

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?

[0] https://news.ycombinator.com/item?id=8617874

microtonal12 anni fa

You missed some:

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.

zaphar12 anni fa

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.

Personally I don't really care much either way.

microtonal12 anni fa

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.

zaphar12 anni fa

    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.

Xylakant12 anni fa

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.

zaphar12 anni fa

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.

Why isn't it considered a viable alternative?

lomnakkus12 anni fa

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.)

the_why_of_y12 anni fa

Here are some specific examples:

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

Xylakant12 anni fa

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.

makomk12 anni fa

> 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.

kijin12 anni fa

> 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.

e762012 anni fa

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.

Xylakant12 anni fa

no, the alternatives are

(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.

exarch12 anni fa

>better than sysvinit

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.

Xylakant12 anni fa

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.

exarch12 anni fa

>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.

Xylakant12 anni fa

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.

e762012 anni fa

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.

Xylakant12 anni fa

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.

e762012 anni fa

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".

Xylakant12 anni fa

> 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).

the_why_of_y12 anni fa

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?

e762012 anni fa

I've been hearing this for decades: If Linux and *BSD are better than Windows, how come exactly zero people have made the switch?

Except they've been adopted, systemd has been mandatory only in some bigger more commercial distros.

microtonal12 anni fa

Socket activation:

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.

exarch12 anni fa

<i>Socket activation</i>

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.

icebraining12 anni fa

It's totally cool if some other daemon lies about whether or not my service is actually listening

You're a little late; inetd(1) first appeared in 4.3BSD, c. 1986.

exarch12 anni fa

Oh shit, let me go recompile my chargen and telnet servers then.

We stopped using inetd for reasons. Modern services don't work this way, nor should they.

icebraining12 anni fa

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.

exarch12 anni fa

Safe, but seems like it's solving a problem that doesn't really exist, or at least exists as a mosquito not warranting a bazooka swat.

e762012 anni fa

Your analogies are great, transmiting a clear picture of systemd, like this: http://upload.wikimedia.org/wikipedia/commons/a/a6/Professor...

teddyh12 anni fa

1. The purpose of systemd is not speed; it is simply a happy side-effect of its design.

2. Socket activation do 𝐧𝐨𝐭 buffer into /dev/null; that is simply FUD.

e762012 anni fa

>> that is simply FUD

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.

exarch12 anni fa

They don't buffer into /dev/null... until you fill the buffer.

And the purpose of systemd, as near as I can tell, appears to be making my system into a Windows box, complete with binlogs.

teddyh12 anni fa

No, when the buffer is full, the write() call blocks. Otherwise no UNIX pipes could ever reliably transport data.

exarch12 anni fa

True, I was wrong here.

[deleted]12 anni fa

exarch12 anni fa

Why make apples and oranges comparisons to the kernel? It isn't that hard to replace sysvinit. Why should sysvinit's replacement regress in this area?

TheLoneWolfling12 anni fa

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...)

thoughtpolice12 anni fa

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?

digi_owl12 anni fa

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).

Shish2k12 anni fa

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)

jjoonathan12 anni fa

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.

Shish2k12 anni fa

> 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)

digi_owl12 anni fa

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.

VLM12 anni fa

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.

Rolpa12 anni fa

It all comes down to the fact that talk is cheap while concrete action is expensive.

jmnicolas12 anni fa

"rape you to death with a flaming donkey"

Dude ...

jmnicolas12 anni fa

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 :-)

I don't hate you though.

lmm12 anni fa

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.

digi_owl12 anni fa

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...

the_why_of_y12 anni fa

It's not a problem to have systemd installed; on Debian it doesn't actually run as init unless you install the systemd-sysv package.

npsimons12 anni fa

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".

the_why_of_y12 anni fa

The reason why sysvinit runs on FreeBSD and HURD kernels is that those kernels have implemented the Linux procfs file system.

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?

makomk12 anni fa

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.

porker12 anni fa

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.

rasz_pl12 anni fa

>Since systemd seems to have the most traction

Windows has even more traction, how about replacing all distributions with windows then?

baldfat12 anni fa

How does another OS have anything to do with the need of replacing init system?

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.

exarch12 anni fa

>systemd and Upstart are both a large improvement over the System V init scripts.

Userland utils like wget depending on a specific init package is a large improvement over sysvinit? Nope.

pantalaimon12 anni fa

How is wget depending on systemd?

Macha12 anni fa

So I had to look this up.

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...)

1_player12 anni fa

The systemd is a make dependency only. Unless you plan on compiling it yourself, you don't need systemd to run it.

    ~ $ y -Qi libutil-linux | grep Depends
    Depends On     : None

EDIT: conversely, these are the packages depending on systemd:

    ~ $ y -Qi systemd | grep Required | fmt
    Required By    : accountsservice  chromium  colord  crda  cups
    device-mapper  gnome-session  lib32-systemd  libgdm  libgusb  libpulse
    libusb  libvirt  libwacom  lvm2  media-player-info  mesa  mkinitcpio
    netctl  polkit  procps-ng  qt5-base  qtwebkit  rtkit  spotify  subversion
    systemd-sysvcompat  udisks2  upower  xf86-input-evdev  xf86-video-ati
    xf86-video-modesetting

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.

exarch12 anni fa

>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.

digi_owl12 anni fa

And making it harder for someone to come afterwards and untangle the mess.

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.

the_why_of_y12 anni fa

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".

cesarb12 anni fa

That's probably because util-linux has a command, logger, which can optionally log to systemd's journal. Take a look at http://man7.org/linux/man-pages/man1/logger.1.html.

cozzyd12 anni fa

Probably accidentally, due to a poorly abstracted dependency chain.

octoid12 anni fa

Debian:

[wget]-depends-[libuuid1]-recommends-[uuid-runtime]-depends-[libsystemd0]

Ph’nglui mglw’nafh Cthulhu R’lyeh wgah’nagl fhtagn

walterbell12 anni fa

Proposal: https://lwn.net/Articles/616571/

Vote: https://lists.debian.org/debian-devel/2014/11/msg00891.html

pilif12 anni fa

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)

yaantc12 anni fa

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.

deong12 anni fa

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.

walterbell12 anni fa

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.

anonbanker12 anni fa

The sole voice of truth in the entire thread, down voted for telling an uncomfortable bit of it.

anonbanker12 anni fa

Look how they buried me for even mentioning it.

digi_owl12 anni fa

A bunch of devs scratching itches, Just so happened that their scratching sticks where tired together and covered in super glue.

the_why_of_y12 anni fa

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.

walterbell12 anni fa

Add astro-turfing to the list of thesis topics, e.g. use the HN API to perform clique analysis of the many systemd threads on HN.

deong12 anni fa

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.

_delirium12 anni fa

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.

VLM12 anni fa

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"

digi_owl12 anni fa

I keep seeing the odd one over at G+.

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".

teddyh12 anni fa

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.

jude-12 anni fa

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.

teddyh12 anni fa

Actually, journald exists for a number of reasons, listed here:

https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBA...

pjc5012 anni fa

Ian Jackson has been involved with Debian for 20 years and is not one to back down easily in an argument or quit over trivia.

ClashTheBunny12 anni fa

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.

lmm12 anni fa

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.

pantalaimon12 anni fa

how many init systems could you chose from before systemd?

morganvachon12 anni fa

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).

fluidcruft12 anni fa

You seem to be confusing Debian with NetBSD...

morganvachon12 anni fa

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.

[deleted]12 anni fa

the_why_of_y12 anni fa

You have never been able to exchange glibc on a Debian system, or replace dpkg with rpm, or (in recent releases) run without udev.

Highly recommend to read this excellent mail by Russ Allbery on portability and Debian's history:

https://lwn.net/Articles/618322/

VLM12 anni fa

I played around with upstart, it worked fine.

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.

digi_owl12 anni fa

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.

e762012 anni fa

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.

makomk12 anni fa

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.

digi_owl12 anni fa

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.

lmm12 anni fa

On Debian/kFreeBSD? 1, but that's 1 more than after systemd.

mateuszf12 anni fa

It still is about choice. If you want you can fork Debian any time.

lmm12 anni fa

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.

mateuszf12 anni fa

And it's the exact reason why unification through systemd makes sense.

lmm12 anni fa

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.

mercurial12 anni fa

I don't know about the rest, but AFAIK, ConsoleKit wasn't maintained anymore.

the_why_of_y12 anni fa

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.

digi_owl12 anni fa

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?

mateuszf12 anni fa

There were so many technical proponents of systemd among distributions that it's now used by most of distros.

e762012 anni fa

This is not true, unless you happen to have too many dollars to spare. Also, Windows can also be forked, by distributing patches instead of binaries.

eots12 anni fa

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?

stinos12 anni fa

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:)

deong12 anni fa

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.]

CJefferson12 anni fa

This is the 3rd person to resign in 10 days (Colin Watson, Russ Allbery and now Ian Jackson).

plus12 anni fa

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.

danohuiginn12 anni fa

That's 3 of the 8-member Technical Committee, which is the group that's ultimately responsible for all technical decisions in Debian.

_delirium12 anni fa

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.

morsch12 anni fa

What does that really mean? Debian is a community project, not a hierarchical organisation with a managerial chain of command.

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.

qznc12 anni fa

So systemd is a plot by RedHat to kill Debian and make RedHat/CentOS/Fedora the number one Linux distro? :)

dijit12 anni fa

it would kill redhat too then.

systemd was created by well intentioned people, solving a real issue but being a bit too aggressive and attempting to rewrite everything.

makomk12 anni fa

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.

sigzero12 anni fa

hand waving sure.

RexRollman12 anni fa

and Joey Hess.

onestone12 anni fa

And Tollef Fog Heen (partial resignation), but he and Joey were not Technical Committee members.

cgh12 anni fa

According to his blog, he didn't resign because of systemd. In fact, he seems to quite like it: https://joeyh.name/blog/entry/a_programmable_alarm_clock_usi...

badgersandjam12 anni fa

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.

yaantc12 anni fa

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 ;)

exarch12 anni fa

>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.

_delirium12 anni fa

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.

clarry12 anni fa

> 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.

danielweber12 anni fa

"Politics" is how humans interact with each other. It's often ugly because humans don't have nice interfaces.

Any project of more than 2 people has politics.

bitmatrix12 anni fa

>I don't have a problem with systemd from a technical perspective

http://cgit.freedesktop.org/systemd/systemd/commit/?id=036ee...

badgersandjam12 anni fa

Ah c'mon at least try a bit harder. '''password''' is defined as:

   char password[LINE_MAX];

So that's preventing a buffer overflow and is perfectly fine.

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.

Lai0chee12 anni fa

IMHO Debian's problem is not systemd the problem are the crazy politics. :-(

_delirium12 anni fa

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.

e762012 anni fa

cough FFmpeg cough

_delirium12 anni fa

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.

e762012 anni fa

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.

_delirium12 anni fa

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).

makomk12 anni fa

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.

e762012 anni fa

(1)

e762012 anni fa

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:

Slackware, Gentoo, OpenSuSE, Ark Linux

Lai0chee12 anni fa

I gave up on Debian after they've renamed Firefox to Iceweasel.

Xylakant12 anni fa

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.

Lai0chee12 anni fa

How do other distros solve this "issue"?

sethrin12 anni fa

Please see this for more background: http://en.wikipedia.org/wiki/Mozilla_Corporation_software_re...

Xylakant12 anni fa

AFAIK, they do not include unofficial patches.

_delirium12 anni fa

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.

Xylakant12 anni fa

I'm sorry about the miswording - I meant "unoffical" as in "not officially approved". Thanks for the correction.

dec0dedab0de12 anni fa

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.

Lai0chee12 anni fa

Yessss, just down vote me for sharing my personal opinion.

stefantalpalaru12 anni fa

Try Gentoo if you're not happy with FreeBSD.

toyg12 anni fa

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.

e762012 anni fa

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

toyg12 anni fa

> 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.

e762012 anni fa

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.

toyg12 anni fa

> As if Debian were the only free open-source OS

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...

e762012 anni fa

> "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.

toyg12 anni fa

That's as much a guess as mine. We'll see in time.

hga12 anni fa

"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.

e762012 anni fa

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! :)

hga12 anni fa

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.

peterwwillis12 anni fa

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.

lmm12 anni fa

> 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.

Xylakant12 anni fa

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."

teddyh12 anni fa

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.

wtbob12 anni fa

Neither, of course, is saying, 'we will permit packages to fail to work with any init system other than systemd.'

Xylakant12 anni fa

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.

lmm12 anni fa

> 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.

teddyh12 anni fa

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.

coldpie12 anni fa

I can't imagine how much effort that would take to maintain. Arch Linux tried it and dropped the idea after a few short months.

mkesper12 anni fa

This would have tied Debian to SysV forever, sucking up manpower needed for more fruitful work.

stinos12 anni fa

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.

peterwwillis12 anni fa

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.

kolanos12 anni fa

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.

anonbanker12 anni fa

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.

teddyh12 anni fa

Ian Jackson had nothing to do with the founding of Debian, Ian Murdock created (and named) Debian.

pmoriarty12 anni fa

systemd is a cancer. I am glad some are taking a firm stand against forcing it down the throats of the Linux community.

walterbell12 anni fa

At least the vote is on the record. Time will tell whether this is another Elop moment.

ausjke12 anni fa

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.

e762012 anni fa

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.