Ah, I get what you mean now by inflammatory statements
Actually, it wasn't me that said that 😅. I do find it in jrgd's reply, though.
Though interestingly, I didn’t feel my comment was very inflammatory and it got downvoted too. 😅
For the record, I also didn't downvote your comment 😜. Though, looking at how well-received my previous reply has been, I can't ignore the possibility that peeps that agreed with what I said also chose to downvote your comment.
I was looking at it more from just a standpoint of systemd itself
Sorry, I don't think I completely understood you here.
just looking at it from the standpoint that fedora and rhel can tend to be industry leaders for change.
I absolutely agree with you that Fedora and Red Hat are very effective agents of change. So yes, if they would get behind an alternative for systemd, then that would definitely get traction.
if RHEL and Ubuntu together made
Has something like this ever happened in the past? I can't recollect a collaboration of sorts between these two entities. If anything, they seem to be at odds with eachother: Mir vs Wayland, Snap vs Flatpak and even Upstart vs systemd. Though, at least so far, Red Hat holds an impressive winning track record.
I think we would see that move downstream.
Absolutely. But, and this is my inner-systemd-skeptic talking, systemd is ridiculously intertwined with the current Linux landscape and often times new updates even show a glimpse of how much more intermingling we'll get in the future. I hope we'll eventually get something to systemd like what PipeWire has been to PulseAudio. That's why development into alternatives like dinit and s6 is of utmost importance.
As far as my use of the term bloated, I’m looking at it strictly from a standpoint for the amount of code that goes into the system.
Suckless it is 😜. It's a fine definition. Thank you for that. But, I got to ask, where is the line drawn? Like, the Linux kernel, by virtue of being monolithic, has to be bloated as well. Right? So, if that's the case, is somehow the kernel's bloat okay while bloat is unaccepted for the system and service manager? If so, why? I'm genuinely curious.
The more code you have, the more entries for security risks.
Sure~ish. Deep discussion. I'm fine with giving this to ya.
I’m not saying that there’s anything that’s particularly better out there right now
I suppose some peeps will enjoy themselves with what's out there. Do you happen to use an alternative on a daily-basis?
but I think we should always be looking for alternatives regardless of what your views are for the people that created the code. KISS philosophy, basically. That and being open to change to avoid stagnation.
Wholeheartedly agree 😊.
😅. I'll try my best 😜.
It is correct that the contents of
/
is immutable at runtime aside from/var
and/etc
. However, note that a lot of folders like/home
and/opt
are actually found in/var
in response. This is later 'fixed' with symlinks and whatnot. In effect, only the contents of/usr
(aside from/usr/share
) is off-limits (or 'actual'^[1]^ immutable).I believe my previous paragraph already answers this. But, to be even more elaborate, Fedora Atomic makes use of
libostree
(read: git for your OS). With this, only the pristine images are 'swapped' in-between updates (or rebases^[2]^). Your changes to the system are found in/var
,/etc
and in so-called 'layers' only and are not swapped out. Some of these changes are kept track of^[3]^, but most of them reside in/var
and will not be touched bylibostree
.Kinda. The important part is that changes are prevented for the sake of a functioning system. But the entire system doesn't have to be locked down in order to achieve this. This does mean that it's actually not that hard to break your system. Just
rm -rf /etc
and your system will probably fail to boot into the very next deployment. But, as Fedora Atomic keeps at least two deployments, you will still be able to access the previous deployment in which you tried to delete/etc
. So you're protected from accidental mishaps as long as you've got at least one working deployment. Thankfully, you can even pin working deployments with theostree admin pin
command. And..., just like that, the distro has basically become dummy-proof. I'm sure it's still possible to break the system, but you'd actually have to try 😉.So, in short, Fedora Atomic definitely intends to be a more robust system and succeeds. But, it does so while giving the user agency (and some responsibility).
I think everything of importance is mentioned in the docs. What is it exactly you want to know?
But that's just the first of seven "package formats" listed in the docs 😜. The other six will assure that your remaining needs are fulfilled.
This is obviously anecdotal, but Fedora Silverblue was the first distro that I used. I was a complete Linux newb. My coding background was also just a Python-course on Uni. But, somehow, in the very newbie-hostile environment back then (read: April 2022), I managed with Toolbx. So..., yeah..., I can't relate. Sorry*. You might be absolutely correct. But, as I said, I don't recognize this from my own experience. I wish I had a video-tutorial back then, though. Honestly, with the amount of hand-holding Bazzite and its docs provide, I believe a newbie should be absolutely fine.
It is even possible to overwrite this. Both in containerfile (requires creating own image) and on device (very hacky, not recommended).
Rebasing is the process by which a different image is selected to boot and run your system from. For example, with this, one can switch from Silverblue (GNOME) to Kinoite (KDE) without reinstallation. This can even be used to switch from a Fedora image to a Aurora/Bazzite/Bluefin/secureblue image.
These include the software you've installed through
rpm-ostree
(or soondnf
). We call these layered packages, based on the analogy that the packages aren't part of the image but are magically tacked on without you noticing anything finicky. It's quite magical. Besides that, any and all changes made to/etc
are also kept track of. The former you can see by invokingrpm-ostree status
, the latter by invokingostree admin config-diff
.