That’s a 40% price increase just to get your keyboard layout and a CPU upgrade

Fixed that for you*.

So what happens is that changing the keyboard language comes together with the CPU upgrade from Intel® Core® i3-1315U to Intel® Core® i7-1360P. That’s what you pay for*. I agree with you that they might have done a better job at conveying what’s happening. For whatever it’s worth, I didn’t immediately notice this myself. Therefore I tried to contact them in hopes of resolving the issue. They responded very quickly (like within a couple of minutes) and explained what was going on. Props to them for that!

tuxedo/system76/metabox/etc are all rebadged Clevo ODM designs.

Yup, clearly. /s

The support that these vendors put in for Linux is miniscule

Wow, that’s a bold claim if anything. First time seeing a Pop!_OS-denier, I assume you also deny the existence of COSMIC? And these are just some of the work done done by System76 only.

the hardware is “fine” at best

Another bold claim; one which only holds true if merely Apple’s finest go beyond “fine”.

I for one love my desktop 3700x and 3060ti mobile stuffed into a laptop chassis. No compromises were made on this hardware.

Hmm…, very interesting! I’m totally oblivious of the existence of such a thing. If that is your benchmark, then I can actually understand what you meant with your earlier claim. Please feel free to enlighten me on how this works 😊.

Conversely, Dell and Lenovo laptops tend to have very good Linux support and can be had relatively cheaply, especially if you get something that isn’t bleeding edge.

I don’t deny this. However, none of Dell’s laptops with decent Linux support have an AMD CPU (or one of Intel’s latest Meteor Lake CPUs). Thus, at least in terms of battery life, it’s not desirable; with battery life being something that OP has explicitly mentioned. As for Lenovo, the Thinkpad-line (the one generally recommended for its Linux-support) with AMD CPUs starts at a very high price. At which point, the “fine” hardware from the Linux-first vendor not only starts to be attractive but highly desirable by comparison.

Ultimately, any discussion on this would boil down to cost vs convenience. As OP hasn’t explicitly stated anything on this regard, it seems unproductive to delve into this further. However, strictly speaking, I have to agree with you that the Linux-first vendors are (in almost all cases) more expensive. Thank you for pointing that out for OP.

My two cents; if you want to use Linux on it, then do yourself a favor and pick a laptop from a Linux-first vendor. So the likes of NovaCustom, Star Labs, System76, Tuxedo and others found on the link over here come to mind. Besides that, it’s important that the device in question either has a dedicated GPU (or at least supports eGPUs). Furthermore, choose a device with relatively high battery capacity; they go up to ~99 Wh, so pick something that’s at least relatively close to that number.

Feels like pointless recreating of everything that is allready available for years.

This seems to be either blatantly false or simply uninformed.

Sure, for years, there have been many different attempts to explore ‘immutable’(/‘atomic’) distros. And while some concepts have become mainstays, like; atomic updates, some degree of immutability during runtime and to a lesser degree; reproducibility, declarative system management and reliance on (OCI) images. There remains a lot to explore still and differentiation in implementation (however minute) is important as it’s not always clear what will and will not stick eventually.

As to your claim of Vanilla OS “pointlessly recreating what is already available for years”, the only atomic distros that have been usable for years are Fedora Atomic, Guix System and NixOS. Both Guix System and NixOS are radically different from all the others and Fedora Atomic has only relatively^[1] recently^[2] started to do the things that actually resemble what Vanilla OS 2 Orchid envisions for their system.

1. https://fedoraproject.org/wiki/Changes/OstreeNativeContainer
2. https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable

“ABRoot is utility which provides full immutability and atomicity to a Linux system, by transacting between two root filesystems. Updates are performed using OCI images, to ensure that the system is always in a consistent state. It also allows for local atomic changes thanks to the integrated ABRoot package manager, which generates local OCI images with the user’s changes, and then applies them on top of the system’s default image.”

(From ABRoot’s page on Github)

This sounds a lot like what Fedora is trying to achieve with their ostree native containers.

Are there any technical differences between the two? Besides, of course, relying on tools with different names etc*. FWIW, it doesn’t seem as if ABRoot (v2) allows one to pin multiple deployments, while this can be done relatively easily through the sudo ostree admin pin [-u] <index> command on Fedora Atomic.

Why ublue over fedora’s images?

Personally, I’ve been enjoying uBlue over vanilla Fedora Atomic for what they offer in terms of system management.

To give you a better idea on what I mean; just a month ago an update to Podman caused breakage and people weren’t able to use their containers created with Distrobox/Toolbx^[1]. Sure; a rollback is accomplished relatively easy and I’m sure some would even be able to fix it themselves. Regardless, every Fedora Atomic user that relied on Podman would have been interrupted to some capacity.

Which, of course, begs the following questions… Isn’t it very inefficient for everyone to fix this issue themselves? Wouldn’t it be easier if somehow Fedora forced some fix upon all of us so that just one entity is burdened instead of all of us? Heck, wouldn’t it be better if Fedora just withhold the update until it’s fixed? Is this perhaps some pipe dream that will never see the light of day? etc…

The interesting part, though, would be how I (a ‘uBlue-user’) didn’t even notice Podman was causing issues in the first place. “How?” you might ask, well… The uBlue devs noticed the issue, applied some magic so that I and many other uBlue users like me just went on with their day like they would otherwise; without being interrupted because Podman just had a bad update. (Did the supposed pipe dream actually already exist in some form or fashion?)

This is just the most recent example of this. But in the last year or so, out of the top of my head, there have been a few more times in which uBlue users didn’t even notice a thing while the others either had to rollback or fix their issues themselves. If you enjoy this interruption and/or are willing to deal with it for the sake of whatever, then please feel to continue to do so. However, I prefer to have a system I can rely on at all times and uBlue offers me just that while remaining very close to vanilla Fedora Atomic.

You won’t have fedoras signatures anymore.

It depends if you have the luxury to rely on them in the first place.

If setting up your workflow (or whatever) requires you to get to the nitty gritty of things and change those parts of the system that strictly speaking isn’t well supported by just rpm-ostree, then -for almost a year now- your best bet would have been to (instead) experiment with (what’s been referred in Fedora’s Wiki as) Ostree Native Containers.

And the truth is, unless you really know what you’re doing, that uBlue offers the best platform to engage with this system. Heck, within a week after Kinoite’s very own maintainer blogged about how to sign container images via Github actions, one of uBlue’s maintainers tried to implement this for uBlue to improve their own platform and succeeded.

Finally, let’s not forget that uBlue is even endorsed by Fedora (or at least by whoever maintains its documentation). Heck, even the inception of uBlue was due to an interaction between Jorge Castro (one of uBlue’s maintainers) and Colin Walters (one of the masterminds behind the whole rpm-ostree-ecosystem).

P.S. If I hadn’t made it clear, it’s totally fine to continue to rely on Fedora Atomic directly without any interventions from third parties for system management or whatsoever. I just wanted to elaborate why I, personally, prefer to use images provided by uBlue.

1. Source to a thread in which this is discussed.

Great choice! But as others already have noted; if it will be used for virtualization only, then perhaps distros like Proxmox should suit you better.

Deez Nuts.

virtualization

Honestly, I don’t know. Though, I’d reckon there would be any significant difference between distros.

stability

Depends on what you mean with stability. If you meant it like how “stable” is used in “Debian stable”, then it would be any distro with a release cycle that chooses to not continuously deliver packages; but instead chooses to freeze packages and hold off updates (besides those related to security) for the sake of offering a relatively polished experience in which the behavior of the distro is relatively predictable. Some distros that score good on this would be Debian stable and openSUSE Leap. It’s worth noting that Distrobox, Flatpak and Nix allow one to have newer packages on these systems if desired.

If, instead, you meant that the distro is less likely to break upon an update, then it’s important to note the following:

• While you shouldn’t expect breakage to happen in the first place, unfortunately it’s realistic to expect it every so often (read: 0-2 times a year on non-stable distros).
• If you have a lot of packages, then it’s more likely that at least one of them causes some breakage.
• Technically, every update is a potential ‘breakage-moment’.
• Packages that haven’t been installed through the official/native repos are more likely to cause breakage.
• Relying on Distrobox, Flatpak and Nix for (at least some of) your packages should benefit the stability of your base system.
• (GRUB-)Btrfs+Timeshift/Snapper allows one to create snapshots one can easily rollback to in case of breakage. Therefore it’s worth seeking out a distro that configures this by default or set it up yourself on whichever distro you end up using (if it isn’t included by default).
• So-called ‘atomic’^[1] distros are (generally speaking) more resistant to breakage, but (arguably) they’re less straightforward compared to traditional distros. It’s still worth considering if you’re adventurous or if your setup is relatively simple and you don’t really feel the need to tinker a lot. Don’t get me wrong; these atomic distros should be able to satiate ones customization needs, it’s just that it might not be as straightforward to accomplish this. Which, at times, might merely be blamed on lackluster documentation more than anything else.^[2]

As for recommendations you shouldn’t look beyond unadulterated distros like (Arch^[3]), Debian, Fedora, openSUSE (and Ubuntu^[4]). These are (in almost all cases^[5]) more polished than their respective derivatives.

speed

Most of the distros mentioned in this comment should perform close enough to one another that it shouldn’t matter in most cases.

If you’re still lost, then just pick Linux Mint and call it a day.

1. More commonly referred to as ‘immutable’. Atomic, however, is in most cases a better name.
2. If you’re still interested, I’d recommend Fedora Silverblue for newcomers and NixOS for those that actually know what they’re getting into.
3. I believe that one should be able to engage with Arch as long as they educate themselves on the excellent ArchWiki. It might not be for everyone, though. Furthermore, its installation (even with archinstall) might be too much for a complete newbie if they haven’t seen a video guide on it.
4. Ubuntu is interesting. It has some strange quirks due to its over-reliance on Snap. But it’s worth mentioning, if you don’t feel like tinkering.
5. With Linux Mint (and Pop!_OS) being the clear exception(s).

Deez

Thank you for sharing your thoughts and experiences. Cheers, mate.

Hmm, one I guess is that it is not “permanent” and deactivates after one command (in Kakoune, you have to explicitly do ‘;’ to collapse the selection to its end (which you can flip with the start using ‘alt+;’) or move around without extending the selection). That’s really the only thing I can think of at the moment and I feel like often it really doesn’t matter tbh, so maybe I was just talking out of my ass there a bit lmao.

Regardless; thank you for mentioning this!

Apparently you can quickly reselect it in vim with ‘gv’ though, which I never checked until now. That’s useful to know.

Hehe, thanks for sharing that; might become useful soon 😅.

One thing I’m really missing from vim though is that it can list directories, has a hex editor, and can read a bunch of other file formats. I think it can even edit remote files over sftp, but maybe I’m confusing that with Emacs. Kakoune just does local text files (though you can of course do stuff like ‘%|xxd’ to pipe the file through xxd to get a hex view, edit and then ‘%|xxd -r’ and save but that feels very very sketchy).

Until yesterday I knew almost nothing about Kakoune. But I’ve since tried to do some reading; while there’s still a lot to uncover and/or explore, I feel as if it tries to offer a more focused experience (for better or worse).

I know almost nothing about Vimscript.

This is actually good news as it means I shouldn’t have to learn a new language to engage with it.

However, during these years every time I tried it it had some slight differences from vim that made using it somewhat annoying.

Interesting. Would you mind elaborating upon those differences?

I probably started with Vim

Hehe, I assume it has been some time since you started this journey.

Thank you for your contributions to the conversation 😊!

I’m not surprised to hear that you preferred Fedora Silverblue over openSUSE MicroOS. Don’t get me wrong, I think that openSUSE Aeon/Kalpa (current names for openSUSE MicroOS Desktop) have a lot of potential. However, as it stands, Fedora’s Atomic Desktops are just more mature.

With the amount of different distros you’ve tried (though mostly derivatives of Arch/Debian), I’m actually surprised to see that you haven’t used any derivative of Fedora. Is there any reason in particular?

and without all your configs it is a very different beast of an editor anyway and something you will need to get used to everytime you jump on the server.

Good point.

If you can install stuff to your home drive then it is quite easy to get helix running - it is a single binary with some language assets (requires one env var to point to them). So is trivial to get working from your home dir without a package manager.

I’m impressed. Thank you for pointing this out.

Ideally with things like ansible you should not need an editor on it at all.

Hmm…, honestly, I haven’t yet done a lot of things with Ansible yet. Perhaps it’s time to go explore that rabbit hole as well 🤣. Thank you (once more) for pointing this out!

Do you mean vi input mode in other editors?

Yes.

Your input has been much appreciated! Thank you!

The problem with SpaceVim is that it offers a lot of toggles that are easy to switch but there are no examples for more ‘custom’ config and I struggled to figure it out. There’s a lot of examples and guides for nvim so it was easier. I don’t know, maybe it was just me but with SpaceVim I also didn’t really see what’s possible. With nvim I just found long lists of useful plugins that you can add one by one.

Makes a lot of sense. Documentation is indeed very important. Thank you so much for sharing your insights and experiences! Much appreciated!