> The distribution is designed to be maintainable by a single person. There is no infrastructure and the entire distribution is merely a few Git repositories.
A very clever approach, mirroring the way FreeBSD, OpenBSD have traditionally managed their core competencies.
I am a lifelong Debian fan but it has always troubled me that I can’t check out a copy of the OS’s metadata — that which is packaged in all of the DSC files or `debian/` directories — in one place.
A monorepo containing all of your business logic is a successful tactic to getting things done. There are some great pieces of behind-the-scenes Debian infra to support this — with SVN, and later git, and internal projects like Alioth — but the first class citizen of the project is still a deb-src apt entry. Inherently a one way HTTP link from the vendor to me with only a published Changelog to track changes. A solid and stable technology for a venerable project, but git-log / git-blame it ain’t.
(Of course, the success of giant open source projects and especially Debian is often because there is no central coordination. The technical and other committees were social constructs to try to keep everyone on track. Do they still function well?)
Alpine is amazing. One of the best distros I've ever used by far. So good for desktop, so good for servers, so easy to use and install, amazing package manager.
Use it as my goto choice for containers and have never had an issue. Tiny footprint and minimal OS means I can minimise attack surface and package update frequency to boot. Really nice versatile distro.
I just wish there was better musl or static linking support in the Linux ecosystem for Alpine. A lot of one-off binaries in my experience were dynamically linked only for the latest Ubuntu's glibc.
Nix it's very common to relink using patchelf, but I don't know if that makes sense linking from glibc to musl. Changing the compile environment from gcc to llvm and/or glibc to musl, means you will be building a LOT of things from scratch because upstream Hydra only builds and caches glibc. There's nothing "wrong" with glibc, but it does cause issues where a compiled binary says `-linux-x86_64` and then doesn't work with your system's glibc. I had a tool I wanted to use in an Alpine container, and switched to Debian or Ubuntu because I didn't want to deal with the incompatibility even if Alpine is smaller and faster. I got the author to put out a paragraph in the README about alternative, non-glibc not being supported by the prebuilt binary (ghc from Ubuntu isn't static).
Flatpak is great, you're able to install and run programs without configuration on most distributions. exept it also (obviously) installs all dependencies, configurations and settings while you usually only need glibc or some other variant to make a program run.
I'd prefer running without flatpak because when something doesn't work you'll be wondering wether its flatpak, the system or the program that is missing something.
A very clever approach, mirroring the way FreeBSD, OpenBSD have traditionally managed their core competencies.
I am a lifelong Debian fan but it has always troubled me that I can’t check out a copy of the OS’s metadata — that which is packaged in all of the DSC files or `debian/` directories — in one place.
A monorepo containing all of your business logic is a successful tactic to getting things done. There are some great pieces of behind-the-scenes Debian infra to support this — with SVN, and later git, and internal projects like Alioth — but the first class citizen of the project is still a deb-src apt entry. Inherently a one way HTTP link from the vendor to me with only a published Changelog to track changes. A solid and stable technology for a venerable project, but git-log / git-blame it ain’t.
(Of course, the success of giant open source projects and especially Debian is often because there is no central coordination. The technical and other committees were social constructs to try to keep everyone on track. Do they still function well?)