4️⃣ Here's the 4th installment of my series of posts highlighting key new features of the upcoming v256 release of systemd.
You might be aware of systemd's per-service setting "ProtectSystem=". When used it ensures the service lives in its own mount namespace, detached from the host's and various key directories become read-only to the service, in particular /usr/. This reflects the fact there's very little code that should ever be able to to write to /usr/.
@pid_eins Any thoughts on making an option in the system.conf to apply ProtectSystem by default in all services spawned by the system manager (basically, flipping the default) without changing how /usr/ is mounted? Or does that not really change things whilst still causing compatibility issues?
Getting really sick of painstakingly migrating to some Cool New Technical Thing With Superpowers and then whoops, It's All Ethics Violations after a while.
First #Kagi - CEO is a white dude who can't read the room when a bunch of users raise serious concerns re: suicide warnings, .ru indexes, Brave collab, etc.
Now #Nix / #NixOS - BDFL is a white dude who can't read the room when a bunch of users raise serious concerns re: toxic members, shitty governance, MIC sponsorship, etc.
@danderson@bitprophet I don't know if it's really better, but Arch has mostly done well for me. And it has a large community - they've gone through the growing pains & maturation involved.
@danderson woah, what happened? (Is happening?) What keywords should I use to find out more? I'm just an outside passive observer, but a fan of the ideas.
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…
In bash, writing ${var?} instead of just ${var} or $var means if var isn't defined then bash will throw an error and not execute your command, instead of expanding it to "" and carrying on.
mv file1 file2 $subdir # oops, I overwrote file2
mv file1 file2 ${subdir?} # error message instead of disaster
My favourite use of this is for example commands in documentation, with placeholders for the user to fill in. Then it's OK if a user accidentally copy-pastes it without filling them in!
@simontatham@muvlon@Rob_Russell@hendric if y'all didn't know, set -o pipefail is also very handy - it means that earlier command's exit codes won't be overridden by later commands that have been piped. That is $? is non-zero if any command in the pipeline is.
So fail | grep blah still results in $? being 1 (or whatever else)
@simontatham@muvlon@Rob_Russell@hendric The combination of the three are so handy that I have an editor snippet called "strict" that I use in scripts to add set -euo pipefail. Makes bash a lot more sane!
I pulled together notes on all of the LLM plugins that have worked for me for Llama 3 - both for hosting locally (I've run 8B and 70B on my 64GB M2) and access via APIs (Groq is SO FAST for that)
@mjg59 I'm surprised that it wasn't a thing already! Seems like an obvious win for a bunch of situations. I'd love to turn that on for a bunch of daemons, seems very reasonable to me.
@Edent as others mentioned, this is a Gitlab specific "feature". Classic SSH keys don't have any date information. There's a thing called "SSH Certificates" that use X509 certs to if you want that pain. (Useful in other ways though.)
re: Same keys - its fine, IMO. Better to have different keys per computer. Also better to have different keys per security domain. (Personal servers vs corporate servers vs external companies.) But 'better' is relative and marginal.