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"
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.
This is around the same time that PA tried to lease their turnpike, and cities all over the US were facing a post-boom hangover when projected revenues from permits and property taxes didn't align with budget realities.
I'm not defending the decision, but it was far more shortsightedness than corruption.
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.
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.
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...
This isn't a "JS" problem. A consistent story/UX around common tasks isn't "bloatware". Queuing jobs on the backend, managing CRUD-ish stuff like native objects, multi-part file uploading (including CORS management, storage as blobs in the DB if you need it), user/auth management, sending mails, and so on really is just the basics.
Of course you can a la carte your own solution together every time, but the API at every different layer is almost guaranteed to be markedly different, the level of testing, support, size of the userbase/ecosystem is unknown, and every minute you spend debating those solutions, wiring them together, maybe creating abstractions so the API "feels" more native, etc is time you are *not* spending writing the actual application.
Finding other developers to work on your homegrown potpourri who won't screw up because they don't fundamentally understand object storage or DKIM constraints when sending mail or can't optimize a query better than the ORM or whatever will be difficult, and even harder if you want to find one who can do that AND nail down which parts of the underlying infrastructure (k8s, DNS, message queue, distributed k/v store, whatever) may or may not be responsible for a problem surfacing for 3% of your users is a harder and harder ask.
You're free to consider DRF and backend Rails and .NET and the rest to be "bloatware". I am not a web person in any way, so I don't have a horse in this race, but I am/was a backend/infrastructure person who has repeatedly had to help "full stack" web devs out of shooting themselves in the foot because they don't understand OIDC/SAML or service lookups in k8s or service meshing or DNS between geo-distributed clusters or how to write an INNER JOIN or you name it.
The "bloatware" lets web devs ("full stack" or not) concentrate on solving their actual problems instead of spending time and getting behind schedules re-inventing comprehensively solved wheels.
`containerd` invokes `runc` (and `docker` can also invoke `containerd` via its API, which then invokes `runc`). The "lower level container runtime" is cgroups and various kernel namespaces (primarily process and network, but some others are included). There's no magic there.
They are not all the same when you get down to it, though. The "different opinions" about how to plumb traffic back out from a container (DNAT/SNAT via a bridge, macvlan, whether using a CNI directly is supported), whether a service/daemon should be the primary entrypoint (docker, containerd) or whether it's optional (podman), whether they speak to runc at all (containerd/docker yes, podman defaults to crun, kata is also an option, and others), what kind of storage overlays and plugins are allowed, etc are more than "opinions".
The devil is in the details. Colima is "basically a drop in replacement for docket desktop" under the assumption that you aren't doing anything very complex with Docker. In particular, complex networking is likely to fail/explode.
GWB rebranded it as Climate Change, not anybody else.
Solar forcing is completely accounted for in the models, in all areas (albedo, bouncing in the galactic plane, distance from the Sun).
The repeated cries of "but you didn't account for this or that, which I know as a layman, but surely PhDs in climate science didn't think about!" is inane. It's in the models. Every single variable you can name and then some are in the models.
Climactic periods are not "measured" in any kind of arbitrary 3 decade cycle. Even if you want to pretend that they are, and we are returning to some kind of baseline (which every bit of science says we are not -- we are going to dramatically overshoot it), humanity did not evolve under those "historical norms". Our society and agriculture and population patterns did not emerge under those "historical norms".
Returning to those "historical norms" will mean the largest population migration in human history, with a large amount of it from nuclear states which already have shooting skirmishes in their borderlands facing an existential crisis over water (India, Pakistan, China). Those "historical norms" are not necessarily compatible with civilization.
Before you talk about how much farmland it is going to "open", ask yourself how well the supply chain did during COVID. Then ask yourself what will happen to it during a population migration. Ask yourself what happens when deep water ports at low sea level start having problems, and how we would get crude to refineries to get bitumen to even make asphalt to create infrastructure in the new "open" land, how we'd transport concrete and steel there if there are interruptions in the supply chain which impact diesel production. Ask yourself how long it will take to transform old-growth forest and granite-filled glacial retreat zones in Canada into arable land, how easily we'll be able to get chemical fertilizers, etc.
Even if you want to talk about how this is some kind of "historical norm", the question ultimately becomes not "is this anthropogenic?" (it is, but it doesn't matter), but "how do we intend to survive this as a species?"
And a bunch of other nonsense. Every one of these "predictions" is either a journalist trying to sell copy by exaggerating a story, or conservative media outlets clapping themselves on the back for pointing out that journalists who exaggerated were wrong.
None of these "predictions" are in any way science, and all of the climate modeling in the past 30 years has made predictions which are *more conservative than reality*.