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)
"[…] The key pair on TPM side is generated from so called null random seed per power on of the machine [1]. This supports the TPM encryption of the hard drive by adding layer of protection against bus interposer attacks. […]"
1️⃣4️⃣ Here's the 14th installment of posts highlighting key new features of the upcoming v256 release of systemd.
This one is going to be quick one. Previously, you had to specify a block device name when invoking systemd-cryptenroll, to specify which encrypted volume to enroll your PKCS11/TPM2/FIDO2 device to. This is now optional. If no device is specified, then the tool will now automatically look for the device behind the /var/ directory and operate on that.