Hello Rick, On Thu, 2015-08-06 at 12:40 -0700, Rick Moen wrote:
Quoting Mark Trickett (marktrickett@gmail.com):
The fact it does binary logs is a _very_ _major_ defect in my opinion and experience.
For completeness, I'll note that it's pretty easy to disable the handoff of logging information to systemd-journald and substitute a handoff to rsyslog or syslog-ng, instead. So, for example, the Debian package for systemd defaults to rsyslog as system logger.
(Your point is of course well taken about the wrongheadedness of systemd-journald binary logfiles, which tells you all you need to know about the wisdom of entrusting system architecture to these particular coders.)
Thank you for this response. It contains most of what I will need when I do an install of Jessie. One query, what window managers have you tried without systemd, and what you find particularly good or bad. For myself, I find the older desktop metaphor more effective and productive.
I noted that it is possible to put openrc on Debian 8. I shall need to do a bit of research. Some notes from you and/or Rick Moen would be very appreciated.
apt-get install openrc
Reboot.
apt-get remove --purge --auto-remove systemd
The basics are remarkably simple, but the completeness that follows is very appreciated.
Note that said command will remove these Debian packages if they are present:
o 5 GNOME packages that directly on systemd: gnome-bluetooth, gnome-settings-daemon, gdm3, gnome-core, gnome-disk-utility. (This is essentially the GNOME requirement for systemd-logind for 'seat' login credentials, which has become problematic to satisfy without systemd because the Freedesktop.org coders orphaned ConsoleKit, and ConsoleKit2 isn't yet usable last I heard.)
Interesting, on what has been done, and what has not been done. Does make changing desktops from Gnome a necessity. I have found the changed direction of Gnome less productive for me, but some of the lighter ones with more traditional workflows more to my preference.
o 10 debian-installer* packages that depend directly on systemd because the Debian 8.0 default installer provides systemd
o 1 WindowMaker dock applet for shutting down a machine by clicking a button (wmshutdown).
o 5 packages that depend on systemd because they're systemd-related: (live-config-systemd, libpam-systemd, systemd-dbg, systemd-sysv, libpam-systemd).
o 1 GNOME-affiliated display manager that requires either libpam-system or consolekit (lightdm).
o 6 assorted other packages that require that systemd _or_ something else be present (mate-power-manager, solaar, libguestfs0, sogo, ligthttpd, lxsession). Details omitted here but you can look them up in package metadata.
o 2 packages from the core Freedesktop.org stack -- the guys responsible for most of the furious code churn in GNOME -- that depend on libpam-systemd (policykit-1, udisks2).
o 1 wireless/Bluetooth network manager from GNOME that depends on libpam-systemd (network-manager).
So it also removes NetworkManager? There are alternate ways of coping with changing networks, I need to find references again. I have found the way NetworkManager tries to handle the connections is not the way I use my PC or notebook. There are bits that work, but also bits which it ripe royally leaves me up the proverbial creek without a paddle.
o pcmanfm, daisy-player, and a couple of other obscure apps that require policykit-1 that in turn requires systemd One depending on policykit-1 that is not at all obscure, is a rather infuriating and pointless dependency hairball, and merits rebuilding the package if you need it (hplip).
This is of significance. I have HP LJ4L and LJ4P printers, although needing a bit of servicing, and a HP LJ4Plus. The latter runs under Postscript, so may be less of an issue. It is a significant package for many of us.
Measures to keep systemd from being installed in the future:
echo -e 'Package: systemd\nPin: origin ""\nPin-Priority: -1' > /etc/apt/preferences.d/systemd echo -e '\n\nPackage: *systemd*\nPin: origin ""\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd
If your system uses multiarch (32 and 64bit packages), do this too, to pin the 64bit version of systemd:
echo -e '\nPackage: systemd:amd64\nPin: origin ""\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd
In other multiarch cases where amd64 is the default architecture, you may have to pin the i386 package:
echo -e '\nPackage: systemd:i386\nPin: origin ""\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd
This is valuable admin information, and a good example that I can use for related things where I want to effect changes.
Above is from my notes of changeover conducted on a virtual machine, so I'm reasonably confident they're complete and correct. Getting rid of udev/libudev1 and getting any replacement (eudev, mdev, vdev) to work with the latest xserver-xorg packages is an experiment I've not yet undertaken.
A few things such as bsdutils and util-linux have started to depend on libsystemd0, but that seems harmless.
Thanks again. Regards, Mark Trickett