Debian and Devuan

Posted on Posted in News

Some days ago we have posted a bizarre proposal on our social channels about a possible migration from Debian to Devuan to get rid of systemd and all the problems that it has brought to our environment since Parrot 2.0, and with this post we will try to explain what is happening in a more official way.

We are not going to deeply explain the technical details of this choice here as it would be useful just to open another systemd flame war which is out of scope, while we prefer to explain what we are actually planning, thinking and doing.

And because we are bad people and we love to have a beer while following Unix wars, we will fill this topic with systemd memes.


Is Parrot switching to Devuan?

Nope, not yet.

We are just testing how our packages behave on top of Devuan instead of Debian, and what should be modified to have everything working without systemd (which seems to be hardcoded almost everywhere).

We are also collecting feedbacks from our community, and this is why we posted a very short announcement on our social channels some days before writing this post, and in a very very short amount of time we were able to collect an exaggerated amount of positive messages.


How would it happen? (assumed that the switch will happen)

It would probably happen with the release of Parrot 4.0, but again, only rumors there

Would i notice any differences?

One of the goals that we want to achieve, in case of a switch to Devuan, is to write some transition wrappers to make commands like systemctl continue to work on sysvinit, exactly like the wrappers that make service, update-rc.d and /etc/init.d/ launchers work on systemd.

Sysvinit or openrc?

Openrc is awesome, and we love how it correctly implements that dependency-based init model that systemd is quite far from being able to represent for the eyes of a Veteran Unix Admin.

But openrc needs a lot of work to work properly in the debian ecosystem, and the introduction of systemd has slowed down its introduction as a valid alternative in Debian, so we will use the Devuan version of sysvinit and eventually follow the Devuan work, and then switch to openrc when it’s ready.

But again, these are just suppositions of how we would like to move in case of a migration.


This is not the question, the real question is:

Do we care of what we run at PID 1?


Ok, let’s suppose the migration happens, would i be able to install anyway?

notabug wontfix.

Seriously, no one gave a fuck of people wanting (or needing) to run other init systems when systemd was introduced in most of the GNU/Linux distributions screwing up years and years of synergy.

We would be happy to see people being able to switch back to systemd on our platform, but we will not waste time and resources to make it easier.

But i want to know what’s wrong with systemd!

Again, we are not here to provide technical reasons about hat is wrong with a wrongly implemented init system, because many other people have deeply studied this situation and can explain it way better than us.

Here some useful resources:

Linus Torvalds and others on systemd – ZDnet <– here you can also understand why we don’t like gnome

Arguments against systemd – WithoutSystemd

I still don’t understand why systemd sucks – Ycombinator



I am Poettring, i am reading this topic and i dislike the way the web is treating me

We want to make it clear, we have nothing to do with those morons who started fundraising campaigns to hire a hitman to kill you, and we hate all the people who are bullying up on you.

We just consider systemd an immature init system which works almost perfectly on some standard desktop use cases. But we also believe that your approach is destroying that part of the Unix philosophy that made GNU/Linux one of the most stable and reliable systems out there.

We also dislike the way systemd took us away the sacred graal of choice.

So, again, nothing personal. Everything that may have hurt your person in this topic happened only because we love memes and freedom, and one of your softwares gave us the former but took us the latter.


  • Palinuro