throwawayish @ throwawayish @lemmy.ml

Posts

6

Comments

220

Joined

2 yr. ago

Unfortunately, we live in the reality in which an affordable laptop with open source (yet modern) hardware simply doesn't exist. While the likes of Insurgo, NitroPad, NovaCustom, Purism, Star Labs, System76 and Tuxedo do commendable work on the software side of things; they still leave a lot to be desired as there is currently no laptop counterpart to what Raptor Computing Systems is able to achieve on the desktop.

Obviously I applaud Framework for what they've achieved for the "right to repair" and hope they'll at least pave the way for what's possible within the realm of open source hardware on laptops. Unfortunately, I'm a bit pessimistic as the way they've handled coreboot up till now has been far from desirable. But I'd love to be mistaken on this.

What exactly does uBlue do differently to Silverblue, which makes it easy to modify those parts?

Perhaps I should've been more precise/accurate. The images offered by uBlue are relatively vanilla but "batteries-included" images of Silverblue/Kinoite etc that include the essentials from RPM Fusion among others and ensure that your system continues to function optimally regardless of ongoing issues related to mesa/Nvidia or whatever. So by themselves, they don't do anything special necessarily in terms of modifiability except for having baked in functionality for receiving cosigned OCI images. Which is where the fun begins with the template provided by uBlue making it very easy to create your own custom cosigned OCI image that is modified to your liking and which is continuously pulled from whenever your system does a rpm-ostree update. As the changes don't happen at the client-level (read: your device), but instead before/during 'base-image initialization', one is able to apply changes to e.g the aforementioned /usr directory simply by creating those (modified or not) files in the github repo of their custom image. The linked template is far from exhaustive as one is able to customize it beyond that for which one could refer to the Bazzite or Bluefin images to see the possibilities.

Note that the template of uBlue is only possible because Silverblue/Kinoite etc supports it. So one is able to forego uBlue entirely and create their own image from scratch (as long as it satisifes some criteria). The beauty of (the template provided by) uBlue is that it enables every mortal to engage with that system as it has been made remarkably easy. Heck, I didn't have any prior experience with git or Containerfiles, but I was able to spin up my own image in like two hours or so.

Eg, how do I alter a file, say /etc/fstsb, in Fedora Silverblue, Nitrux, BlendOS etc?

I'll answer for Fedora Silverblue as it's the only one I'm confident about. So, by default, both /etc and /var are writable. Furthermore a lot of traditionally writable parts (like /home) are contained within /var as well. So say you'd want to edit /etc/fstab (which I've done in the past), then you'd literally do it the very same way you'd do it on non-'immutable' distros. So; copy (the content of) /etc/fstab, change whatever you want and sudo cp the modified file to /etc/fstab and you're done.

Perhaps interesting to point out is that, on Fedora Silverblue, all changes compared to the pristine copy of /etc (which is kept in /usr/etc) are being tracked and can even be accessed with ostree admin config-diff. Note that 'traditionally' the contents of /usr has been one of the harder parts to modify on Fedora Silverblue and I'd argue the average Joe should not engage with it as it's very easy to mess up. However, uBlue actually enables one to engage relatively easily with those harder to modify parts. And the amount of configurability it allows should definitely put anyone to shame that continues to posit that "immutable is inflexible".

Snapper offers basically the same functionality as Timeshift and is -to my knowledge- developed by openSUSE's team. So, while finding it therefore pre-configured on say openSUSE Tumbleweed makes sense, it's also the preferred solution on some other distros like Garuda Linux, Siduction and Spiral Linux.

Let's not forget to praise Snapper as well.

Due to legal reasons, Fedora is not able to distribute their distro with everything baked in to ensure (close to) maximum functionality out of the box. Notoriously, codecs required for (some of the) hardware acceleration and enabling the use of some multimedia file types are not delivered out of the box. Therefore, users are required to set those up themselves. Thankfully, RPM Fusion steps in to the rescue and makes it a lot easier for the end user to acquire these nonetheless.

But..., what if retroactively Fedora is forced to remove even more stuff and what if the solution is not directly available on RPM Fusion and thus requires (advanced) manual intervention in order to resolve the problem for the end user? Which actually happened just a few months ago with the mesa drivers*. Or what if a new Nvidia update causes troubles and you can't boot into your system? Which actually happens once every often if you don't pay attention and/or are unlucky. These are real problems that require real solutions; solutions which Fedora can't offer in the most elegant way in fear of the court (rightfully so).

This is where the "batteries included"" expression comes in. The aforementioned two problems were nonexistent on images provided by uBlue. Because problematic images are hold back by default automatically, which cautions them to resolve it ASAP and within a day (so far) the workaround gets built-in to the image and the end-user just gets the solution without ever noticing that something was wrong in the first place. Why? Because the end user's system never got the update without the workaround in the first place. An interaction unique as such within the Linux space is simply unheard of. I'm only aware of Vanillas OS that might be able to pull off something similar in the near future. Which is why I'm also very excited to see how it develops. Furthermore, as the end user you never had to go to the RPM fusion page in the first place to get/set up the earlier mentioned codecs as they were actually built-in to the image by default. That, is also part of the "batteries included" expression.

If you're interested, please consider checking out their documentation. Furthermore, please feel to inquire, if you so desire 😉 !

Hollow Knight is a masterpiece worth recommending. Furthermore, it satisfies most of your criteria. But you might need one of the better integrated GPUs to run it smoothly on your system.

Hades is another masterpiece worth recommending and perhaps satisfies even more of your criteria. Though, once again, it requires you to have one of the better integrated GPUs.

Yup, we've even been able to engage (to some extent) with it for the last couple of months.

It does require some know-how to set up, at least if you're unaware of uBlue; a community project that is set on offering said OCI images of Fedora Silverblue (batteries included) with different desktop environments (even those that aren't offered by Fedora (yet)). Bazzite, that has received some significant traction and exposure since it's very recent 1.0 image, is just one of the provided OCI images.

They even offer a very easy way for everyone to engage in building their own custom OCI image. I got mine spin up within two hours or so without knowing how git or containerfiles worked beforehand, it's that simple.

As other have already alluded to, any distro with a lightweight desktop environment should work on that laptop. However, we don't know if it would work out for you; simply for the fact that you haven't given any other information.

Hopefully bcachefs will be merged with 6.6.

Not sure which one you're talking about, but there are multiple copr repos that have very up to date packages.

Glad to be of help 💙 ! Feel free to inquire if you so desire 😉 .

And it’ll be segregated from the base system and from other containers, like toolbox installs are?

Exactly. It's even possible to segregate it beyond what Toolbx has been able to do (at least since the last time I checked) in that you can define another folder/directory as your HOME directory within the distrobox.

You can install Distrobox on Fedora (or any of the distros that support it), create a Debian distrobox on your Fedora install, and within the Debian distrobox you can use apt-get to install whichever Debian package you like. Or..., you could make an Arch distrobox and even install stuff from the AUR. Or really any package from any of your favorite distros as long as it's supported.

The one thing it does best is offering the capability to share the results so that people can refer/link to it while making an inquiry as such.

I likely would have encountered this as I try to take the approach of research, then do.

Props to you mate 👏 ! That's the way 😉 .

This is the first time I’ve ever posted for Linux help/or guidance.

Thankfully the community is very helpful in general, so you're in good company :blush: !

Searching forums has historically lead me to an answer close enough to resolve my not-so unique issue.

Yeah lol, we've all been there 🤣 .

A lot of negatives seem to come up around Oracle and Canonical being involved with SUSE and Ubuntu

Fedora also has connections to Red Hat, so yeah 😅. I didn't even know Oracle had anything going with SUSE before the recent 'alliance' of sorts in reaction to what Red Hat has done recently. Was that what you meant or has SUSE being working with Oracle for a longer time?

EDIT: I think what I’m wanting is something that gets new features more frequently, yet doesn’t become unstable. I feel drawn to the desktop eye-candy that I see getting featured with KDE desktops. I seem to believe I’m missing out on something, but can’t directly state what. Ultimately, I think I simply want to move to a more core/upstream version of Linux so that I get new functionality faster. I’m trying to find what I desperately need but never knew it existed.

Thank you OP for clarifying! Distros that are closer to upstream, but still accomplish 'stability' (often through hand-holding) and on which KDE has great support would be (in alphabetical order):

• Fedora's KDE Spin: Has a semiannual point release cycle, but still continues to get updates to kernel etc almost as soon as they come. Therefore it's sometimes referred to as semi-rolling release. In the middle out of these three in regards to how close it is to upstream.
• openSUSE Tumbleweed: Sets out to be the stable rolling release; thus receiving a constant stream of updates without foregoing stability. Perhaps surprisingly to some, it accomplishes this rather gracefully. Being on a rolling release enables it be the closest to upstream between these three.
• Ubuntu (their KDE flavour is more popularly known as Kubuntu): Also has a semiannual point release cycle, but mostly foregoes updates besides security-related ones and the ones received for snaps. It is the furthest away from upstream out of these three.

A lot more can be said concerning the differences between these three distros. However, working with them either from inside a VM or through a Live USB is probably a lot more valuable. All three are great picks, so you should be fine regardless.

Please feel free to inquire if you so desire!

You can even install KDE on Mint, and configure it however you want.

Personally, I'd advice against this as KDE is not supported on Linux Mint. While this doesn't have to mean much, it does mean a lack of polish and sophistication you might expect on Kubuntu or Fedora's KDE Spin or openSUSE (on which KDE is the default DE). This might result in some edge-case bugs and other mishaps that might trample your experience; thus giving you the wrong idea about KDE. Instead; consider booting into a Live USB of any distro that comes with KDE by default.

Distrobox exists, so one is not bound to use a specific distro just because it packages some of the apps/binaries they require.