I switch back and forth between bazzite and bluefin quite often

on these and other immutable distributions, /usr is read-only, and the recommended is to use installation methods that write to your HOME (or to /var which is where docker and flatpak --system save files)

i really should muck about with container-based development flows

my current preference is flatpak, then whatever per-language package tooling (e.g. cargo for tools written in Rust, npm with a custom HOME prefix for tools written in Node.js, uv for Python projects, etc) when there’s no flatpak, then homebrew, then rpm-ostree as a last resort

for editing files in /etc my recommendation would be to set the EDITOR environment variable to point at whatever you like, installed however you like, and edit with sudoedit /etc/fstab, because then your editor is not running with root permissions

you could also point EDITOR at a custom script that mounts the target file into a container running your desired editor

even without going too-CISC it can make sense to have instructions for popular use cases

e.g. ARM has special instructions for optimal numeric operations in JavaScript: https://developer.arm.com/documentation/dui0801/h/A64-Floating-point-Instructions/FJCVTZS

and I thought I’d read something about custom instructions in Apple Silicon to optimise virtualisation (i.e. translation of x86_64 executables) but I can’t find a source for that, maybe that secret sauce is not in the instruction set

rejecting the revert is completely separate from accepting additional age-check / mass-surveillance PRs, you know this and you are being willfully ignorant

I would be very upset and very surprised if hypothetical follow-up PRs were merged into systemd, and I’m betting they will be rejected

it would be very interesting to see that attempt

but Poettering has already said that functionality doesn’t belong in systemd so I’m not sure where anyone would raise such a PR

seems like an Ubuntu/RedHat level distribution design to pull in a brand new age-verification / mass-surveillance component, or maybe modify an existing telemetry component

the birth date field only made it into systemd because it’s user metadata that is consistent with what is already stored there, whereas surveillance does not

for now, at least

again, I’d be very interested to see what happens with follow-up PRs

I’ll be upset when a cloud-connected Linux component prevents the system from working unless the real name and birth date fields have been verified

until then, this is just as inert as the real name field which has been there for decades, and far less useful for surveillance than the real name field which has been there for decades

love to hear some examples of the issues you’ve seen

for years, i’ve always completely wiped the trusted CAs and enrolled my own SecureBoot keys, and only use Linux

there have been vulnerabilities in SecureBoot, sure, but only for folks that don’t wipe the “trust Microsoft” keys away first

tell me how user-enrolled keys cements Microsoft’s ownership over my device please :)

this new anti-systemd sentiment reminds me of anti-TPM and anti-SecureBoot sentiment

having TPMs and SecureBoot on Linux machines has only ever empowered device owners to ensure that the software on their devices has not been tampered with

there’s never been a case where these technologies were used against Linux device owners

likewise, I predict that Linux device owners may find the age field useful for certain opt-in parental controls, but we’ll otherwise look back on this and shrug at the extreme paranoia

this new anti-systemd sentiment reminds me of anti-TPM and anti-SecureBoot sentiment

having TPMs and SecureBoot on Linux machines has only ever empowered device owners to ensure that the software on their devices has not been tampered with

there’s never been a case where these technologies were used against Linux device owners

likewise, I predict that Linux device owners may find the age field useful for certain opt-in parental controls, but we’ll otherwise look back on this and shrug at the extreme paranoia

you don’t have to use or like Ubuntu, but they do have a certified hardware list that might be helpful

https://ubuntu.com/certified

i’m guessing a few things somehow consume /etc/hosts mappings without going through nss /shrug

it modifies /etc/hostname for you, but doesn’t seem to touch /etc/hosts

i still prefer hostnamectl, but i’m now unsure of what benefit it offers over editing /etc/hostname directly

no, you might have misunderstood

/etc/hosts is not where the hostname is configured

/etc/hostname for the actual hostname, and a mapping in /etc/hosts pointing it at a 127.x.x.x address

seems like a pretty common practice across Linux distributions

/etc/hostname for the actual hostname, and a mapping in /etc/hosts pointing it at a 127.x.x.x address

yep, I used that command to modify the hostname, rather than edit /etc/hostname directly

I think it should be a punishable offence to share Python scripts that depend on third-party packages without any ready-to-go bundling/isolation :)

goes for any interpretted language where dependencies inevitably creep into the global namespace via distribution packagers that should know better :P

https://xkcd.com/1987/

i wonder if rootless podman would have the same permissions problem … something to try out

interesting, i wasn’t prompted or anything, from the documentation there’s the ollama/ollama:latest image and the ollama/ollama:rocm image but either way ollama will do its own detection and silently fallback to CPU if anything even smells wrong, haha

i’ve noticed a few people are not using the official ollama images 🤷

it’s a good point about pessimism, I should try harder to not spread it

you’ve put together a pretty useful table there!

RE voting with our wallets, I was mostly referring to this: https://doctorow.medium.com/https-pluralistic-net-2025-09-13-consumption-choices-marginal-benefits-66edd5d9a82e

oh, sorry, now I understand the question

yes, devices available in CrowdSupply tend to philosophically align with my values: owner is in charge, no subscriptions, cloud connectivity is not a thing or completely optional, schematics are open, drivers are open, etc

so they aren’t usually interfered with at a functionality or technological level

but they’re popularity and availability are subject to interference: we’ve already had multiple governments ban or consider banning the Flipper Zero for various reasons

and we have various media codec patents and DRM requirements that prevent truly open devices from being able to be used for popular purposes like streaming video content which pretty much guarantees that only industry-approved devices will ever gain wide distribution and popularity

I don’t think it’s too tin-foil hat to suggest that if a truly open device did gain popularity somehow, that we’d see IP lawsuits or import restrictions or mandatory modifications (e.g. countries attempting to mandate a government-operated surveillance app preinstalled on over smartphone)