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.)
Is your distro Pu-239 going to be The Bomb?
Big question: Will it condone LLM generated / “assisted” programming?
CachyOS automatically does bootable BTRFS snapshots with every update. I don’t really see any advantage of atomic distros over this.
Can’t speak much about OP’s distro or CachyOS, but I can talk about how Fedora Atomic differs from simply doing btrfs backups before every update.
First, updates are not the only thing that can modify the base system. Installing packages, installing plugins or extensions, manual user modifications, etc, can all end up bricking the system. Fedora Atomic makes the base system immutable so that the only way of making modifications is via rpm-ostree, which ensures that you always have a way to rollback.
Second, one of the issues with traditional update mechanisms is that over time, updates might not do proper clean-up and leave artifacts. This is a harder problem than people realize, because users can have all sorts of permutations of packages and versions installed, and the update mechanism has to account for all of them. Over time, and many updates, a system can accumulate tons of small update errors and finally fall over. I’ve had this issue myself and heard of this issue from multiple sources. Fedora Atomic solves this by ensuring that every update is like a complete re-install.
Third, since every Fedora Atomic user uses the same base system as their distro maintainers, they can be sure that their base system is well tested. Bugs are more reproducible, and thus can be fixed faster. None of those “works on my system, you’re on your own” issues.
Fourth, this one isn’t a benefit to the user but the community. Fedora Atomic (and universal blue) distros are easy to fork. This is why there are so many flavors now. Bluefin, Aurora, Bazzite, Secureblue, Wayblue, etc. Instead of one generic distro with a huge community relying on a few maintainers, like Fedora used to have, now you have smaller specialized communities with their own leaders, and users can choose which community they align with more. And you can even switch communities, since rpm-ostree allows you to “rebase” to a different distro (eg Aurora -> Bazzite).
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!
Not personally interested,but a big question with something like this is how much time you have and how do you plan to maintain it in the long term? Don’t want to dissuade you, but I really don’t know if we need yet another distribution based on arch.
Yeah I get you, recently with everyone vibe-coding their stuff, there have been a lot of useless distros, but I really feel like I’m onto something useful. I’m self employed and basically temporarily took on less orders so I can work on this full-time until I get the first version out and actual full on development turns into maintaining and improving. I can definitely manage it and actually look forward to it as it’s super fun to me! Also I used today to make some changes as you can read in the comment I just left.
deleted by creator
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.
Didn’t know about RakuOS, nice! “RakuOS, but Arch” is exactly how Pu-239 sounds like, and I like it 😄
I find both projects very interesting too. I see some distro hopping incoming… Well, least try it out on my secondary device.
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!
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?
You’re doing something very wrong if Debian keeps breaking things for you.
I didn’t say “it suddenly breaks”. I said I have more issues with it, which is decided different from “it just works”, which has been my experience on CachyOS. Specifically I mean issues with installing (up to date) software, or using software that has requirements that I just can’t install the required version cause the repo has a version from 3+ years ago. Not everything has to be “bleeding edge”, but being so stable that everything is utterly outdated is also a kind of unstable.
Sometimes this goes so far that the “stable” version shipped by debian is already unsupported upstream with all the security implications that entails (I had that once with PHP, I think).
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.
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.
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)
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.
You’re coming into a discussion about two different linux release models misunderstanding both their established terminology and their purposes, and then claiming one of them is “bad” because you tried to use Debian in a way it wasn’t intended to be used.
I didn’t claim anything is bad, anywhere.
Also I didn’t “try to use Debian in a way it wasn’t inteded to be used”. I am using debian on 90% of my servers/vms/containers to this day. Have been for literally decades. To give a specific example: I was running a nextcloud, which required PHP, and wanted to update that. The newer version reuqired a higher PHP version, because the currently installed PHP version was EoL and not supported anymore (by PHP maintainers or Nextcloud). So updating required removing the debian-provided PHP version and installing one from other sources (external repo or compile from source), which honestly defeats the point of a “stable” distribution if the software provided is EoL, doesn’t it?
And to be clear this is just one example I can specifically remember. The “issues” I encouter when using debian are usually of that general type. And to be clear, that’s mostly the point of using it on a server, where I use it, but even there it sometimes goes a bit too far.
And finally: I was originally arguing the semantics of calling debian stable and arch UNstable, which it is not. It is rolling, it might be bleeding edge. It’s also isn’t the same as having a stable and unstable release branch (within the same distro) when applying the label to the most stable release of different distros.
which honestly defeats the point of a “stable” distribution if the software provided is EoL, doesn’t it?
Again, the point of a stable release model is that its packaged software doesn’t have breaking changes for the lifetime of the release. Install something from those repos and it’s guaranteed to run in the same way for the full lifecycle while still getting minor and security updates. So if the software you’re externally layering on top of that suddenly requires new dependencies that you have to install externally too, and you don’t like that, that’s more a problem based on a misunderstanding of Debian than a problem with Debian.
It’s the way that word has been used for over 20 years.
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).
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.
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!
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.
Why github and not https://codeberg.org/?
Seconding that. I’ve just read through the website. Got interested. Then my eyes went to the top panel again finally, I’ve read “GitHub”, and my thoughts are “Huh? But this mismatches the rest of the page, especially with the AI stance and some push for simplicity combined with competence.”. Went back here to write about it.
/me a ~10 year old ArchLinux user (using Arch for this long, my Earth age nobody cares about including me anyway). I’m thinking if I wanna actually try this for real. I currently have manually written packages that define the OS dependencies and configuration, and I don’t like the mutability of everything, the default update handling of no-longer-dependencies, the
.pacnew… I still like and appreciate Arch obviously, but the pain points connect.Ah, and please add the stock
-Suyprocess to the pain points. It alters the local database even when downloads haven’t fully finished yet (as it is out-of-the-box at least), so if downloads fail mid-ways you have to remember to not dare installing any particular package before a full upgrade still. If you forget, you’re toast.
Man, good question, I’m still torn about this. Initially I was forced to use GitHub specifically from my university, now it kind of stuck. I haven’t pushed much yet anyway so I might even make the switch.
Well, you could use Github’s free (as in beer) infrastructure to host artifacts, which means they’ll have to pay (as a company) instead of codeberg (as a non-profit). The issues and development can be hosted on codeberg. Kind of like how the Linux Kernel does it, Github only being a mirror, not an endorsement.
Hmm, I will definitely take your suggestion to heart. For now I’ll focus on actually getting the first ISO ready to be rolled out, after that I’ll take a deeper look into it, thank you!
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.
Is arch really this hard? I’ve been on it for 3 years with practically no issues. It “just works”.
wdym about hard? this is to achieve immutability plus kernel efficiency improvements.
I just see all these derivatives and everyone saying “to make arch more accessible and easy”. I just dont get it I guess.
this is something else i guess, it’s not about UX but about how the system works kind of. i’m not exactly sure about how silverblue does it but think of it this way. not everything in your system needs to be mutable (your home dir does) so those parts are isolated and made immutable, the user cannot modify them, this helps to keep a more stable system. they can be changed when the system updates them , but it’s more like they are replaced and a one image is built rather than a modification if you will.
Jup, you got it right, the “easier and accessible” part just arises as a byproduct of making Arch atomic. By nature this will make the install pre-configured and thus easier to get into even if this isn’t even the goal but rather just stability and peace of mind.
Nope, I don’t find it that hard either, but we are in a bubble here. The average “which distro should I pick” post suggests SteamOS but only with a full AMD system and when people suggest CachyOS, it’s met with “bUt YOu cAN’t sUgGesT aN ArcH bASeD diStrO tO a BegInNer” so I hope to bridge the gap for people that are waiting for a general-purpose SteamOS release PLUS the CachyOS performance on top. Also some distros do offer people to add the CachyOS repos, which is however forbidden due to their repo policy. Yes it is open source, but they understandably don’t want their servers and mirrors to be used by people not even running their distro. As I will compile the kernels for now, ALL packages in the future and host them myself, I actually comply with their repo policy as one of the few distros.
Yeah you shouldn’t recommend Arch to a beginner.
If you actually interacted with beginners you’d immediately understand why people choose mint or Ubuntu for that purpose instead.
It used to have more problems. As others have noted, there is always the possibility of updates breaking something with the rolling release model. But for the last few years, it has been stable enough that a user knowledgeable and willing to read a log and modify a configuration file has likely been fine.
As has been noted in the ArchWiki that is expected to be read by users, one should always check for package-related news before upgrading their Arch system. This is because package changes and breakages that require user intervention do occur, and ignoring them can sometimes leave a broken system. Arch isn’t really hard after getting over the bootstrap hurdle, but simply requires more upkeep effort than most point release distros would.
Yeah I just have arch news as my homepage. Haven’t seen a breaking change that applies to normal gaming desktop usage in a while.
I think the biggest one in recent (past year) would have been the upgrade tree to nvidia-open, which would break 10-series and older support without changing package on affected systems. Definitely a lot of the more recent breakages are not large-scale problems, but they do still exist.
Why the name? I find distros with these names that are hard to say annoying to speak about, so I would suggest better name. Something short, catchy and easy to say for people with different languages. But don’t make it too general either so that it is also easy to search for.
Second comment because I just remembered: my initial idea was to simply call it Arch-Atomic, but just the fact of being atomic alone already would violate their trademark policy, which is why I went with my favorite isotope!
Yeah that name would suck 😀 As I wrote in previous answer, I really like Plutonium just like that.
Okay, I’m just going to reply to this one really quick before sleeping, my intention was for this to be the short version of Plutonium-239 so it matches better with the logo. I kind of hope for this to be colloquially refered to as just Plutonium, but that itself as a name sounded boring. You are right to point it out and I agree, it was a placeholder at first however that name eventually grew on me too much and the domain is already purchased haha
English speakers will think your distro stinks based on that name.
Aha, I get it. And I like that its kinda nerdy. I dont think majority of the people will get it though. Just Plutonium would be fine, sounds actually real good and I think searching for plutonium os should be distinct enough (given the fact plutonium is not an element of everyday life). However if you still insist on the shorthand, what I saw people do, have a paragraph explaining what the shortcut means and how to call the os. Something like “the p-239 stands for plutonium and that is what we call the os - Plutonium” or variant of that. Maybe have it on the homepage even as a part of some baner or simly as second or third element under header. And it can also link to the full story (that it was a codename at first…)
Hard to google though…
my intention was for this to be the short version of Plutonium-239 so it matches better with the logo. I kind of hope for this to be colloquially refered to as just Plutonium
My first thought when I saw your domain was not plutonium-239, it was P U 239, your website doesn’t reference plutonium until 8-9 paragraphs in.
Oh shit, you are right, I had it in my head to include the written out name in the first paragraph but kinda just forgot about it, thank you for pointing it out!!
Might I suggest Hesperium (earlier alternate name recommended by Fermi) or Plutium (a name Seaborg considered before deciding plutonium sounded better)?
Name could be Plutium, domain could be pu-239? @yxc999@lemmy.ml
Hmm, in my head I’m pretty set on Plutonium already, but I will take your advice and make the written out name more prominently visible so people will hopefully develop the habit of refering to it as “Plutonium”. If I should decide to have multiple spins on it, I’ll remember that Hesperium and such are cool alternate names, thank you for the ideas!
I love the idea, apart from “user applications are flatpaks”. I’d love to install non flatpak applications.
Plus points for my perceived lack of AI sloppiness.
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!
Omg yass. I’ll install this for sure.
I do plan to have a way too “unlock” it so you can for example enter a console command to be able to install packages like vanilla Arch but they still get applied atomically. I dislike Flatpaks myself so for me to use it on my main workstation, I’d have to be able to never touch a flatpak as well haha. For the average user that wants a “just works” distro like SteamOS but also some of the speed-up from CachyOS, Flatpaks seem like the most intuitive decision however.
Sounds great and exactly how I’d want it! So you basically have a base set of packages which are guaranteed to be stable, but you can still layer stuff on top?
Maybe you can also have multiple boot entries like a “safe mode” or a way to boot different combinations of packages.
I’d really like to have a somewhat declarative way to manage the software on my laptop and desktop both, the latter being a superset as I need gaming and LLM related software there (which I don’t need on my laptop).
I’ll certainly play around with your distro as soon as it’s out. Don’t know when though, as I need to take a few precautions to not fuck up my data first 😅
Currently you can select either KDE Plasma or Gnome in the calamares installer and other than that it just slaps Intel and AMD CPU firmware on it along with Intel, AMD and NVIDIA drivers so yeah, a boated but working list of packages. I thought about making a quick tick-box solution but decided to just make it work right in the first place and get a proper hardware-detection going. The first version will be shipped with just that, for 0.0.2 to be released, I want it to have that kind of developer access where you can add or remove the packages you want, just like on a pre-configured Arch distro. That’s the first priotity after the initial release so thank you for your interest and I hope you will be happy with it in the future!!
Why didn’t you call it Starchy?
I both hate this so much and respect the creativity lmao
Same, same. Please don’t call it Starchy. Hope your distro has a longer half-life than Omarchy (pun intended) 😅
Although unintuitiv, judging by the name, hopefully less toxic too!
