A group of developers made good on their threats to fork Debian Linux late last year after the community’s leadership voted to replace sysvinit with systemd, making systemd the default init boot process.
The Debian Technical Committee’s decision spurred several key Debian developers and project maintainers to resign. Some of them formed a new community dedicated to developing a forked Debian Linux distro called “Devuan,” pronounced “DevOne.” The split is largely philosophical; there was contention within the Debian community over the growing control of GNOME project leaders.
While it’s unlikely the Devuan team will reconsider the decision that sparked the forking, Debian project leader Lucas Nussbaum invited Devuan to join the Debian Derivatives Census.
The new group might be willing to work on improving infrastructure software among both communities, he said.
“I would love to see improvements to Debian’s own support for sysvinit (as a non-default option) as a result of their work to maintain and improve support for sysvinit in Devuan,” Nussbaum told LinuxInsider.
The fork was welcome news to many in the Debian community, according to Nussbaum. The Debian community works with many other Debian derivative communities.
More than 300 such projects exist, according to Distrowatch.com. They include 130 that are still active, ranging from niche distros to the very successful and popular Linux Mint and Ubuntu.
They all have very different development models. Debian forks are initiated on a monthly, if not weekly basis, he said.
“The decision on the default init system for Debian is the kind of decision where it is hard to find compromises,” Nussbaum noted.
“In the end, either you change the default or you don’t. Debian decided to change the default init system to systemd. It is true that some people — including Debian developers — are unhappy about that decision, but there are also more people — including Debian developers — who support that decision,” he explained.
Options Built In
The philosophical dispute is clouded in a word battle. The Debian Technical Committee’s decision to officially put its default support on systemd is not really a replacement of sysvinit, according to one viewpoint.
Both Debian 7.0 (Wheezy) and the upcoming Debian 8.0 (Jessie) support Systemd, Upstart and sysvinit, according to Debian developer Sam Hartman. Though not a member of the technical committee, he does frequently join their discussions.
“The Systemd support in Debian 8.0 is significantly enhanced over Debian 7.0. The project as a whole has worked to make it possible to more easily choose an init system to boot Debian. The systemd maintainers have spent a lot of time improving integration with our operating system,” Hartman told LinuxInsider.
A maintainer is someone who maintains packages. A developer is often a maintainer — as is Hartman — who has gone through a formal process and gained the right to vote in the project. Hartman remains actively affiliated with Debian.org.
The status of any of the three init processes beyond Debian 8 is not yet decided. Some of the objectors were unhappy that the Debian leadership was taking future decisions on the init issue on a case-by-case basis, Hartman said. Other people just do not like change or do not want the systemd software used at all.
Debian is not alone in deciding to support systemd. Fedora, Red Hat, Arch and Suse all have moved to systemd, and Ubuntu will follow. That represents a vast number of Linux users, noted Hartman.
“For a long time, we have been trying to improve the technology of booting Debian systems and improve the init system we use. No one on the technical committee favored keeping sysvinit as the default as their primary position,” he pointed out. “Eventually, after a long process, the committee decided that systemd would be the default for Debian 8.0.”
Sysvinit is flawed, or less effective, for a few key reasons: Sysvinit does not automatically restart services that fail; it does not provide facilities for security isolation of services; and it does not always start services in the right order.
“The sysvinit maintainers volunteered their happiness that sysvinit was no longer the default. They cited sysvinit’s challenges with boot ordering as a good reason to move away from sysvinit,” Hartman said.
Systemd Not Perfect
Some people within the Debian community are unhappy with the design approach to systemd, admitted Hartman. That view has been longstanding.
The traditional practice in Unix is to group together a series of small programs to perform powerful tasks. The advantage to that is allowing tremendous flexibility to people who understand how computers work, and to system administrators and developers.
The disadvantage, according to Hartman, is that it actually makes certain types of things harder to do — like having certain elements run very fast or managing complex relationships between systems.
Systemd is built on a different philosophy. It groups all the things power users need to do into one component so they can get their job done. People are concerned that doing this removes the flexibility in how they can evolve the system.
“I think that even some of the people who agree that systemd is a great step forward today are concerned by that,” said Hartman.
Cause and Effect
Some half dozen long-time Debian developers and maintainers resigned in the wake of the Debian Technical Committee’s decision to support systemd. Among those quitting due to the systemd dispute is former Debian project leader Ian Jackson.
Some of those who resigned have moved their support to the Debvian fork project. Others resigned from their key leadership roles within Debian.org but have remained within the Debian organization.
In the case of Debian developer Colin Watson, the ongoing systemd versus sysvinit debates were not so much the breaking point as was burnout. He resigned from the technical committee after the vote, but he remains a developer within the organization and is not part of the Debian fork movement.
“I’m perfectly happy to continue my involvement as a Debian developer, and my involvement in one derived distribution (Ubuntu) is already more than enough to keep track of,” Watson told LinuxInsider.
He resigned from the technical committee simply because it became clear that doing a good job on it would require more time and energy than he could continue to give.
It is hard to see the direction Devuan will take, given that the project is still in its early days.
The new community could create a shallow derivative, which would involve using most packages directly from Debian but providing a small set of modified packages to change what they want to see changed.
Devuan developers could fork the entire Debian archive, have their own release cycles, and synchronize on a regular basis as Ubuntu is doing. Another option is to try replacing Debian entirely and become a new gateway between upstream projects and users of all packages.
“That, of course, requires a lot more manpower and infrastructure. This is really their decision,” said Nussbaum.
Either way, he thinks that it is important to let Devuan organize and decide what to do — then actually do it.
“Even if Debian facilitates this, creating new Debian-based distributions is not a trivial business, and only time will tell us if they are up to the task,” said Nussbaum.
The Devuan View
So far, those comprising the driving force for Devuan.org are identified only as the “Veteran Unix Admin collective.” The names of those involved in starting up the forked project have not been released.
“I haven’t been able to determine how many people are involved in Devuan. They have a GitHub repository. Based on the number of comments posted there, it appears to be a small number of people,” said Hartman.
The initial postings on the new Devuan website map out the startup plans going on behind the scenes. Those activities include setting up the start of a core infrastructure to host a website, mailing lists, and a package repository. The same information has been posted on the debianfork.org website.
Devuan’s website emphasizes the rallying point of its supporters’ side in the dispute. Among its goals is becoming a base distribution whose mission is to protect the freedom of its community of users and developers. Another goal is to enable diversity, interoperability, and backward-compatibility for existing Debian users and downstream distributions willing to preserve init freedom.
The yet unnamed Devuan developers appear to be looking at this project as a fresh new start. They have formed a community of interested people who reject decision-making within a hierarchical, bureaucratic structure, except in actual cases of emergency.