evol262

The vast majority of intelligence assets are analysts or sigint, not James Bond-ish operators who can discard identities and their family/friend/etc like a Scooby Doo mask. This is not a plausible thing.

This _is_ Silverblue and other ostree-based repos.

This article is focused on containers because when the root OS is immutable, then mutable developer workflows/etc necessarily happen in containers (distrobox, toolbox, whatever). OSTree is/was commonly described as "git for filesystems". Every update is an entirely new system image which applies a 3-way diff. It's possibly to state in a single command "show me the drift in my config files/data versus the ref I'm running" and/or "show me the diff between my running system and an update I may apply".

There is a stark difference between a sovereign power gagging or stifling perceived dissidents and other citizens (whether they are elected officials or not) deciding you're an unethical asshole others should be warned about.

What happened to Nixon? What happened to OJ Simpson from the victim's family?

And the advantage of doing this over letting application authors maintain their own packages and deptrees with flatpaks/appimage/whatever is...?

They could be based on top of Nix. In practice, it's more likely they'd be based on top of rpm-ostree. But that doesn't do anything to close the gap between the wild west of copr/ppa/aur and "get your application accepted into mainline repos" for someone who wants to distribute their app.

The goal of systemd as an *init system* is not the same thing as the goal of some of the systemd umbrella projects, and they shouldn't be conflated. systemd as an init system is leaps and bounds ahead of sysvinit, openrc, and upstart for distro maintainers, large scale sysadmins, etc. No more need for supervisord, random scripts to flag off and on was part of VPN connection, convoluted "meta" scripts which carefully restart 5 different services in the same order and a huge mess of shell.

That said, no, Lennart did not/does not do things that way on his personal laptop. His position is that users shouldn't need to know how to configure dnsmasq to have a local caching DNS server, that 99% of the options for dhcpcd aren't used by 99% of users (who are perfectly happy to simply get an address in a fraction of the time), that most users don't need to know how to configure /etc/sysconfig/network-scripts/ifcfg-* or /etc/network/interfaces/* for their use case.

If you do, you can disable those things. You can think this is a good opinion or a bad opinion, but at least he's pushing towards some kind of solution which isn't "RTFM". If you think his ideas are bad, propose new ones. Start a project which does it better. "Just don't change anything" is not a meaningful or productive way to design software or operating systems.

> Snaps/Flatpacks/other binary-containerised stuff is one of the major reasons why I abandoned Linux distributions after 22-odd years (1999-2022), and am now a happy Apple user (the other one being abandoning X11 in favour of Wayland, and a switch to laptop-first usage, on which Linux still has horrible power-consumption).

Flatpaks/Snaps are almost exactly the same, conceptually, as apps on MacOS. Go look inside something in /Applications/... The .app is a folder, with all of its deps.

> Linux distros have a history of abandoning useful, well-understood technology for fads that then cause power users all kinds of headaches later-on (e.g. by cluttering output of useful tools like mount). Eventually, power users just lose the will to adapt, and move on.

"Power users" have a history of complaining about distro maintainers abandoning useful, well-understood techology because the "power users" don't actually understand the technology, nor do the understand the enormous headaches it causes distro maintainers to put a sane face on 30 year old design philosophies and continue moving forward.

The goal of distro maintainers is to STOP investing endless man hours in trying to make X work with high DPI displays, scaling, high refresh rates, a fundamentally insecure design model, and so on. The goal of systemd is/was for distro maintainers to STOP wasting endless man hours on edge cases because sysvinit didn't have reasonable mechanisms for "if anything in this dependency chain is restarted or changed, re-evaluate it" or "don't try to start this service if the mount isn't available so systems stop hanging on startup if some NFS server isn't available" or whatever.

> In the time of Jenkins et al the burden of creating bistro-specific packages is negligible.

Under the assumption that they are ABI stable, which is a bad one. Otherwise, it's the same old kaleidoscope of mapping out whether it's `libfoo-dev`, `libfoo-devel` for build requirements, whether it's a distro with a completely different naming system, dissecting the ELF header or reversing depchains in Python/Node/whatever to try to find deps and what THOSE are named in some distro, or whether they're even packaged at all, then building for every possible supported version of RHEL, Debian, Ubuntu, Fedora, SuSE, and down the line.

This is why "power users" aren't an important user model. Arch, Gentoo, Nix, and others exist if you want to be a "power user". Otherwise, extremely naive assumptions about the amount of effort expended by distro/package maintainers hand-wave the complexity away with "duh, just put it in Jenkins."

Flatpak/Snap are essentially a re-invention of putting things in /opt and using LD_LIBRARY_PATH or chrooting. Disk space is much less of a concern than it was before, and sacrificing a little space to AVOID the mess of shit above is a good investment.

Yes, because either you, the user, must track down .NET Framework X.Y (less of a problem now that they're stabilized) or because the application packs all of it dependencies and shoves them into \Program Files or \Windows\System32 until it's eventually 30gb with 1000 copies of msvcpXXX.dll

That's not that different from the distribution model of Flatpaks/AppImage (or APK, or .app on MacOS/iOS). It's more that, traditionally, Linux packaging solutions try to only have ONE copy of glibc or any other library, and packages are recompiled from source so the symbols resolve. Something which isn't an option on Windows, as a generality.

It's just as likely that it's "TODO: add handling for this case which is out of scope during design and which no user is likely to ever request, because the developer argued that it should be there and got shot down"

Virtualize it and pass through USB devices to the VM for the microscope camera/etc.

Silverblue is intended for the opposite of that. It is single system image mostly immutable root OS. The goal is to *not* tinker with the core OS, and do your tinkering in containers (toolbox, distrobox, whatever).

Complaining that rpm-ostree took 2 minutes to update 2 packages (rpm-ostree downloaded an entirely new pre-baked filesytem snapshot and applied it atomically) is completely missing the point, as is complaining about selinux after swapping out a bunch of system level stuff. This is like the antithesis of the use case for Silverblue, and an author who has somehow never had to build a package for anything but Arch (deb would be much worse) complaining about the difficulty of building RPMs to install/overlay on the host system, which is not the intended use case *anyway*, is silly.

A article from the relatively neutral Times of London which suggests a deeper investigation into whether the treatment of patients may be biased due to financials is neither anti-trans nor culture war.

This falsehood needs to die.

It's true for non-trivial cases, and exceptionally false for some things. Like databases. A lot of the sysctl tuning for large database environments has to be done on the host, either directly, allowing unsafe sysctls and restarting kubelet, running with privileges, etc.

This is not "independent of the underlying infrastructure" or "the VM and my laptop have the same kernel tunables set". They don't. And it matters.

Why is your project changing the license, and why do you assume that contributors would still have done so under whatever license you're changing to?

Because sometimes you have multiple, discrete applications which should be isolated, but need high performance (40gbe, optane, huge amount of CPU concurrency, whatever) and don't want to slice up the server for virtualization or run it in the cloud. Or you won't want to manage multiple pgpool/pgbouncer configs. Or you want BGP-based site failover and it's more complex with more clusters, or replicating massive data warehouses/ML data/preprod is substantially faster if it can be a job on the same server instead of replication, or...