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".
I think Silverblue's approach is a good start, but for desktop usage I'd like to see userland "environment" things like DEs get their own layer with a similar treatment as the root OS, so you could e.g. roll back GNOME or KDE independent of the rest of the system if you so desire. This would also make it very difficult to inadvertently put the system in an unusable state through things like dependency conflicts — if your DE fails to start it can simply fall back and start the last known good version.
The lines for what counts as "environment" are fuzzy which might pose a challenge, but the fix for that could be as simple as offering sane defaults and letting the user decide what is/isn't included.
> I'd like to see userland "environment" things like DEs get their own layer with a similar treatment as the root OS, so you could e.g. roll back GNOME or KDE independent of the rest of the system if you so desire. This would also make it very difficult to inadvertently put the system in an unusable state through things like dependency conflicts — if your DE fails to start it can simply fall back and start the last known good version.
Yes! I've been thinking about the same thing as an accessibility feature for disabled users, as well. I recently learned that I'm going blind, and so I've been thinking about how this kind of mechanism could be used to ensure that a system always has, e.g., a working screen reader and fullscreen magnification software. I'd like to add something like this to NixOS, which is my favorite distro and daily driver.
>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".
I can see how this can be usable for configuration. But I am having a hard time imagining how this would look for something like PostgreSQL's data files.
/var is not immutable, /home is also relocated to /var/home on Fedora Silverblue for this reason (as far as I recall, it's been a while since I've checked up Silverblue)
I have switched to fedora Silverblue because I wanted my system to be as stable as possible between updates. But I think it's true that one has to delve into container technologies to fully use the OS, and that is a bit of an overhead.
These types of distros are currently suitable for users who are either very advanced OR non-technical (who’s needs are completely filled by an app store).
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?
> 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.
Mac and iPhone apps don’t automatically update unless you tell them to.
The goal of systemd is to make everyone do everything the way Lennart Poettering likes it on his personal laptop. Perhaps some of it is nice but also some of it is not nice. And his holier and smarter than thou attitude is off putting and rightly so.
And don’t handwave away wasting my resources just so you can avoid work. That’s how we end up with Microsoft Teams.
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.
Some interesting gaslighting here, complaints about the forced systemd ecosystem can be deflected by pointing at the init system. Which, just like the rest of the ecosystem, improves some parts and deteriorates others like the absolutely worthless journaling log replacement.
Anyway I’m not about to engage the systemd evangelization task force, thanks. Good luck elsewhere.
> 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."
Surely distros could be based on top of Nix with carefully curated sets of packages with less effort than it takes to package everything for Debian.
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.
Translating from Nix to another packaging ecosystem usually entails removing specificity. This is why going in the opposite direction is harder. So I suspect we can provide escape hatches from Nix into Debian/RPM/Arch/Gentoo so that one would only have to maintain one fully specific package, but get easy translators for the other ecosystems.
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.
> 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.
I can assure you I've built packages for more than just Arch Linux, and that building RPMs was by far the most frustrating experience of all :)
I don't want to tinker at all. I just want to get some work done. That is why I run Debian stable. Back when I first installed Slackware in 1994 I spent a lot of time tinkering. I am through with that now.
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.
But Chicago did lease the parking garage underneath Millennium Park to the same parking meter investor group. And that deal went bankrupt with the lease going back to the lender (who set up a new consortium which is also on the verge of bankruptcy).
So basically the two parking deals have just now broken even ;)
> Amid a legal skirmish with the city over the underground parking garages, the venture is in talks to relinquish them to banking giant Societe Generale S.A., which provided a $403 million loan to finance the 2006 deal, sources said. It's a sign that the investment has lost so much value with little prospect of a turnaround that the venture no longer sees a reason to own it.
> Chicago CFO Gene Saffold said the Midway Investment and Development Company, the group that successfully bid on the 99-year airport lease in September, was unable to secure financing, leading to the deal’s demise.
People are often trying to implement and shorten term limits. But it amplifies this problem, and it gives lawmakers an incentive to line up their next job in the private sector while in office.
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.
