Thanks for the elaboration!
The reply was already becoming quite long, so I deliberately chose to cut some corners here and there. I was hoping that the "somewhat" qualifier would do the heavy-lifting π.
throwaway403
joined 2 months ago
I used it in this sense. But yeah, I admit it's not the traditional dictionary meaning. Unsure if it would be right to qualify it as a semantic change, though.
It has been my pleasure :) . Thanks for the kind words!
Arch is an OS thatβs quite fully featured
Not entirely sure what you mean with that.
suited to veteran/power users
The gist is that Arch pretty much comes with little to no defaults. So, you are literally put into the position to make all the important decisions. Which, as you might have imagined already, basically requires you to be pretty knowledgeable on Linux in the first place. Thus making it mostly unsuitable for new users. Though, I won't dismiss a special breed of newb that somehow manages to rawdog it quite 'successfully'.
because it has regular updates
We refer to its release cycle as rolling release. Which basically alludes to the absence of a point release.
The version of Linux Mint you were on is 21.2 and you'll soon be on 22.3. After some time, you'll be on 23.x etc. These are referred to as point releases. So, whenever a new point release update hits, you'll receive a couple of months' worth of updates. And between two consecutive point releases, you'll receive little to no updates. So, basically, Linux Mint deliberately chooses to hold updates of. By doing so, it ensures you'll only receive updates that have undergone thorough testing.
Arch, on the other hand, has a much leaner testing phase. Heck, as pointed out earlier, it doesn't even wait for a certain moment to reach before it outputs an update. Instead, after the packages have had some testing, it pushes the updates out for its users to receive it. As such, you'll receive constant updates. And you're somewhat expected to at least perform daily updates. By doing so, it ensures you'll always have access to the latest and greatest.
Note that Arch is not the only rolling release distro. But, out of the 'Big 3'^[The others being Debian and Fedora*.], it's the only one that is rolling release by default.
Its release cycle does indirectly contribute to Arch being less newbie-friendly. Basically, any update comes with the risk of causing breakage. On Debian, this risk is partly mitigated by the infrequency of updates and by pushing out very well-tested updates to begin with. On Arch, you just have to deal with it every once in a while.
Note, however, that it's most often your fault and not Arch's. Secondly, after dealing with this a couple of times, you'd have acquired some excellent skills in troubleshooting.
highly mutable
Traditional distros are basically equally mutable. So, Arch doesn't (necessarily) outdo e.g. Debian or Fedora in this regard.
It has its own repo too by the looks of it?
It does. But that's a thing with independent distros. Linux Mint is a derivative of Ubuntu. Which, itself is a derivative of Debian. Debian, however, is independent. Similarly, Arch isn't derived from anything else; hence, it's an independent distro.
The list of independent distros isn't huge or anything, but I suppose there are at least a couple of dozens of 'm.
As for the own repository part, both pkgs.org and repology.org feature some resources on that.
hardened
This is an important keyword but perhaps not sufficiently discussed. I'd reckon focusing on it will be pretty helpful.
So..., what is it you want? Is it
- A. Make a fortress out of a very decent starting point? To daily drive it afterwards*.
- Or B. Daily drive a fortress built by someone else?
- Or perhaps even C. Something else entirely?
By the rest of your post, I'd bet on B. Which, puts us into an interesting situation...
systemd free
Assuming^[To be honest, I don't see any reason to not grant them the benefit of doubt. As far as I can tell, their lists look complete.] DistroWatch does a decent job at tagging/categorizing, there are only a handful of distros that are both systemd-free and tagged with "security". Note that half of these don't survive it upon closer inspection, which leaves us with Alpine, HardenedBSD and OpenBSD.
If you're well-versed into hardened distros, you'll note the absence of Linux' finest in this category; namely Kicksecure and secureblue. Their absence is due to their (heavy) reliance on systemd for additional hardening.
Furthermore, note that DistroWatch doesn't mention how well the likes of Artix, Gentoo and Void (among others) would function as excellent starting points to build your own fortress from.
From the Linux-first vendors, I am only aware of Star Labs' StarLite. Their products are pretty good, though a bit price~y.
Thank you! This is actually very helpful! And we can definitely reverse some of their doing π. Below I will repeat the invoked commands and provide some context/explanation. So, without further ado.
sudo rpm-ostree kargs --append-if-missing=zswap.enabled=1
sudo rpm-ostree kargs --append-if-missing=zswap.max_pool_percent=25
sudo rpm-ostree kargs --append-if-missing=zswap.compressor=lz4
sudo rpm-ostree kargs --append-if-missing=systemd.zram=0
The commands found above were used to change the kernel arguments through rpm-ostree. You can still find these back with rpm-ostree kargs --editor. You can even outright remove them, then and there. It's also possible to literally revert those commands by invoking the following:
sudo rpm-ostree kargs --delete-if-present=zswap.enabled=1
sudo rpm-ostree kargs --delete-if-present=zswap.max_pool_percent=25
sudo rpm-ostree kargs --delete-if-present=zswap.compressor=lz4
sudo rpm-ostree kargs --delete-if-present=systemd.zram=0
sudo rpm-ostree initramfs --enable --arg=--add-drivers --arg=lz4
Unfortunately, I don't have any experience with this.
sudo swapoff -a
sudo rm -rf /var/swap
sudo semanage fcontext -a -t var_t "/var/swap(/.*)?"
sudo restorecon -Rv /var/swap
sudo btrfs filesystem mkswapfile --size 32G /var/swap/swapfile
sudo semanage fcontext -a -t swapfile_t "/var/swap/swapfile"
sudo restorecon -v /var/swap/swapfile
sudo swapon -a
Basically, the commands found literally above affect the contents of /var. As such, they're outside of the 'jurisdiction' of rpm-ostree. Reverting these is the same as on any other Linux system.
The following commands change the contents of /etc. As such, they're being tracked and can be reverted to their original states. Though, I'm not sure if it's possible to revert them back to their respective versions without those changes.
sudo sed -i '\|/var/swap/swapfile|d' /etc/fstab
I'll be honest with ya. I don't know what this one does π
. I have used sed in the past but wasn't able to decipher this one. FWIW, it tries to make some changes to /etc/fstab . And, if I'd have to make a guess, I think it deletes any lines that contain /var/swap/swapfile.
echo "/var/swap/swapfile none swap defaults,nofail 0 0" | sudo tee -a /etc/fstab
This added some text to /etc/fstab. To revert it, go to /etc/fstab, and remove /var/swap/swapfile none swap defaults,nofail 0 0
echo "vm.swappiness=120" | sudo tee /etc/sysctl.d/99-swappiness.conf
This created a file named 99-swappiness.conf and placed it to /etc/sysctl.d/. As such, a simple sudo rm -rf /etc/sysctl.d/99-swappiness.conf suffices.
sudo rpm-ostree install policycoreutils-python-utils
This was an optional command. If you did have to invoke it, then you should find policycoreutils-python-utils when invoking rpm-ostree status. It should be mentioned as a layered package.
To undo it, simply invoke rpm-ostree uninstall policycoreutils-python-utils.
Bazzite's messaging has merit, but we'd be making a mistake by regarding it as absolute. It makes more sense to take them as carefully written guide lines for a specific audience.
Furthermore. with all due respect, but OP's writing doesn't imply installing/managing software with rpm-ostree. Which, is actually the subject of the documentation entry you quoted. As such, I think you might have misunderstood them.
Youre breaking a core tenant of immutable distros by installing system level packages.
Finally, FWIW, I absolutely disagree with the above. The page you quoted from seems to agree with me on this: "Layering packages are mostly intended for system-level applications, libraries, and other dependencies."
I made some changes using
rpm-ostreerelated to zram and swap
Could you be more transparent and/or elaborate in this regard? Like, what did you actually do?
FWIW, I've been on Fedora Atomic since before Bazzite's existence, but I've never once considered using rpm-ostree to make changes to zram and swap. So, I'm a bit confused. To be clear, it's perfectly possible that what you did is 100% legit, but that it just happened to expose a gap in my knowledge.
I had assumed that, because I used
rpm-ostree, the changes would become part of the βtreeβ and I could rollback to the original settings. But when I went to look at Bazziteβs rollback tools, it seemed solely focused on rolling back to previous official releases, and I couldnβt find any reference to the specific changes I made.
Basically, while rpm-ostree does offer git-like control on your base system; hence, why it's so powerful to begin with. It does not keep more than two deployments around; at least, by default.
If you would like to keep around a specific deployment (for whatever reason), you can do so with the ostree admin pin <insert number> command. The git-like control also enables you to keep track of:
- the changes applied to
/etc; invokeostree admin config-diffto see what files have been added or modified since installation - layered packages; simply invoke
rpm-ostree status
Keeping track is cool and all, but its usefulness is in full display with powerful applications such as:
rpm-ostree reset; this basically removes all permutations. That is, two people on the same image, will have the identical base system after this. (Note that this still isn't as powerful as a factory reset. For that, refer to this issue tracker onbootc^[On that note,bootc's model is arguably better suited if you're just interested in finding back references to changes you made in the past. Granted,bootcoffers a hefty amount of freedom in how you'd approach this and might be overwhelming for now. FWIW, both Bazzite and this are products of this.].)
Finally, the git-like structure ensures actual reversibility. On most other systems, installing A -> installing B -> uninstalling A will yield a different state than just installing B. With rpm-ostree, the base system between the two will be identical.
For completeness' sake, I've used "base system" above to just mean the contents of /usr and /etc (and maybe some other subdirectories of /). Crucially, the contents of /var are not part of the "base system".
Fam, with all due respect, perhaps consider to not rely on the AUR at all for the time being. At least, until you're genuinely confident in your ability to assess PKGBUILDs.
Thanks! Much appreciated π!
LOL, indeed.
About the breaking part, kudos to you for doing a great job at maintaining Arch. But I assume/think^[Please feel free to push back on this.] most people don't enjoy 'babysitting'^[This term isn't meant derogatory or anything. But it's what comes up to me whenever I see how involved this is. By contrast, I actually do apply daily updates on my semi-rolling daily driver. But I never have to give it any thought. Heck, it even happens automatically.] their OS π .