As the title and the website say, I’m currently making a distro with the goal that you don’t have to compromise between ease of use + safety and bleeding-edge + performance optimizations.
As I will likely be able to publish the 0.0.1 source code to the GitHub link and the ISO to the website sometime next week, I would like people to be aware of my project so I can have some feedback for further improvements when I release the first version. I have not posted this anywhere else yet, as I value the opinion of this community more than Reddit or whatever.
If you have any questions or any criticism, please voice it, I would love to hear it, good or bad, in the end I want to make a proper OS. (I’ll go to bed now so expect replies to take a few hours from posting.)
Second and last question: Will it support other init systems other than systemd?
Honestly, I haven’t even thought about that yet. I don’t see anything speaking against using other init systems at first glance, but that’s gonna be very low on my future priorities rn. If I should have some spare time after checking every mayor box then sure, I don’t mind systemd but I’m also not a huge fan.
Big question: Will it condone LLM generated / “assisted” programming?
BASED
Is your distro Pu-239 going to be The Bomb?
HiroshimaOSMay as well be called TrumpOS, we are so dead
UPDATE
I took your suggestions to heart and updated the website to reflect the changes I implemented today. The big change is that I found a way to keep pacman fully intact and functioning, but make it apply the changes atomically. So now this isn’t just limited to Flatpaks, but LITERALLY Arch Linux but made atomic.
The new intro reads:
“Plutonium-239 is Arch Linux, made atomic. It combines the rolling release model of Arch Linux with an atomically updated root filesystem inspired by SteamOS on top of the heavily optimized CachyOS performance kernel. Unlike immutable distributions that lock you out of the native package manager and force you into sandboxes, Pu-239 keeps the core Arch experience intact. You still get the full power of pacman and the official Arch repositories, with the peace of mind of an unbreakable safety net underneath.”
For more information, please check out the updated “How it works” section. Thank you all a lot for the feedback!
I have no idea what people keep talking about when they say Arch/CachyOS is “unstable”. I have had so many more issues with running Debian (usually on servers) over the years. Since I swapped my desktop to CachyOS over a year ago, I have basically no issues at all. Just one very minor thing that fixed itself after a few days (bug in kde on new version released). For like 15 months of use, that’s spectacular compared to any other system I’ve ever used (especially including Debian and of course Windows, obviously).
What exactly is the goal? How do you make “no issues” and “it just works” more stable?
Stable vs Unstable does not mean anything to do with bugginess or prone to breakage.
It literally just means package version changes.
Stable meaning packages update slowly and only minor versions or security.
Unstable means packages update frequently including major versions
Inherently rolling releases are unstable.
My personal experience too is that Arch has been the best distro for lack of bugs and issues on my machines than Fedora or Debian etc.
This is why we should call it “bleeding edge” rather than “unstable” it’s a much more accurate name and it exemplifies the advantages (albeit leaving out the (minor) disadvantages)
Stable vs Unstable does not mean anything to do with bugginess or prone to breakage
It would be great if that’s how the words were actually used, but in most discussions I’ve seen it is certainly not the case. Also, when talking to new users, they are supposed to magically understand and know the word is used in a niche way in this context? It certainly won’t be what they take from it when hearing or reading it.
Unstable means packages update frequently including major versions
That’s what we have rolling or bleeding edge for. Sure, unstable can mean that when used within the same project/context. So having different releases be stable and unstable for the same thing, but across projects/distros that’s just confusing, especially for new people. Yes I’m aware of the historic reasons and the roots in software development, but I’d argue it isn’t helpful to convey the practical reality of the differences.
I don’t disagree that it causes confusion and that people conflate the two meanings especially for those unaware of what it is supposed to mean.
And inherently as well being an unstable distro as far as package updates goes likely leads to it being “unstable” in day to day use as far as bugs etc obviously goes hand in hand which further conflates the meaning.
I’m completely on your side, I have NEVER had less issues with an OS ever since running Arch and/or CachyOS, however issues could arise and that is enough for the usual Reddit dickhead to talk someone who’s asking for their first distro out of using anything Arch based. I’m tired of hearing these fucking “no you can’t recommend CachyOS, a new user should not touch Arch”, “CachyOS will break three times within your first week of using it”, “it has the AUR so you will contract HIV instantly by using it”, I just can’t hear it anymore which is why I want to provide people with an option that still has them on an Arch based distro but with added peace of mind and speed optimizations out of the box. You know, that’s the thing, I personally find Arch easy and intuitive and don’t get where people get the idea that it breaks all the time from, but that IS the perception however.
I have no idea what people keep talking about when they say Arch/CachyOS is “unstable”.
a) stable in the sense of not changing, or more specific not changing dramatically the user experience and not breaking compatibility, so you can rely on being the same, and b) stable in the sense of not breaking by bugs and issues. Those are two different topics sharing the same wording of stable/unstable. It’s a similar issue of the word “Free”, which could mean either Open Source or no cost in money.
Archlinux is unstable, in the sense that it changes frequently, without warning for most of the time, and this can break compatibility or user experience. Compare the other extreme Debian, which is very stable.
Compare the other extreme Debian, which is very stable.
In the sense that is unchanging, sure. But that’s one hell of a bad word to describe that in this context. In my experience the incompatibilities caused by only ancient versions of things available in the repo of even a newly released Debian are not helpful. Stable wouldn’t be the word I choose to describe the situation, or the fiddling and tinkering that results from that. Often having to go outside of the repo to solve, defeating the whole point of said repo.
Arch in my limited experience is much more stable, in the sense of “just works” and always having up to date software. If I want to use something, I can just install it (from the repo), the chance of it not being the current release are slim.
The word stable for describing unchanged is a common way of doing so. Especially to differentiate them from their development or experimental versions. That contributes to confusion and disagreements with the other meaning of the word. Unfortunately this word is common usage in both cases. In example Archlinux as a rolling release is unstable by definition. It does not mean its unstable in sense of issues, however depending on the user and use case it can be unstable a lot (or stable a lot).
It’s the way that word has been used for over 20 years.
Very interesting approach, please keep us posted and best of luck!
Edit: just thought, have you ever heard of RakuOS ? They seem to have similar ideas, about the unlocking while still atomic.
Check out the comment I just left, I implemented a solution that pacman is now completely usable so it’s literally just vanilla Arch but atomic instead of being Flatpak-only!
This is very cool! I like the idea of atomic distros although I haven’t really gotten into them much, if you keep on working on this project I might join it.
Question: I’m a bit confused about the package management system you talked about. Flatpaks for user level packages? What about the official arch repo and the AUR? I know other atomic distro’s don’t really work with traditional package managers, what does this mean for Pu-239? If there’s no AUR then there is no Arch Linux at least for me.
Also that name could probably do with some work lol. Maybe work on a shorthand way of spelling it and a better way to pronounce it? I’m not sure.
Thank you a lot for your interest! So as I pointed out in the other comments, out of the box and for the 0.0.1 release it’s intended to keep the system itself atomically updated through pacman and the user is advised to use flatpaks to install his applications. This is the most user friendly way of going about it, however I’m absolutely on your side and wouldn’t use it that way myself. 0.0.2 will have a way to “unlock” it so you can use the distro like vanilla Arch BUT you get peace of mind from knowing that you have a failsafe way of knowing the system will not break.
For the name, I did want Arch-Atomic at first but noticed this would violate the Arch Linux trademark policy and just went with my favorite isotope as a placeholder that unfortunately grew onto me. I will get off the couch now and edit the website so it’s apparent that Pu-239 is just the shorthand and people will refer to it as Plutonium-239 or just plain Plutonium in the future!
Thanks that does alleviate my concerns, I do like the name Plutonium or Plutonium-os.
Check out the comment I just left, I implemented a solution that pacman is now completely usable so it’s literally just vanilla Arch but atomic instead of being Flatpak-only!
This is awesome, thanks!
deleted by creator
Why ostree instead of bootc?
My initial idea was to just literally reverse-engineer the way SteamOS does it but when I saw what a mess this was I looked at a few other distros and how Fedora Silverblue used ostree seemed the most intuitive for me to program so yeah, that’s pretty much the reason haha. Are you just asking for clarification or do you think bootc has some advantages that you care to explain? Now would be the perfect time as the only machines running this are my ThinkPad, ThinkCentre and two friends on their spare laptops.
Very interesting, I’ll take a deeper look at that tomorrow, thank you!
I’m not a dev, but bootc sounds like the way forward. Like, it has ostree baked in, so you get all of it’s benefits without having to deal with the drawbacks.
On top of that, bootc is more distro agnostic. So, ideal for an Arch base. And most of all, your distro would be contributing to the community for being a bootc arch reference.
deleted by creator
So don’t you think you’ve come full circle and invented Bazzite again?
Haha, good thing to point out, however my plan is to make the second release able to be “unlocked” so you can pretty much treat it like vanilla Arch Linux but with a failsafe atomic way of the updates being applied. Being immutable is just the default configuration. Think of it more like Arch-Atomic but I couldn’t choose that name due to their trademark policy.
That’s an interesting idea, but if you make Arch’s root read only you’re leaving behind pacman/AUR (and to a good extent the Arch wiki) which are usually the main advantages of Arch based distros.
SteamOS solves the stability issue by providing runtimes for games, I didn’t read anything there about anything similar on your distro. Correct me if I’m wrong, but it seems you’re not solving the stability issue, or in other words you will still be unstable as this will be a rolling release. In short I don’t see what would be the advantage of this over base Arch + Snapper (or timeshift).
In that regard, how is this different from Bazzite? I know it will be a different kernel and package versions but in principle the philosophy seems to be exactly the same, and I don’t expect the kernel/packages to be that different either.
Check out the comment I just left, I implemented a solution that pacman is now completely usable so it’s literally just vanilla Arch but atomic instead of being Flatpak-only!
Interesting, how are you dealing with pacnew/pacsave files? From your explanation it seems that they would go into the read only filesystem and would need to be resolved manually and preserved there until some old version cleanup is ran.
And while I find the idea of a writable overlay filesystem for the /etc fascinating, I think that could have issues with some rollbacks and backwards incompatible config changes.
At the end of the day seems like a fascinating project, but I wonder if Arch+snapper wouldn’t be better overall.
i recently thought of exactly this but with nixos instead fedora silverblue. sounds very interesting!
Just an fyi you can basically get the full steamOS frontend as a session pretty dang easy with gamescope. I’m not talking just normal big picture mode either, like just the normal steamOS gaming front end.
I have it setup with fedora 44 kde right now for when I’m using my TV with my PC across the room.
The frontend isn’t even the goal, I won’t even be adding this at all unless it’s an often requested feature. Currently you can select KDE Plasma or Gnome during your install and both ship pretry much vanilla except for the distro’s logo and fastfetch. It’s intended to behave like SteamOS from a back-end perspective for lack of a better word!
IIRC the CachyOS optimizations were basically a rounding error. I’m thinking of just switching my gaming PC to Fedora (and switching my Fedora Laptop to OpenSUSE maybe).
Honestly, for the packages I do agree. You are not going to notice if your damn font is compiled with v3 flags or not lmao. The kernels however do apply a meaningful improvement, even if it’s just in general desktop use, you DO notice the jump from 250Hz to 1000Hz. Currently I’ll just ship the regular linux-cachyos kernel with the EEVDF scheduler which is more general purpose, but if you select BORE for gaming or (I forgot the name) for throughput, it becomes even more apparent. I get almost a minute shaved off compiling the kernels when I use a good kernel!
