This message was sent to the DNG mailing list on November, 27, 2014 to announce the Debian fork. It is kept here for historical interest. A December, 22, 2014 update is also of interest.
Since then we have refined our plans, e.g.: Github has been replaced by our own instance of Gitlab. However, for the most part, the core of the vision remains the same: a minimal, stable system which honors Debian history and embraces innovation while maintaining backwards compatibility and interoperability.
## [Dng] [debianfork] Don't panic and keep forking Debian™! Dear Init-Freedom lovers, The Veteran Unix Admin collective salutes you. As many of you might know already, the Init GR Debian vote promoted by Ian Jackson wasn't useful to protect Debian's legacy and its users from the systemd avalanche. This situation prospects a lock in systemd dependencies which is de-facto threatening freedom of development and has serious consequences for Debian, its upstream and its downstream. The CTTE managed to swap a dependency and gain us time over a subtle install of systemd over sysvinit, but even this process was exhausting and full of drama. Ultimately, a week ago, [Ian Jackson resigned]. : https://lists.debian.org/debian-ctte/2014/11/msg00091.html The problem is obviously not just technical: the VUAs idea of calling for a "fork" mostly refers to the lack of common ground between diverging perceptions of the Debian project, its governance and its mission. Diverse mediation attempts have failed. Today we can all peacefully agree on one thing: further negotiations related to systemd are costing way too much energy for anyone concerned about the cause of Init Freedom. We believe this situation is also the result of a longer process leading to the take-over of Debian by the GNOME project agenda. Considering how far this has propagated today and the importance of Debian as a universal OS and base system in the distribution panorama, what is at stake is the future of GNU/Linux in a scenario of complete homogeneization and lock-in of all base distributions. Therefore, looking at how the situation stands today: we need to fork. In appendix to this mail is the message of Roger Leigh, a Debian Developer and maintainer of many important parts in Debian. We have his endorsement and that of other 2 anonymous DDs, plus many letters from concerned professionals upstream and downstream of Debian. We welcome all Debian Developers intrigued by our plans. The Dyne.org non-profit foundation has accepted to provide us support and the administrative framework we need to get up to speed. If we all struggle for elegance it will be a light and lean effort, think of channeling the bad energies into creating something new and beautiful in its simplicity... ### So we will fork! First of all, our project is called "Devuan". Our home is on https://devuan.org. Please spread the word. We need volunteers. The Debianfork website and IRC channel stay as the first campfire for this adventure, but we will be operating under the name "Devuan" from now on and we invite everyone to use this name when referring to our project. Now we need all your support and attention in order to shape this as a collective and welcoming process for all the people inside and outside Debian that are willing to contribute to it. Our fork will grow gradually and step by step, tracing a path that is different from the one that systemd and the GNOME projects are trying to impose on everyone. There is space for everyone who wants to participate, a good channel to start from is #devuan on freenode, the GitHub issues are the TODO and main topic for that channel, while the well participated #debianfork stays open for the more general discussion. ### So what's the plan? First mid-term goal is to produce a reliable and minimalist base distribution that stays away from the homogenization and lock-in promoted by systemd. This distribution should be ready about the time Debian Jessie is ready and will constitute a seamless alternative to its dist-upgrade. As of today, the only ones resisting are the Slackware and Gentoo distributions, but we need to provide a solid ground also for apt-get based distributions. All project on the downstream side of Debian that are concerned by the systemd avalanche are welcome to keep an eye on our initiative and evaluate it as an alternative base. We will work carefully to make it a viable possibility and our primary goal here will be a clean removal of systemd and its dependencies, rebuilding and patching packages when necessary. There is already an interesting proof of concept for this plan: the website http://without-systemd.org/debian-jessie/ (by Obri) explains the pinning method and provides a 64bit installer of Debian testing free from systemd. We are running a systemd-free pin on our new Devuan infrastructure already, well ready to eat our own dogfood of course. If you have greneric experiments to contribute, experiences or ideas and documention on this and other approaches, feel free to use the wiki on http://without-systemd.org/wiki/index.php/Main_Page. We started setting up the first bits of a core infrastructure to host a website, mailinglists and a dak based package repository (to be mirrored, soon details!). We are also uploading materials on the https://github.com/devuan group which we plan to use as a development platform, at least in this initial phase. For those willing to help immediately, we still need to setup a BTS (https://www.debian.org/Bugs/) which will allow us to inherit a lot of the useful tools Debian has developed. At last we plan to have continuous integration of packages from GitHub to a Jenkins builder (http://jenkins-debian-glue.org/) and then to our package repositories. Feel free to experiment and let us know Continuous Integration Pipeline: Github --> Jenkins --> packages.devuan.org .oO mirrors Once this is all set, we will be ready to welcome package maintainers. Besides the BTS we will use GitHub issues on https://github.com/devuan/devuan-baseconf/issues for task coordination. The first package of Devuan is indeed `devuan-baseconf` which basically consists of a Debian installer with preseed of sysvinit-core and a couple of devuan packages containing devuan keyring, devuan repository list files and pinning out of systemd-sysv. Once installed and updated this package will avoid the requirement of systemd as PID 1 in any case and will prefer use of systemd-shim when strictly needed. ### More about the vision This is just a start, as bold as it sounds to call it fork, at a process that will unfold in time and involve more people, first to import and change Debian packages and later on to maintain them under a separate course. To help with this adventure and its growth, we ask you all to get involved, but also to donate money so that we can cover the costs of setting the new infrastructure in place. Devuan aims to be a base distribution whose mission is to put the freedom of users: to be intended as developers, sysadmins and in general tech-savvy people, as the majority of Debian users are. Among the priorities are: enable diversity, interoperability and backward compatibility for the existing Debian downstream willing to preserve Init Freedom and avoid the opaque and homogenizing systemd avalanche. Devuan will derive its own installer and package repositories from Debian, modifying them where necessary, with the first goal of removing systemd, still inheriting the Debian development workflow and continuing it on a different path: free from bloat as a minimalist base distro should be. Users will be able to switch from Debian 7 to Devuan smoothly, as if they would dist-upgrade to Jessie. Devuan will make an effort to rebuild an infrastructure similar to Debian, but will also take the opportunity to innovate some of its practices. Devuan developers look at this project as a fresh new start for a community of interested people and do not intend to enforce the vexation of hierarchy and bureaucracy that is often opposing innovation in Debian. We are well conscious this is possible mostly because of starting small again and we will do our best to not repeat the same mistakes. The Devuan distribution will make an effort to improve its relationship with both upstream and downstream and, particularly in its gestational phase, will do its best to accomodate needs of those downstream distributions willing to adopt it as base. We look forward to statements of interest from such distributions, as well as involvement in this planning phase. Devuan will do its best to stay minimal and abide to the UNIX philosophy of "doing one thing and doing it well". It will foster diversity and freedom of choice among all its components and will perceive itself not as an end product, but as a a process, a starting point for developers, a viable base for sysadmins and a stable tool for people who have enough experience with computers. Devuan will never compromise for more efficiency at the cost of the freedom of its users, rather than leave that and the responsibility for a secure setup to downstream developers. ### If you need Devuan, then join us and support us now! Donations: https://devuan.org/donate.html Designers and creatives: please contribute logos! we don't have one yet. Wiki: http://without-systemd.org/wiki GitHub: https://github.com/Devuan Press and contacts: email@example.com General discussion (1st mailinglist): https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng IRC chat channels on freenode: \#debianfork (generic discussion) \#devuan (focus on development) - -- We conclude quoting a letter by Roger Leigh Hi, I'm a Debian developer, currently quite disillusioned with what's been going on with Debian over the last two years. I'd certainly be interested in getting involved with a fork. If systemd had just been an interchangeable init system it wouldn't be so problematic. It's the scope creep and mess of poorly-defined interdependencies that are truly shocking. Take logind, for example. When looking at how to implement XDG_RUNTIME_DIR for non-systemd inits, I couldn't find any actual specification for how to do this. That's because there isn't one, just some loosely-worded descriptions; it only exists in the systemd implementation. And the semantics of it are very poor indeed; it hasn't been developed with safety, security or flexibility in mind. We'll come to regret adopting this since the poor design decisions are likely to become entrenched. And more recently, there have been several reports of unbootable systems. That's unconscionable, and a serious break with Debian's traditionally solid support for backward compatibility. Here, existing supported systems have had that support dropped on the floor. With sysvinit great effort was taken never to break existing configurations, and that appears to have been lost. Introducing dependency-based boot took over two stable cycles; optional in one, default in the next, mandatory after that. That could have been reduced certainly, but the point is that time was taken to ensure its correctness and robustness (and in the beginning, it did need work, so the wait was worthwhile). This has not occurred with systemd, which has been made the default yet is still not ready for production use. Debian is developed by hundreds of active developers and used by many times more people. People rely on Debian for their jobs and businesses, their research and their hobbies. It's not a playground for such radical experimentation. systemd support was forced in rapidly and didn't just cause breakage, it caused breakage with our own past, breaking the reliable upgrades which Debian has been renowned for. Personally, I'd like to see a much higher regard for stability and backward compatibility, rather than just ripping out the old in place of the new without any regard for its true value. It might not be bleeding edge, but we already have Fedora for people who value this over a solid and dependable system. It's possible to be up-to-date without being a Fedora; Debian unstable historically made a good job of this. Kind regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800