Welcome to a world after systemd. After systemd?
Why after systemd?
We think that even though many distros have adopted systemd, the general design or motivation of the project is not good and will lead to more problems than it solves.
We anticipate that systemd is currently in fashion, however many of us have seen software rising and falling, especially if it was ill designed (sendmail anyone?).
In that sense we are planning for the time when distros and users are beginning to migrate away from systemd.
What this site is about
Our aim is to find a good exit strategy for distros and users of systemd.
We do so by analysing the current situation, the needs that systemd actual fulfills and the problems it causes and how to get rid of those.
We focus on being productive for the next generation of people using Linux and other Unices (yes, they exist and yes, they are important, too!).
What is this site not about
It is not a place for ranting. If you want to blame/rant, please look for another site.
Problems to solve
Linux only orientation
The current implementation of systemd is highly Linux centric, which is a major problem if other software that is being used on other Unices begins to depend on components of systemd.
At this point of point we know about gnome depending on systemd (or not, depending on your point of view).
Writing portable applications has the advantage of finding bugs in your software and in contrary to what the systemd authors think, POSIX is actually helping writing portable apps for a long time.
Starting Services in chroots (technical)
When you run an init system like systemd that requires a helper program to start services (systemctl), it is not easily possible to start services in a chroot, because the chrooted systemctl cannot connect to the outer systemd.
Using init scripts or a different type of cli that does not require another daemon to run (like sysvinit does with the shell scripts below /etc/{rc.d,init.d}), solves this problem.
There is a detailled description of the problem at 0pointer.de.
So in short, running services in a chrooted environment became harder with systemd.
Pros and Cons
Let's have a look what systemd actually makes better and what are the problems that are new due to having systemd.
Again, this is not a rant-or-blame page, but focussed on analysis and to make the basis for future steps.
If you do not agree with something written here, please update this website.
Unifying Distributions (political/technical)
One interesting outcome of the development around systemd is that many distributions adopt it. If you dislike systemd (for whatever reason) this may be a disadvantage. However, having the same init system on all Unices would make life much easier for sysadmins and authors of configuration management systems (like cdist).
Brainstorming
Currently we are brainstorming in various groups about what are good ways to keep or regain freedom of chosing to live with or without systemd.
The radical move #1: Change your OS
When you read reactions of people who are unhappy about systemd, you will find one solution to the problem very often: To change the OS to something that is not dependent or tightly coupled to systemd.
Currently this could mean switching to a BSD based OS or Gentoo (list of Linux distros staying without Systemd tightly coupled should be added here).
The radical move #2: Fork your OS
If you want to stick with your OS, but don't like to be forced to use systemd, but the OS maintainers decided to go or stay with systemd, a radical, but maybe problem solving move may be to fork your OS.
This idea has been spoken out in form of a Debian Fork so far.
Why do some people like to use systemd?
To be honest, there are not only people who dislike systemd. So for some reason, people were inspired to switch and see using systemd as an advantage.
So in case it becomes clear, what people aspire, there is a chance to rebuild those components of systemd in a modular, Unix way and to remove or stay without systemd.
Maybe it is about
I want to contribute!
That's great! There are various possibilities to help:
Talk about us
Mention #theworldaftersystemd on Twitter, talk about our movement on IRC, help others to understand why the current implementation of systemd is not a good idea.
Use your favorite chat/publish/mention tool to do so and include us. We are reachable on IRC (see below), via mail theworldaftersystemd --at-- ungleich.ch or Twitter @ungleich and @NicoSchottelius.
Discuss with us
You can find us on #cstar on Freenode.
Change this website
If you want to change this site, simply clone the repositiry on github and open a pull request.
This site uses markdown as interpreted by ikiwiki.
Resources
- A nicely writen report about design flaws of systemd
- uselessd, a fork which reduces systemd to an init system again
- Boycott Systemd -- Collection of arguments against systemd, maybe ranty.
- Debian package tools for avoiding systemd
- Phoronix on Debian and systemd
- Phoronix on Debian and systemd
- Mailing list for discussing how to keep Debian independent of systemd
- Debian Fork
- Debian's General Resolution about Init System Coupling
- Systemd fun