When pondering whether we should start linking to some external library in systemd, I usually spend some time looking at the library's sources, to understand the quality of the code. While coding style differences are fine, there are certain red flags that make libraries unsuitable for use in systemd, or that indicate questionable quality of the code.
Red flags like this are for example absence of OOM guards on malloc(), absence of reasonable error propagation,
placement of too much state in global variables or TLS (instead of maintaining clean context objects), obvious TTOCTTOU races around file use, open coded structures, absence of symbol prefixing and so on.
But there's one red flag that I want to write about today, that's just so annoying, because it's not widely understood to be the devil's work: use of ELF constructurs/destructors.
In ELF/gcc you can mark functions as ELF constructurs or destructors. Functions marked like that…
… will be automatically called whenever the shared library they are placed in is loaded into a process (which means at process startup, before main(), or at dlopen() time) or when they are unloaded from a process (which means at exit() time, or dlclose() time).
At first, from the outside the concept seems kinda OK: it has this C++'ish RAII feeling to it to: whenever a library is initialized in can initialize some fields, and whenever deinitializes it can release them again.
During the last Canonical engineering sprint someone mentioned it is possible to know if a terminal has light or dark a background and adjust colors to match, so that application text remains readable.
Yesterday I took a stab at this and implemented a trivial crude version that works on both MacOS terminal and GNOME terminal, but not the Windows terminal.
Here you can see it work both locally and across ssh to another OS and CPU architecture.
1️⃣3️⃣ Here's the 13th installment of posts highlighting key new features of the upcoming v256 release of systemd.
ssh is widely established as the mechanism for controlling Linux systems remotely, both interactively and with automated tools. It not only provides means for secure authentication and communication for a tty/shell, but also does this for file transfers (sftp), and IPC communication (D-Bus or Varlink).
'" The data shows that “frozen” vendor #Linux kernels, created by branching off a release point and then using a team of engineers to select specific patches to back-port to that branch, are buggier than the upstream “stable” Linux #kernel created by Greg Kroah-Hartman. '"
@kernellogger@bluca sure, but then the rule is not "we never break userspace" but more "move fast and break things, and sometimes revert where people protest too loudly".
I mean, that's fine by me, but maybe they should communicate it like that then.
The thing is that removing a widely documented mount option is very obviously a compat breakage. You cannot discount that. It's not just a "mistake" to remove something like that, it's an obvious attempt to break compat.
I find the sound of that mail quite different from your much weaker "let's maybe undo the worst shit if people complain too loudly"... And of course "uh, sometimes we fucked up so hard, we cannot fix it anymore, let's add a new api instead" (which is what happened in the block device capabilities/media change api).
(again, I actually find it OK if API is broken from time to time, just be honest about it, and communicate properly, and do a bit of research first. Don't claim that uppercase extremism and then do not even superficially follow through)
My laptop screen broke, so I figured I could use my #SteamDeck as replacement. Didn't want to loose Steam OS, though, it's a gaming device after all.
So I bought a SanDisk SD card for 35€, and used #mkosi to flash a #fedora workstation disk image onto it. Took a few days to understand what #fedora packages I need for the full workstation experience, but in the the end the process was surprisingly smooth.
And yes I am pretty sure they should revert the kernel change. Departing needlessly from the option name the other file systems give this is already wrong. But breaking all current systemd versions on new kernels just for the fun of it is extra wrong.
Note that I actually do think it's ok if kernel folks break interfaces every now and then if done for a good reason and if userspace is prepared. But here neither is the case. And my main beef here is that they claim they wouldnt do it ever...
From gratuitous use of superfluous language features (a cleanup handler, for a single fd, srsly?) to inappropriate use of standard POSIX APIs (using connect+write on a socket that only sends one message and then gets closed, really?) Older compilers don't even support a cleanup attribute, and this code is used as a model of portability??
@hyc@wednesday well, any compiler used on any Linux from the last decade or more supports the cleanup stuff. And that pretty much matches systemd's intended audience.
1️⃣5️⃣ Here's the 15th installment of posts highlighting key new features of the upcoming v256 release of systemd.
systemd integrates with many components of the OS. Due to this it links against various external libraries. Generic distributions – which typically enable all features a package provides – usually have to deal with relatively large dependency trees in cases like this.
systemd is often used in smaller environments, i.e run in containers, or in the initrd or similar. Hence a large dependency tree is problematic.
Because of that in systemd we started to turn a large number of our dependencies from regular ones to dlopen() ones: instead of always requiring some shared library we only load it the moment we need it. This means we can gracefully degrade our feature set if certain libraries are not available.
We have been doing this since quite a while, so that in v256 22 of our dependencies have been reworked like that.
This has the benefit that on a typical system the systemd binary itself only pulls in the C library (including libm), libmount, libselinux, libaudit and libseccomp.
Net result: we have a tiny required dependency footprint, but can still provide a large feature set, if the optional deps happen to be installed.
This comes at a price though: since our library dependencies are now dlopen() based they do not show up in the ELF metadata of our binaries anymore. And package managers such as dpkg/rpm generally look at that, and automatically translate those ELF dependencies into packaging dependencies.
Hence: at first glance, this means that we regress on this front: previously automatically determined dependencies have to be encoded manually again.
There's now work ongoing to process this data automatically at rpm and dpkg build time, so that we get the best of both worlds: "weak" dependencies and proper metadata to declare them consistently.
For now the spec sits in systemd's repository. We intend to add it to the uapi group's repository soon though, as this really is supposed to be something not only systemd provides, but any software that is in a similar situation and uses dlopen() to gracefully import a fixed set of external libraries.
And that's all for now. Stay tuned for episode 16 soon.
(Sorry for not keeping up the pace btw, currently at a conference)