1. 22
    1. 20

      Open source exists to support forks. Don’t petition, don’t whine, just fork the project and do your best to create the thing that you think should exist in the world.

      1. 7

        It’s better for everyone if participants make an attempt to engage in discussion before forking. I know everyone hates politics but it does have a purpose.

        1. 1

          Discussion with whom? Certainly one should attempt to resolve the issue with the developer, company, or sponsor that is driving you to fork a project prior to actually declaring a fork. I do not agree that you need to try to incite the userbase to support your ideals prior to forking with a petition or a threat to fork.

      2. 3

        Dialogue is good, forking a major project is a ton of work and to be avoided if possible. Threats are normal over serious issues. During the exciting times leading up to xorg, Theo de Raadt famously warned:

        This is final; if that license stands, there will be forking.

        1. 1

          The OpenBSD team are not afraid of forking - or writing replacements.

          That license didn’t work out well for XFree86 :~)

    2. 9

      i dislike the threatening nature of the post. i’d be all for a friendly fork of debian, in the spirit of “hey, there are two ways to do this; let’s explore both”, but this seems more like a “we’re going to fork, and you really don’t want that to happen” sort of statement.

      1. 6

        Forking is unpleasant business, whether you like it or not. Sometimes it’s necessary, but it’s always regrettable.

      2. 3

        The thing is, those two ways of doing it could coexist in debian - but only if debian doesn’t standardize on systemd. Once you adopt systemd it’s infectious and your system becomes dependent on it.

      3. 1

        Debian is a major core of the Linux community. A fork with a lot of support could really fuck with things for the next decade.

        1. 8

          A fork with a lot of support could really fuck with things for the next decade.

          Ubuntu is a 10 year old Debian fork with a lot of support. The Debian community survived.

          1. 1

            Ubuntu wasn’t really a “hostile” fork though, was it? I was under the impression that they (Ubuntu) actually try to work with Debian, contribute back up, etc. I wonder how things would have gone if Ubuntu had been a “hostile” fork.

            1. 4

              that’s my point; it’s possible to do a nonhostile fork of debian, if the idea is to give people the option not to use systemd. the point behind this fork seems to be to be hostile from day one; its initial manifestation is as a threat rather than an exploration of the technical challenges and possible roadmap.

            2. 1

              The hostile/friendly fork aspect is just posturing. The end result is the same and contributions are enforced by the licenses (see how ffmpeg incorporated most of the changes from the “hostile” libav fork).

    3. 4

      Whew, I can tell it’s sysadmins and not designers.

      I’m all-for the “freedom of choice” option because it’s what Debian has already been about on many levels – though it gets gunked up with bureaucracy and process, it still tends to find a way. I don’t much like systemd myself, and I wouldn’t like having to weed it out to install sysvinit on each new box, but I think I’d hold off on making a loud page about forking Debian (or you know, actually fork it instead of talk about it) until after everything internal to Debian is determined.

    4. 4

      If concerned parties are so very concerned, and are ready to fork, I can suggest one thing, that worked very well in the past for many derivatives: contribute your changes back. The vast majority of Debian maintainers are happy to accept patches (unless upstream disagrees, in which case it is upstream you want to fork, not Debian). Get the work done to support alternative init systems, and you won’t have to fork, at all.

      The problem right now is not that Debian is unwilling to support alternative init systems: the problem is there is not enough manpower and willingness to support them. So go ahead, and make it happen! You don’t need to fork for that.

      But, if a fork is what you want, go ahead. In the long run, it won’t really matter.

      Also, you are misunderstanding Ian’s proposal. The default init system will be systemd, we’re not going back to sysvinit. The proposal is only about alternatives, and only for one release.

      Furthermore: if you do not have the time and resources to become Debian Developers, how do you plan to sustain a fork? Trust me, becoming a DD and voting is much less work, than maintaining a distribution.

    5. 4

      Why don’t you do that yourselves?

      We are excluded from voting on the issue: only few of us have the time and patience to interact with Debian on a voluntary basis.

      How are we supposed to interpret this? Are they just asking other people to do the work to solve a problem they’re complaining about? Why are they making such a fuss? They seem to be taking the “central steering committee” role without actually doing any of the work from where I stand.

      1. 3

        It is a strange bit of reasoning that decides since they don’t have the time and patience to engage with an open source project, the only option is to start a new open source project.

    6. [Comment removed by author]

      1. 6

        Distros that don’t use systemd are few and far between these days. And not everyone wants to use Gentoo, before you mention it.

        1. 8

          Some people are apparently switching to freebsd too. At least there are good alternative OSes these days.

          1. 1

            FreeBSD 10 on EC2 for all our production clusters at work has been great =)

          2. 1

            I have, and I love it. The FreeBSD repos are more up to date than most Linux repos these days. =D

    7. 2

      I sent the following to the folks behind debianfork:

      … something to consider: some long-time (since 1995, in my case!) Linux users have already voted with their feet. The Debian team shouldn’t necessarily take silence as consent, as the most deeply disaffected users may already have left."

      I’ve seen variations on this mistake in many fields, and I wonder if the Debian project may be experiencing it now. (In my case, ‘voted with their feet’ means ‘abandoned Linux Mint for FreeBSD’).

    8. 2

      Can anyone give some background on what the issues are with systemd vs. sysvinit? Aside from the fact that it “betrays the UNIX philosophy”, this article is fairly light on details on what I would think is an important rhetorical point.

      1. 3

        systemd (SystemD if you want to piss off proponents) init specifically offers a bunch of benefits over sysv init, most of which revolve around not writing bourne shell scripts to launch system daemons and providing a framework for managing said daemons (instead of being handled ad hoc with more shell scripts and management functionality built into the daemon itself). This is pretty strictly beneficial.

        The biggest complaints people have are that systemd has started implementing things way beyond init, and tightly coupling them together into a practically monolithic blob of system management code. Many of the non-init components enforce extremely questionable design decisions, and they’re practically impossible to replace because the systemd developers are actively hostile to independent development.