[Semibug] tragedy of systemd: was: OT: is there any office package (especially spreadsheet) that lets me choose a PEN color

[Ron / BCLUG]

Jonathan Drews wrote on 2024-05-23 19:54:

> I don't know what the cause was but I could never get scanning (xsane)
> to work on either Linux Mint or Kubuntu.

Scanning has been a solved problem in Linux for a decade or two, so it's 
hard to know what went wrong, nor what purpose is served bringing it up 
really.


> One of the claims about systemd is that it would provide faster boot
> up. However, my Devuan Linux boots faster than either KdeNeon or
> Kubuntu or Linux Mint. All three were installed on the same T480
> laptop, which now runs Devuan.

All running KDE?  With the exact same packages installed? Seems like 
apples to oranges without that info.

What times did you measure for them?


Parallelism is pretty much always going to be faster, all else being equal.


General question for the list: how does one diagnose which process(es) 
slow down booting up on non-systemd hosts?

I run `systemd-analyze blame` and get a nice list like this:

         1min 10.758s plocate-updatedb.service
              31.549s apt-daily.service
              31.283s apt-daily-upgrade.service
              15.423s fstrim.service
               7.902s dev-loop2.device
               6.296s snapd.service
               4.059s systemd-networkd-wait-online.service
               3.830s systemd-udev-settle.service
               3.819s smartmontools.service
               3.433s zfs-import-cache.service
               2.432s postfix at -.service

I can see at a glance exactly what is going on with my boot sequence timing.

Is something like that even possible on non-systemd machines?






> Finally there is the xz exploit, which has a writeup:
> https://marc.info/?l=openbsd-misc&m=171179460913574&w=2
> 
> it leads in with a quote to remember -
> 
> "This dependency existed not because of a deliberate design decision
> by the developers of OpenSSH, but because of a kludge added by some
> Linux distributions to integrate the tool with the operating
> system's newfangled orchestration service, systemd."

"kludge". "newfangled".

That's quite the biased take on it, not worth the time it took to read it.


The xz exploit was a nation-state attack targeting sshd via xz-utils as 
a vector, then pivoting via systemd's dynamic linking of xz.

Everyone knows that if one is targeted by nation-state actors, it's 
pretty much game over.

Defenders need 100% success, attackers only need 1 success.



As for systemd linking to xz-utils, everyone realizes that log files get 
compressed, I hope?


When software statically links libraries, people complain because:

* multiple versions statically linked "waste disk space"
* with dynamic linking, a vulnerability only needs one library to be 
patched for all apps to be patched

The flip side is, one compromised library and lots of apps are 
vulnerable, I guess.

There isn't really a Right Answer™ to statically vs dynamically linking.


Anyway, systemd had a patch committed that would statically link 
xz-utils, just waiting for distributions to bundle it, when the xz-utils 
hack happened. FWIW.


rb