--- /dev/null
+# Debian Jessie with Mate and without systemd
+
+## Rationale
+
+I am a Debian user and there are packages I don't like to be installed
+on my computers.
+
+The most visible one I skip is
+[Gnome3](https://www.gnome.org/gnome-3/). I really tried to use it on
+Wheezy. After a month of use, I expected a minimal "get it" moment
+about that new system. Didn't happen. My workflow doesn't fit at all
+with Gnome3, and it's a ressource hog on your computer. I am now a
+[Mate](http://mate-desktop.org/) user.
+
+I also remove routinely [Avahi](http://www.avahi.org/) (which only
+merit seems to bring noise on your LAN) and
+[PulseAudio](http://www.freedesktop.org/wiki/Software/PulseAudio/). This
+last one is installed by default with Mate, but often gave me no sound
+after a fresh install [^1]. When I replace it with Gstreamer, I get
+sound automagically, and there is one less daemon filling my process
+table.
+
+[^1]: And yes, I did the obvious verifications: unmuting, chosing the
+correct audio device...
+
+On Jessie I tried also
+[systemd](http://www.freedesktop.org/wiki/Software/systemd/) for a
+while, read a bit of all the flamewars going on about it and here also
+I decided it's not for me.
+
+My arguments are the following:
+
+1. The existing documentation about systemd is not usable to
+understand how it works internally; and that is a precondition to be
+able to debug problems confortably.
+2. The claim at modularity from systemd proponents is
+completely false: as all the various daemons and executables
+comprising systemd share a huge common codebase, what you have in
+reality is a monolitic system.
+
+The above two facts are enough to stay away from systemd, whose main
+programmer, surprise, was also the one involved in coding Avahi and
+PulseAudio.
+
+But my main grief about systemd is that it's actually less and less an
+init system, so it may contaminate too much of your software in the
+future. I would not object much to systemd if it was only a SysV init
+replacement.
+
+But Debian give it's users the choice to skip the init part of systemd
+while keeping the problematic non-init part mandatory.
+
+So the topic of that article is to explain what you can do to limit
+the use of systemd on your Jessie system, including the non-init
+part. As I said above, I use Mate on Debian, so I will cover the use
+of that desktop on that distribution.
+
+## Debian Jessie with Mate and systemd init
+
+So, let's start with a fresh Jessie install. To avoid cluttering my
+computers with packages I probably won't use, I chose to install only
+the "standard system" from tasksel before the first reboot.
+
+At that point, you will have systemd running, with the following
+daemons:
+
+* systemd (this is the process with PID 1)
+* systemd-journal
+* systemd-logind
+* systemd-udevd (previously called "udevd")
+
+For good measure, even it is only "recommended" by systemd, there is
+also dbus-daemon running. We will need it anyway for a desktop GUI.
+
+After the first reboot, I uncheck the "download recommended packages"
+in [aptitude](https://wiki.debian.org/Aptitude) options, then proceed
+to install Mate as a task [^2].
+
+[^2]: And if Avahi-daemon is no more installed, the default for Mate
+is still to use PulseAudio. You can get rid of the PulseAudio daemon
+by replacing package *mate-settings daemon-pulse* by package
+*mate-settings-daemon-gstream*, then suppressing package *pulseaudio*.
+
+The installed systemd related packages are then the following:
+
+| Package | Installed size | Number of files | Mandatory dependencies | Remark |
+| :----------- | :-----------: | :------------------: | :---: | -----: |
+| *systemd* | 12MB | 700 | 20 | |
+| *libpam-systemd* | 300KB | 15 | 10 | Was installed by Mate |
+| *systemd-sysv* | 50KB | 25 | 10 | |
+| *libsystemd0* | 200KB | 10 | 70 | |
+| *udev* | 6MB | 120 | 85 | |
+| *libudev1* | 100KB | 10 | 90 | |
+
+The mandatory dependencies figure is especially important for
+*libsystemd0*, *libudev1* and *udev*. *libsystemd0* is mostly used to
+ensure systemd is present, and the additional functionality offered in
+that case is (for now...) limited. The lack of functionality is
+probably higher if *libudev1* is present but not *udev*, as we have
+been living with *udev* since a long time.
+
+So *udev* development taken over by systemd is the real trouble here;
+but more about that in the conclusion.
+
+## Debian Jessie with Mate and SysV init
+
+Now let's try to replace systemd init by SysV init; this is done by
+replacing *systemd-sysv* with package *sysvinit-core*. At reboot, from the
+4 systemd related daemons present initially, there is only
+systemd-logind left, and process with PID 1 is now the traditional
+init.
+
+But the 5 other packages related to systemd are still there! So you
+can still execute commands like "journalctl" or "systemctl", just
+these are now mostly empty operations. Only "systemd-cgls" and
+"systemd-cgtop" still provide useful information.
+
+So systemd is still sitting on your system, waiting for an upgrade to
+pull in again *systemd-sysv* and recover its full functionality. At
+this point, you can put *sysvinit-core* on hold in aptitude.
+
+In addition, new packages *systemd-shim*, *cgmanager* (it launches a
+daemon) and some dependencies have been installed on your system.
+
+The following figure shows the dependencies between some packages in
+our new configuration. *mate-power-manager* may not be an installed
+package on a desktop machine.
+
+[[!img dep-systemd.png size=600x]]
+
+## Debian Jessie with Mate, SysV init and *consolekit*
+
+Exploring the packages dependencies in
+[aptitude](https://wiki.debian.org/Aptitude) gives you the following
+alternative set of packages dependencies:
+
+[[!img dep-consolekit.png size=600x]]
+
+where package *consolekit* replaces *systemd* at several
+places. Notice that it is not possible to change/suppress the
+dependency of *udisks2* and *policykit-1*.
+
+So let's go to change to the above figure by installing *consolekit* [^3],
+as a first step to limit your systemd exposure.
+
+[^3]: In the process of installing *consolekit*, you may have lost (or
+not) the ability to resume/suspend from your Mate desktop; the
+conditions under which it happens are not clear for me at the
+moment. But continuing until the end what I suggest in this article
+will recover eventually that functionality.
+
+## Debian Jessie with Mate, SysV init and a modified *libpam-systemd*
+
+As *libpam-systemd* is the only package left depending on *systemd*,
+the idea is here to modify *libpam-systemd* to:
+
+1. Restore resume/suspend functionality if it's lost
+2. Make the new package depend no more on package *systemd*, so you
+ can get rid of it
+
+To do that, I took the Debian systemd source, which I modified to
+build a new package *libpam-systemd*. The main steps were the
+following:
+
+1. In debian/control file, I only allow building of *libpam-systemd*,
+ and added that it breaks and replaces *systemd*
+2. I deleted all source files not needed in the compilation of
+ the PAM module and the daemon "systemd-logind"
+3. Some other tidying up was done (debian/rules, documentation...)
+
+This results in a smaller source package (but not so much, which
+contradicts the claim to systemd "modularity").
+
+For your convenience, all of the source files and the .deb package
+(for i386) are here:
+
+If you have installed the needed development packages, it's easy to
+rebuild file "libpam-systemd_215-17+deb8u2bu1_i386.deb" with these
+simple commands:
+
+ # the 4 source files have to be downloaded in your current working directory
+ dpkg-source -x systemd_215-17+deb8u2bu1.dsc
+ cd systemd-215
+ dpkg-buildpackage -rfakeroot
+ cd ..
+
+To install it, you will need some local package repository. An easy
+method to do it is to run:
+
+ mkdir -p ~/my-repo/dists/jessie/main/binary-i386
+ mv libpam-systemd_215-17+deb8u2bu1_i386.deb ~/my-repo/
+ dpkg-scanpackages ~/my-repo /dev/null | gzip > ~/my-repo/dists/jessie/main/binary-i386/Packages.gz
+
+Notice that "dpkg-scanpackages" is available through package
+*dpkg-dev*.
+
+Then add line (if you are user "joe"):
+
+ deb file:/home/joe/my-repo/ jessie main
+
+to /etc/apt/sources.list and update the available packages in aptitude
+to take the content of your local repository into account.
+
+You can then try to upgrade to the new *libpam-systemd*
+with aptitude. You will get a conflict. Choose to solve it by
+suppressing *systemd*, proceed with the upgrade and you are done!
+
+Some people may ask why I haven't changed the name of the new package
+replacing *libpam-systemd* and suppressed in it any reference to
+systemd. First, its source code is still pure systemd at that
+point. And secondly: not having string "systemd" in your computer will
+not make that software vanish from the universe, like not saying
+"Voldemort" doesn't make that guy disappear as by magic.
+
+## Final remarks
+
+Installing the modified package *libpam-systemd* proposed above will
+alow you to get rid of package *systemd*, while keeping your Mate
+desktop fully functional.
+
+On your computer there will be only packages *libpam-systemd*,
+*libsystemd0* and *udev*.
+
+As said above, there is (for now...) no more harm to continue using
+packages dependent on *libsystemd0*, as there is to use packages
+dependent on *libpulse0* (to access PulseAudio) or *libavahi-client3*
+(to use Avahi), even if you don't have PulseAudio or Avahi daemons
+running.
+
+*udev* is a bit more annoying as its functionality has been used for a
+long time, so it has penetrated deep in our Debian systems. Someone is
+working on an independent replacement for *udev* called
+[*vdev*](https://github.com/jcnelson/vdev). The work seems promising,
+and I will at one point experience his work.
projects / reminder / blobdiff