@EUCommission would love to, but the Italian government won't allow postal votes, nor will setup polling stations at consulates in the UK this year, so I cannot. That's 450k largely pro-EU voters being disenfranchised.
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).
@pid_eins "...and that is why we are now introducing systemd-ssh. Comes with native support of xz compression, graciously contributed by Jia Tan. Enjoy!"
'" 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 as usual, the point is not that these are bug free, but that they are regression free. The kernel upstream releases break userspace on every new release, and kernel maintainers don't care. See https://github.com/torvalds/linux/commit/a1912f712188291f9d7d434fba155461f1ebef66 for example, as Daan just found out, which removed a mount option without caring that it is still being used, so since 6.8 every btrfs device can no longer be mounted by systemd
@kernellogger well, the kernel doesn't have a bug tracker - not for real anyway, bugzilla.kernel.org might as well be pointed to /dev/null, so no idea what "reporting" would even mean in this case. I do not use BTRFS so I am not affected, just sharing what was reported to me. It looks like it was reported against the Debian kernel package too now: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071420
5️⃣ Here's the 5th installment of my series of posts highlighting key new features of the upcoming v256 release of systemd.
I am pretty sure all of you are well aware of the venerable "sudo" tool that is a key component of most Linux distributions since a long time. At the surface it's a tool that allows an unprivileged user to acquire privileges temporarily, from within their existing login sessions, for just one command, or maybe for a subshell.
@pid_eins@phako the JavaScript engine does not process untrusted inputs, only trusted configuration, so it's really not a security problem anyway. People like to talk down js but it's extremely popular and well know and stable and there are tiny engines like duktape, unlike other alternatives with similar properties like lua
@pid_eins@phako not really, JS was chosen because you need to be able to express complex configuration rules, and it's better to use a known tool than inventing a new one. It's not about IPC, the transport doesn't matter, you need a configuration-like DSL because it's unfeasible to ask every admin/user to write and deploy a new program every time some rule needs to be adjusted.
@pid_eins@phako because writing a new config file and writing a new running program are not the same thing, and while for us developers there's not much difference, for non-developers the difference is huge. JS was already a though sell because, while the dialect used is minimal and restricted, it's still potentially a full-blown language. Dealing with writing and deploying and maintaining fully independent executables would be way too much. You need dependency tracking, pipelines, etc etc.
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 "abominable" -> you somehow managed in 2024 to have a compiler that doesn't provide the cleanup attribute (you should really ask for your money back), and there's a connect+write instead of a sendmsg? Wow, with these kind of standards your code must always be a work of art! <checks Gitlab> Oh. Oh no. Oh dear. Never mind.
@hyc "RAII patterns supported by all compilers that matter and used by the kernel and other major Linux projects are garbage bloat, asckchyually" is exactly the kind of elitist drivel and delusion of grandeur that I was expecting, bravo, bullseye, 9/10
My annual plea for a thing: I want a type 1 hypervisor that just has a small isolated VM and then passes through the rest of the hardware to the main VM which runs Linux. The small VM is intended to be used to run small pieces of code that the main OS should not be able to interfere with. Does such a thing exist? (Think Xen, but with a Dom0 that can't see into DomUs)
I'll now start blocking the KeePassXC hate mob. We're all trying to do our best here and I don't need to constantly engage with new haters while trying to navigate a foreign cities metro system.
1️⃣ So let's try something new. As we are closing in on tagging systemd v256-rc1, let's see if I manage to post a brief mastodon item about major new features of the upcoming release, every few days until the final release of v256. I figure not everyone reads NEWS files, even if curious. Hence let's start today with the 1st post: the new .v/ directories. You know those .d/ directories that are quite popular in low-level Linux packages these days? While .d/ dirs never have been formalized properly…
#systemd v256~rc1 is out! You know the drill, download it, run it, find all the bugs and report them - possibly to somebody else, I'll be at the nearest pub
for a full-feature build, down 5 libs which are now dlopened on demand. Last one, libcap, will need to be swapped for some ioctls which won't happen for this release.
@codonell thanks - seems to be working well!
If some company had a pile of cash to throw at this, especially in light of the 'xz' situation, it would be really nice if we could get support for OSX-like lazy loading/resolving of shared libraries, so that they are loaded only after the first symbol is actually called. IIRC dylibs on OSX have this feature since forever
@codonell yep, hardening becomes more difficult, no idea how they solve that on OSX. Another nice feature of dylibs is that AFAIK you can detect when such a lazy loaded library is not available and fallback, like we do when dlopen fails, which is perfect for optional features
@codonell afraid not, as it's hearsay from @pid_eins 😃 iirc you can simply check if a function exists before calling it, but again all second-hand knowledge, never did OSX development work myself
