Debianfork will publish the Debian branch without SYSTEMD.

The Debian 8 Jessie Init system uses SYSTEMD by default, a choice that has caused a lot of controversy in the community, leading to the resignation of several members of the technical Committee. Now, veteran Unix Administrator announces the creation of a new Debian branch that does not use SYTEMD. The group of Unix-philosophical advocates asked for donations to support their new mission.

The following content is from debianfork.org:

Who are we?!

We are veteran UNIX administrators (veteran Unix Admins), and we are very concerned about the differences between Debian Gnu/linux on SYSTEMD and the decision to Branch (fork) the Debian project.

Why are we doing this?

Some of us are upstream developers, some of whom are professional system administrators: We do all kinds of dealings with Debian every day.

We do not want to be forced to use SYSTEMD to replace the traditional UNIX sysvinit initialization system, because SYSTEMD deviates from the Unix philosophy.

Instead of destroying the principle of "doing one thing, doing it well", we consider adopting a framework that is close to Sysvinit, with dozens of tightly coupled binary files and opaque logs.

Is there a better solution than creating a branch?

Unfortunately, not at the moment!

In the next generation of the Debian v.8 "Jessie" release, the default initialization system will be systemd, which will cooked a bunch of tightly entangled things to come.

We need to isolate these dependencies, remove them from all the affected packages, and provide the appropriate alternatives. The stability of the branch we are trying to create is the primary priority to consider at this stage.

Why do you think it's going to be this step?

Today's Debian project leaders are influenced by too many GNOME developers and consider too many desktop requirements in the project, while Debian users are mostly technology-savvy system administrators.

And, today, Debian is moving away from its original vision and the cornerstone of open source software: Customer first. What the hell is going on here? So-called "do-ocracy" developers and package maintainers are imposing their choices on users.

Can you tell me something about your opinion of SYSTEMD?

To apply Eric S. Raymond's view on this issue, we think that systemd can easily change and become bloated and eventually turn into a nasty tangle of fur balls.

We want to be able to control the startup of the system with a shell script that can be read, because readability gives us the ability to control and gain more insight. We believe that centralized control of services, sockets, devices, mounts and so on in a daemon is a slap in the face of the traditional UNIX philosophy.

Some people who support SYSTEMD's quick response to this can be seen on forkfedora.org (which is closed and requires FQ to see the archive). This page highlights the fundamental difference between the two: Systemd may be simple for configuring INIT, but it adds to the opacity of the INIT process. It is clear in systemd that you can adjust by fewer variables, and that a program that is far beyond the sysvinit size hides most of the details in a huge binary program.

Ls-lh/sbin/init  Sysvinit:-rwxr-xr-x 1 root root 36992 Jul  2013/sbin/init  systemd:-rwxr-xr-x 1 root Roo T 1317632 Sep  1 14:41/sbin/init# You may think I'm not strong enough, but you're too fat!

It can be said that SYSTEMD's security model relies more on developers and package maintainers than on system administrators. As a Debian user, we just hope not to be forced to do so, to see Ctte's vote on this issue will know, we believe that this will be more and more to hear the user request: Let go of the Init! Don't be entangled with systemd and its piles of bits and pieces.

How long can you hold on?

It is not always sheep that is longer than the beard, rest assured, furry!

Summarize the plan?

"Let go of that Init" (init Freedom), this is our commitment, we will build a branch of the Debian project, create a new basic distribution.

It takes some time and we will step by step.

First, we will work with the Debian 8 "Jessie" release to provide a complete solution for the current Debian user's smooth upgrade.

If you also need this, please help us: donate or participate in.

We need to talk.

Of course, you can write an email to [email protected] .

We also have some people gathered on IRC, freenode channel number is #debianfork, welcome to join.

You can subscribe to a mailing list. If you like, post your opinion, whatever it is.

Is it just you guys?

No, a lot of users have a problem with systemd.

There is an article that is a good introduction to this question: Systemd:linux apocalyptic omen.

There is a boycott SYSTEMD website that has some relevant information. There is a "Systemd branch" called USELESSD, some nice places and lots of laughs (lulz).

Others have proposed a retreat strategy when the world Systemd.

The SYSTEMD reception chapter in Wikipedia also has some criticisms of it.

Thank you for doing this, how can I help you?

A small caucus of veteran UNIX administrators (veteran Unix Admins) is actively building the relevant framework for the branch and some infrastructure for development.

Donations at this time help us determine how much we can invest in our infrastructure and what people expect from us.

If you can donate, then come on.

As we do now, we will be here to update the progress of our project.

What do people think about what you do?

Here are some of the emails we received (please refer to the original link) and we will publish this information anonymously unless you have stated otherwise.

We will keep your e-mail address confidential and will inform you of our next progress.

• Related articles recommended:
• Debian launches SYSTEMD discussion again
• Ubuntu 14.10 will use the update Linux kernel 3.16.4
• GE Open Predix, expected to become the industrial Internet fact standard
• This article from: Hobby Linux Technology Network
• This article link: http://www.ahlinux.com/news/10111.html

Debianfork will publish the Debian branch without SYSTEMD.