As others have stated, reviving them through Linux should be a piece of cake.

However, how many is “a tonne”? This is important information for the community to provide recommendations on administrating those systems.

So you’re really butthurt, eh 😂. Don’t worry; I won’t initiate any further contact. Consider growing up though. Cheers.

Last year, this piece was written on it. And, based on an extremely small sample size (N=1), the takeaway was basically that the 1% lows (and the 0.1% lows) do seem to benefit on some games.

But, there are so many factors at play, it’s pretty hard to back up any claim of performance increase (or decrease). However, if you’ve got the time and you want to play around, then please feel free to benchmark the 1% lows (and 0.1% lows) of the games you play on different distros and come to your own conclusions.

Small nitpick; layering is technically only a thing on Fedora Atomic. Not all immutable distros subscribe to it.

First of all, I’d like to apologize if I misunderstood the situation. Communication only through text can be hard. And, in retrospect, I agree with you that I should have been more careful with my writing.

Secondly, please dismiss my last two replies. Especially the first is atrocious, while the second one was written under time pressure. Something that I should have not done to my fellow human being.

Thirdly, you’ve had another conversation with another user under this post. And I got most of what I wanted to get out of this conversation from that one already. And, I’d have to agree that that person was a lot more punctual and eloquent when wording their views. Thus, I understand why my writings might have felt as a downgrade by comparison.

Fourthly, thank you for your time. I appreciate it. And I wish you a great day.

Fifthly, there’s actually one thing that I really want to know 😅. But, I’ll not bring it up, unless you allow me.

Cheers.

I’m glad to be proven wrong.

Thank you for being more optimistic than I am.

😅. Alright, I’ll digest it for ya.

You said: “If rolling release causes the system to implode, doesn’t that make arch more user friendly?”

Which, if I’ll have to guess, is what you understand from the following sentences of mine:

• “But, did I understand you correctly, that you hint towards the curious observation that rolling distros in general are technically ‘immortal’ while point-release distros eventually implode on themselves?”
• “The inevitable implosion happens once every two years at worst.”

Which, are the only two instances I used the word. And, in both instances, it is pretty clear what I meant. I even just checked this with a LLM and it agrees with me on this.

However, the question you posed (i.e. “If rolling release causes the system to implode, doesn’t that make arch more user friendly?”) has many flaws within it:

• Like, if rolling release cause a system to implode (which I never said nor implied), then, because an implosion is clearly undesirable and thus not user friendly, Arch (as a rolling release distro) would also have been less user friendly (not more user friendly*).

So, what did you actually try to convey with that sentence? Did you make a mistake while formulating it? If so, what did you actually intend to say/ask?

Regarding me quoting myself; it’s pretty simple. I just want to ask you if you think that a distro with the following policy can be considered user friendly. And if so, could you explain why you think that’s the case? Policy:

“Note: It is imperative to keep up to date with changes in Arch Linux that require manual intervention before upgrading your system. Subscribe to the arch-announce mailing list or the recent news RSS feed. Alternatively, check the front page Arch news every time before you update.”

When I quoted the text found below, I wanted to ask you why you feel pacman is better than apt beyond the claimed robustness. I agree with you that I could (and perhaps should) be more explicit.

it’s package manager is just better than apt

You didn’t lay out “fault in my logic”

I meant the following parts of my previous writings:

I’m relatively new Linux user (just over two years now), so please bear with me. But, did I understand you correctly, that you hint towards the curious observation that rolling distros in general are technically ‘immortal’ while point-release distros eventually implode on themselves? If so, wouldn’t it be more correct to attribute this to the release model (i.e. point vs rolling) instead? Because, IIRC, this issue persists on openSUSE Leap, but doesn’t on openSUSE Tumbleweed. While both utilize zypper as their package manager.

But, if you noticed, I didn’t actually explicitly mention Arch’s install or its unopinionatedness as its downfall; which are indeed solved by its derivatives. The problem is with updates. At least on Debian and Ubuntu LTS, packages are (mostly) frozen and thus updates are in general non-existent and thus are not able to cause issues. The inevitable implosion happens once every two years at worst. Is that bad? Sure. But does it cause any trouble within those two years? Nope. And honestly, I don’t blame anyone that simply prefers to worry about updates once every two years instead of daily.

To make it easier for you:

• Is Debian (according to you) not robust because it breaks eventually?
• Do you acknowledge that this occurs beyond the Debian ecosystem?
• Do you acknowledge that this occurrence seems to be found on distros with point releases, but not on distros with rolling releases?
• Do you acknowledge that, therefore, blaming the package manager for this lack of robustness is perhaps an oversight?
• And do you acknowledge that, with openSUSE Tumbleweed (rolling release distro) and openSUSE Leap (point release distro), this is perhaps most evident. As both rely on zypper, but the former is basically ‘immortal’, while the latter will eventually succumb to some major release.
• Thus, do you acknowledge that, in fact, Debian’s lack of robustness can not justifiably be attributed (solely) to apt. Nor, can Arch’s (seemingly) superior robustness justifiably be attributed (solely) to pacman?
• And thus, do you acknowledge that, we can’t continue to make the claim of pacman’s robustness as the reasoning doesn’t hold any truth in retrospect?

Earlier, when I said

Then, I’d argue, if you really dislike reinstalling, then Arch scores better at that. But we don’t measure how user friendly a distro is on just a single metric.

IF we both understand with your earlier statement of “pacman is so much more robust than apt” that you meant that Arch installations survive longer than Debian installs (under optimal conditions). Then, we could translate this argument to; if you dislike reinstalling, then Arch scores better. But, then I proceeded, with “But we don’t measure how user friendly a distro is on just a single metric.”. I don’t think this sentence needs any explanation, but I can clarify if you feel like it. The reason why I said “single metric”, is because I assumed - with how you actually didn’t try to rebuke anything that I said in this comment of mine - that you also agreed with my points. This might be a wrong assumption. So please feel free to correct me on this.

I honestly suspect the main issue is related to either the opinionatedness of Ubuntu compared to Debian or the absence of Snap. Why do you think that Distrobox will help them with their choice?

I’m afraid that you won’t get an answer from OP. Based on the last couple of days, and OP’s many posts, we’ve noted that OP has only rarely answered questions. I don’t think it will be different this time.

So, while I can’t read their intentions, I will provide my thoughts.

OP is a newb. And has asked this community many different (but somehow related) questions.

OP was on Xubuntu, but experienced a problem. After they saw that the solution involved more steps than they’re willing to take, they instead opted to switch distros. After prompting the community for some input and inspiration, they decided to go for Debian with Xfce. However, they’ve experienced a bunch of things since that have made them second-guess their choice; Xubuntu was perhaps better at some things AND Linux Mint Xfce was actually the popular pick in their earlier community prompt.

So, in order to resolve their second-guessing, they intend to put them all to the test simultaneously though multi-boot before finalizing their decision.

But as far as I know, NVIDIA just supports enterprise distros.

I tried looking this up, but to no avail. Got any proof to back this up?

I didnt know that, but uBlue uses random OCI container builds by Fedora for all their stuff, that Fedora doesnt even officially use themselves.

I don’t know how it is currently. However, initially, images were provided by maintainers affiliated to Fedora. Could you provide a link in which your current understanding is better described/explained?

Thank you for contributing so that people don’t misunderstand!

I didnt know they have testing images, but makesbsense in their flagship variants.

You can verify it yourself from here.

Though, with all that’s mentioned above; do you still think Pop!_OS is better than Bazzite for Nvidia?

I think we’re misunderstanding eachother. So perhaps consider to outline if you agree with the following:

• uBlue has some systems in place that enable it to detect some breakages.
• uBlue’s pipeline is such to not ship you the detected breakages.
• After a method has been found to fix a breakage (or other issues), uBlue’s maintainers implement these fixes and then, the very next update, the users will receive an image that contains both the updated package and the fixes required for it to not cause problems. Heck, the user didn’t know anything was up in the first place. They didn’t notice a thing*.
• uBlue’s issue/problem detect systems are not absolute; things might slip through.
• However, Nvidia drivers will not cause breakage that will make you shiver in fear.
• uBlue does not fix it on your device. They fix the image and that fixed image will deliver you the fix built-in; so manual intervention are a thing of the past (except for edge cases).
• Their pipeline does not require nor does it detect (through telemetry or whatsoever) the breakage on the device of the user. Heck, as implied earlier, most breakages are detected, prevented from shipping broken, fixed, ship the fixed one before any end user is disturbed by it.
• uBlue is not a Stable system (i.e. it does not freeze packages (apart from security updates) until the next major release). So yes, you receive updates all the time.
• Not being tied to legal restrictions is cool. However, a lot of derivatives do this. So this can’t be its unique selling point.
• uBlue is not entirely free. Its maintainers do pay money for providing some of their services (as has been mentioned by Jorge).
• Some of their images do have testing branch; even Bazzite has.

Hahaha. Okay, yeah you laid it out brilliantly. Thank you for that! I can’t but agree with you then. I hope some Fedora employee sees this @joojmachine@lemmy.ml. Apologies for the ping*.

From the FAQ of Qubes OS (i.e. most secure desktop OS for general use):

“Why does Qubes use Xen instead of KVM or some other hypervisor?”

“In short: we believe the Xen architecture allows for the creation of more secure systems (i.e. with a much smaller TCB, which translates to a smaller attack surface). We discuss this in much greater depth in our Architecture Specification document.”

Great observation on Ubuntu and drawing parallels to Red Hat.

Actually I’m going to accuse Fedora of doing this too. You kind of have to know “Fedora WorkStation” is the Gnome version which is considered the default, “Spins” are the versions with other DEs, and “Silverblue” is the immutable file system version.

I’m mixed on this. It’s a fact that Fedora Workstation receives the most love from Fedora. And while it’s undeniable that they also put a lot of effort into all DEs that they support, none come as polished as WorkStation. One might argue that the way different installations are found on Linux Mint’s website isn’t that different to what Fedora does on theirs.

If rolling release causes the system to implode, doesn’t that make arch more user friendly?

Actually my point was that point release distro seemingly implode at some point 😅. But, I’ll assume that you meant point release here. Then, I’d argue, if you really dislike reinstalling, then Arch scores better at that. But we don’t measure how user friendly a distro is on just a single metric. That doesn’t make sense.

I’ll quote the main body in which my argument against Arch being user friendly has been laid out. I hope you’ll respond this time:

I do wonder what your definition of user friendly is. Cuz I can’t fathom how you can think that a distro that subscribes to what’s quoted below can (by any stretch of the imagination) be considered user friendly.

“Note: It is imperative to keep up to date with changes in Arch Linux that require manual intervention before upgrading your system. Subscribe to the arch-announce mailing list or the recent news RSS feed. Alternatively, check the front page Arch news every time before you update.”

Which simple means that you have to check if you can update before you actually perform an update. That’s just wild.

And you know what’s most curious about this, we’ve actually solved (within Linux) issues related to updating your system. You read that correct, it’s a solved problem. And I hope that you’ll benefit from these advancements even if you continue to use Arch.

Btw, please don’t come to me with packages that automatically pop up in terminal to inform you about manual intervention. On my system, updates occur automatically in the background and with some black magic shenanigans (or just great engineering) it ‘fixes’ itself without requiring any manual intervention from me. That pop-up message in terminal can’t compete with that.

it’s package manager is just better than apt

Earlier you called it more robust. I laid out the fault in your logic. But you didn’t care to react to it… Regardless, if it’s only speed that makes you think that, then please just say so.

But there is no automatic repair voodoo anywhere, on any distro. That driver is proprietary, only NVIDIA can fix it.

Consider to revisit this, cuz this is basically (at least for me) most of uBlue’s schtick:

“No more building drivers on your laptop, dealing with signing, akmods, third party repo conflicts, or any of that. We’ve fully automated it so that if there’s an issue, we fix it in GitHub, for everyone.”

And the way it’s setup, is so that you don’t get the broken update ever on your device in the first place.

So, contrary to what you might expect, this black magic (or just excellent engineering) somehow does exist.

The answer found here should give my general thoughts.

But, with embedded dev, I’d argue that both Aurora and Bluefin (with their respective DX: (i.e. development friendly) variants) should make more sense.

Thank you for your reply!

If you’ve ever “held broken packages” you’ll know what I mean by robust. I’ve had an entire distro upgrade break in Debian, it seems with a Debian system, eventually, you’re wiping and reinstalling because something broke. I have had this happen to every single Debian system I’ve installed since the gnome2 days.

I’m relatively new Linux user (just over two years now), so please bear with me. But, did I understand you correctly, that you hint towards the curious observation that rolling distros in general are technically ‘immortal’ while point-release distros eventually implode on themselves? If so, wouldn’t it be more correct to attribute this to the release model (i.e. point vs rolling) instead? Because, IIRC, this issue persists on openSUSE Leap, but doesn’t on openSUSE Tumbleweed. While both utilize zypper as their package manager.

When I talk about Debian and arch, I’m also talking of their downstream distros. So Mint would be a desktop oriented downstream distro for Debian. It inherits all the problems that come along with Debian, just as Manjaro or EndeavorOS would inherit anything that comes along with running arch. This is all in addition to any issues caused by those distros themselves.

But, if you noticed, I didn’t actually explicitly mention Arch’s install or its unopinionatedness as its downfall; which are indeed solved by its derivatives. The problem is with updates. At least on Debian and Ubuntu LTS, packages are (mostly) frozen and thus updates are in general non-existent and thus are not able to cause issues. The inevitable implosion happens once every two years at worst. Is that bad? Sure. But does it cause any trouble within those two years? Nope. And honestly, I don’t blame anyone that simply prefers to worry about updates once every two years instead of daily.

I wouldn’t recommend any new person install arch, in fact I don’t even do it because I get tired of the installation process. I’d recommend someone install EndeavorOS, which is just arch without the installation issues. If someone wants a Debian based system, I’ll recommend Linux Mint, but if you don’t already know why you want a Debian based system, if you’re just looking for a desktop that works, I’ll recommend EndeavorOS because the underlying Arch system is just IMO better than a Debian system.

Once again, installation is not the problem. I would like to kindly remind you that I haven’t even mentioned it once in my previous comment.

But they rely on rpmfusion, an external repo packaging the proprietary NVIDIA stuff for Fedora. The repo is not supported by Fedora, and the drivers cannot be fixed by anyone.

Not sure what you’re trying to say here. Would you mind elaborating? FWIW, Bazzite’s model (by default) allows automatic fixes to be applied to a broken driver without requiring any manual intervention from its user.