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