I don't remotely want to use Windows 2000 again, but it is interesting to see a version of Windows where the UI was consistent. Currently it is a mishmash of four generations of GUI toolkits, some UI is in one style, some UI is another, etc, etc
and that particular init process did way more than any init process ever should even before somebody had the bright idea to add "docker compose substitite" to its ever growing list of responsibilities.
you could put a word processor and games in their too if you really wanted. is that a good idea? ill leave that for the reader's judgment.
systemd just provides the feature to use a custom external application to configure a service based on a declarative spec, which podman uses to create actual systemd services from a declarative container spec.
From the podman docs:
> Podman supports building and starting containers (and creating volumes) via systemd by using a systemd generator.
Putting aside all the other issues one may have with systemd, this feels like a decent feature for a service manager to have (custom generation of service specifications).
> bright idea to add “Docker compose substitute”
Why is this so revolutionary? Docker-compose is just a service manager for containers. Systemd is a service manager. Systemd allowing podman to give it “container” features seems pretty reasonable.
> before somebody had the bright idea to add "docker compose substitite" to its ever growing list of responsibilities.
systemd itself isn’t acting as a docker-compose substitute. Podman simply translates unit files containing docker-esque configuration (image name, volumes, etc.) into plain systemd unit files that contain (among other things) an ExecStart line that starts the container with the proper arguments.
> Running individual services that would have been RPMs?
Essentially this. Rather than adding anything on top of systemd (which is almost certainly running anyway) quadlets are a way of turning containers into systemd units, and directing systemd to run them
I think it is the lightest weight, but still convenient, way of running a container as a daemon, with all the pros and cons that implies
I use Nix extensively, but the Nix daemon doesn't do much of use that can't be achieved by building your code from a fixed OCI container with internet turned off. The latter is certainly more standard across the industry, and sadly a lot easier too. Nix is not a revolutionary containerisation technology, nor honestly a very good one.
The value in Nix comes from the package set, nixpkgs. What is revolutionary is how nixpgks builds a Linux distribution declaratively, and reproducibly, from source through purely functional expressions. However, nixpkgs is almost an entire universe unto itself, and it is generally incompatible with the way any other distribution would handle things, so it would be no use to Fedora, Debian, and others
At work we went back to a Docker build to make reproducible images. The primary reason is poor cross-compilation support in Nix on Arm when developers needed to compile for an amd64 service and derive image checksums that are put into tooling that are run locally for service version verification and reproducibility.
With Docker it turned out relatively straightforward. With Nix even when it runs in Linux Arm VM we tried but just gave up.
This is a myth. The 787 has about 60 million miles of wiring in it. It is vastly more complicated than an airliner from the 1940s, and it also much, much safer. Poorly engineered technology fails, not necessarily complex technology
> secondary problem is the stacking of abstraction layers docker / kubersomething
Then don't use Kubernetes or Docker? They aren't mandatory
No this is a common rule in industry in particular.
The more components you add a component into to a defined system (excepted for redundancy purpose), the higher the probability of failure.
This is exactly why Toyota provides tier A car in term of reliabily and majority of European / US car full of failures by adding a lot of useless gadget.
> Write as much CI logic as possible in your own code
Nix really helps with this. Its not just that you do everything via a single script invocation, local or ci, you do it in an identical environment, local or ci. You are not trying to debug the difference between Ubuntu as setup in GHA or Arch as it is on your laptop.
Setting up a nix build cache also means that any artefact built by your CI is instantly available locally which can speed up some workflows a lot.
Absolutely. Being able to have a single `nix build` line that gets all the way from source to your final asset (iso, ova, container image, whatever) with everything being aggressively cached all the way along is a game changer. I think it's worth the activation energy for a lot more organizations than realize it.
Imo, the “activation energy” is a lot lower than it appears too. The determinate systems nix installer solves a lot of the local development issues and it’s fairly easy, as a first pass, to write a simple derivation that just copies your current build process and uses nix for dependencies.
Sounds like a business that surfaces the power of Nix with a gentle learning curve as a simpler, cleaner CI tool could have some success. Every time I see Nix come up, it’s described as very powerful but difficult to learn to use.
Is this Firefox rebranded with anything privacy breaking removed?
Personally that is what I want. A minimal set of diffs on top of Firefox that turns off anything obnoxious Mozilla might (or might not) add, but is close enough to the original codebase that it can be updated with security fixes right away
It sounds like LibreWolf and Waterfox both fall into this category. Difficult to distinguish much between the two.
There's a 2yo reddit thread [0] in which the Waterfox founder claims that Waterfox balances privacy with usability, and has the advantage of an auto-update feature. This could be outdated as I just installed LibreWolf and there definitely was an auto-update option in the installation dialog.
There's also an article on OnionEngine [1] which compares the two. According to this, Waterfox has support for legacy add-ons, but unlike LibreWolf does not necessarily disable trackers by default. Hard to see how up to date the article is.
By the sounds of it, if you have a strong privacy prefence and don't mind compromising usability for the sake of privacy, Libre Wolf may be the better bet.
Librewolf portable [0] is available via the PortableApps.com launcher, which is great for keeping it from scattering files everywhere or for carrying it on a USB drive for Win32/Wine users. Waterfox Classic used to be available, but that stopped a long time ago, and the new Waterfox was never available, to my knowledge. Additionally, the portable version of Librewolf, while lagging slightly as most portable editions do, is updated fairly frequently.
This is why I ended up choosing Librewolf - I prefer to have more control over where files are stored on the Windows platform. I also took the extra step of creating the TempForPortableApps [1] folder as well.
That's a great shout. Portable versions of apps are really useful if you want to sync tools e.g. over syncthing/pCloud/Dropbox, or you work for companies with draconian installation policies.
The modern version of Waterfox does not support legacy addons.
There's a Waterfox Classic, which does, but even that is mostly obsolete these days (add-ons may work, but many websites don't). And I don't think it's getting regular security updates.
- https://kermit-font.com/_css/KermitRoman-VF.otf
- https://kermit-font.com/_css/KermitItalic-VF.otf