Written by Rick Moen
(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.)
The problem seems that commercial (or more sinister?) interests at work so it is possible that such things are happening. All major Linux distributions have systemd now at its core, and I do not see any hope that it becomes easier to run Linux without it. The smartphone segment is more or less monopolised by Google-controlled Androids. So it's not much different than, lets say, OpenSolaris, which was practically controlled by Sun, and with Oracle taking over, game over. Yes, it's not exactly dead but it's a fringe community which works on "the leftovers". Systemd is too much of a disruptive beast to be tolerated in an open-minded Open Source community. It is more or less a hostile init ABI without certainty of reasonable stability for the surrounding environment. For me, it leaves FreeBSD as the "largest company independent open source operating system" (well, maybe not very good wording but you may get what I mean). I know there are things out there "just for Linux". But for many many things you can use FreeBSD and it works as well, or often better, than Linux does. Not to mention things you can hardly do with the same quality under Linux now. E.g. the current setup where I work now, with VMware ESXi and CentOS, is simply inferior to the way I could manage FreeBSD/ZFS/jails over the last years. Regards Peter On Fri, Aug 7, 2015 at 5:40 AM, Rick Moen <rick@linuxmafia.com> 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.)
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
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.)
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).
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).
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
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.
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main