Arch

I run Arch btw...such a cliche term, but it's the truth here. I use it because the rolling release nature and the speed of updates typically means I end up getting software patches pretty quickly. Which is good...as I enjoy playing games on Linux and writing software for fun. I also like ripping open the internal of my computer and rebuildings things as I see fit...this is largely why Athena is a thing. That would have been infinitely more difficult in a more locked down system.

It's not just running it

I maintain an unofficial AUR package. To be specific I maintain the git build for APX for Arch. This is effectively a package manager that wraps around distrobox and allows a user to run applications installed in docker rather than on the host system. If you are wondering why not just use flatpaks...this allows you to select the exact version you want from a specific Linux distro or to run packages which have no been packaged for your distro.

I also have contributed to the Arch Wiki. In particular the section on the Arch User Repository Linux. When you see this text: "Use git clean -dfx to delete all files that are not tracked by git, thus deleting all previously built package files." That is due to a conversation and change I made addressing an issue with the existing documentation.

I have contributed to fixes on several AUR packages I have used including Ubuntu Multipass. Which is a hypervisor utility wrapping qemu that Canonical maintains. I used to use it heavily prior to the having the server cluster of the scale I do and tooling to spin up\destroy VMs on the fly.

I also have worked with the PKGBUILD implementation of Arch to dynamically change configurations and build custom packages downstream from the official ones. For example there was a flag in upstream mesa on Arch that I did not want enabled because it at one point caused issues with one of my workloads. Specifically this was the moment I made a custom build due to a change with sysprof. And it's not the first time I've decided to modify upstream packages so I've largely gotten fairly comfortable with it.

Some strangeness

A little known fact every time a new version of electron is released Arch releases a new package. Go ahead, go to the Gitlab and search "electron". This is an issue because there is a delay in package creation in Arch that is nontrivial so if you run something like Synapse and it needs a new build of electron you would effectively end up on an older version of Synapse until a new version comes out and both the electron as well as Synapse packages make their way out of testing.

Strangely this was also my introduction to NixOS. I ran into this problem and wanted an update to date version of Synapse. NixOS solves this probably very elegantly due to how they address dependencies and not symbolically linking everything.

Sadly though...that is not how the OS went as a whole so we're here with this strange issue and a series of attempted containerization technologies to manage these dependencies.

Knowing that...a few notes

Manual intervention and maintenance is expected\part of the design\ethos. As is the ability to completely break your system. It is your right to change, configure, or alter whatever you want. The responsibility of the system shifts from the distro to you which is a very sharp departure for some. For the most part the system will just stay out of your way. Which is great if that's what you like to do...less ideal if that's not what you're looking for.

Personally...I like the fact you can change internals trivially. I run a tiling Window manager, a custom mesa build, have run custom kernels if I feel a need, I have run modified display managers which was very difficult in other distros (I used to maintain a small script\program to repackage GDM changes for hybrid graphics support into Ubuntu back in 2014-2015, that was an entire project...in Arch it would have been a single PKGBUILD change...in Ubuntu that was something 3000 downloads). But the ability to do that is the direct result of ownership of the system shifting entirely to the user.

A lot of people run Arch and then complain about instability or issues with the runtime. Something like the AUR really let's you overwrite core dependencies if you choose and if used carelessly can very quickly result in a broken system. It requires a lot more knowledge\care than is typically expected by most Linux distros. Care and understanding the tooling avoids a lot of issues.

Flatpaks and containerization technologies for dependencies avoid a lot of broken packaging issues that can arise on Arch due to being so bleeding edge so if you opt to go for something that's not in the official repos...maybe check to see if there is a flatpak before you build a from source package. In some cases like OBS these may actually be less broken than the official packages because the application developers built the flatpak.

Also the AUR has had a lot of issues with malware in recent years. This is mainly because anyone can upload or take over a package. So if you are blindly installing packages there is a nontrivial chance you get malware or a broken system. Read the PKGBUILD for the package, understand it, verify the source is authentic, and then run it if you trust it.

My deployment

Mostly official Arch packages, a small number of carefully vetted\selected AUR packages where there is no way around it, a number of flatpaks from the official developers, and a home directory on a seperate partition in the event a reinstall happens.

In general my systems are very stable and run pretty much official software or things I have built\changed.

I have few complaints...my system just works for anything I want to build. I mostly just wrote this out to talk about the cool things I've done in that space.