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] command on Fedora Atomic.

Thanks for the thorough answer.

It has been my pleasure. Though, most of it was part of the suggestion to use uBlue 😅. I hope you’ll manage regardless of how you go about it 😊!

I’ll probably just try the surface kernel

Fair.

but I’ll look more into what ublue is.

I’m eager to help out if required 😜.

My two cents; install uBlue’s Microsoft Surface Images. Here you can find the (WIP) documentation on how it differs from other uBlue images. I’m sure the following lines should pique your interest:

• "Replaces the stock Fedora kernel with the Surface kernel
• Adds the correct kernel modules"

For installation, either refer to the dedicated page on installation (from ISO) or follow instructions on how to rebase (from an existing Fedora Atomic installation).

My personal take on what uBlue is, would be that it’s how Fedora would love to ship their Atomic variants if they could ship everything without worrying about those things they can’t (like hardware acceleration, codecs etc). Furthermore, uBlue even has device-specific images; which is just fantastic if you happen to own such a device.

Last, but definitely not least; it’s the best platform in which the transition to Ostree Native Container has been realized. As such, this allows some very unique ways to maintain a distro. For example; if something broke (for whatever reason) on vanilla Fedora Atomic, then… well, you (the uBlue-user) wouldn’t even have noticed it. Because that breakage simply never hit your device. Instead, uBlue’s maintainers noticed the issue -> somehow applied changes to the image so that the image doesn’t ship the issue (by either not shipping the breakage inducing update of the specific package or by shipping the workaround/fix with the image) -> the very next time you update your system (which happens automatically in the background by default) you just go on with your life as if nothing had happened in the first place 😅. So, in a sense, your system is managed such that breaking changes/updates don’t hit you; while they do hit non-uBlue users.

And I haven’t even touched upon how uBlue enhances tinkering or how it allows one to manage (a fleet of) self-customized images etc.

In case you’re still not sure if you’d like to use a derivative rather than the original, then it’s at least worth noting that uBlue is mentioned in Fedora’s documentation.

Username checks out

Honestly, that’s very encouraging! Thank you so much for providing me with very valuable insights and information! Have a good one! Cheers!

Preface:

• Last summer I tried dualbooting Windows 10 and Fedora Silverblue and succeeded. So I will be sharing my experiences based on that. I don’t know if doing this with Windows 11 will be different and/or more challenging (or not).

It’s also got an Nvidia GTX 4060 in it, which will probably not be optimal from what I hear (so any tips on that are much appreciated as well!).

Yup, the gist of it would be that Nvidia’s proprietary drivers are not found in the native repos of most distros. This also applies to Fedora. However, you should be able to acquire the proprietary drivers by following the instructions found on RPM Fusion. But, Nvidia’s proprietary drivers are known to not play nice and might require you to get into the nitty gritty later down the line to save your system. Don’t get me wrong; some people never have issues, but unfortunately this doesn’t apply to everybody. Therefore, it’s very good to approach this cautiously. If, instead, you’d prefer a managed solution; so one in which your input is left to a bare minimum but somehow Nvidia’s proprietary drivers are installed and (at times) fixed by some black magic shenanigans (or just good engineering) going on in the background, then look no further than uBlue’s Nvidia images. Delving further into what uBlue is and why IMO you should consume Fedora Silverblue through it would be out of scope for this comment.

How would I go about actually shrinking Windows 11 down to make space for Fedora? Is “partitioning” the right word to use here?

So, unfortunately I don’t quite remember what I did exactly. But I can’t imagine I would do anything beyond the following two scenarios:

• I just did what I always do and used GParted to shrink the size of the Windows 10 installation.
• I used Windows’ own tool to do the shrinking (assuming they even offer something to that effect).

After I shrink the partition, is it then just a matter of running the installer and using automatic partitioning with the unused space left over after shrinking Windows?

If memory serves me right, automatic partitioning by Fedora’s Anaconda installer was for some reason undesirable. I don’t remember the specifics, but it’s likely either one of the following:

• It straight up took hold of the entire disk and thus wanted to remove Windows.
• Issues related to the bootloader; either it just forgot about it or tried to coexist with Windows’ bootloader or tried to hijack Windows’ bootloader. Nonetheless, all of these might result into some issues later down the line. Therefore, ideally, it should have its own separate bootloader (or at least one it shares with other non-Fedora(-based) distros).

Therefore, I did something slightly different. If I recall correctly, one should adhere to the following instructions:

1. After you’ve shrunk the Windows partition, make a new partition (preferably using GParted) with the following specifics:
   • 512MB (in size)
   • Set as file system “fat32”
   • Give the partition the “boot” and “esp” flags
2. Reboot into Fedora Silverblue/Kinoite’s installer and when you get to the screen found below:

First select the disk you’d like to perform the installation on and then select Custom (optional: you’re free to choose the “Encrypt my data” option as well). After you’ve done this, press “Done” in the upper-left corner.

3. A new screen should appear, in here I selected “Click here to create them automatically.”. This should apply the default partitioning on the empty disk space. However there are a couple of things to keep track off:
   • Ensure that nothing from your Windows partitions is touched.
     • This includes the EFI partition of your Windows; if Fedora wants to do anything with it, then ensure it remains untouched.
   • By default, at least in my case, a new EFI partition specifically for Fedora Silverblue wasn’t made. This is where the earlier created partition using GParted will play an important role;
     1. Select the earlier created 512MB partition
     2. Mount Point: change it from blank/empty to /boot/efi
     3. File System: Set it to EFI System Partition
     4. Ensure the checkbox with “Reformat” that’s found to the right of the selection box for “File System:” is enabled/blue/checked
     5. I don’t recall what I did exactly with the selection box under “Device Type:”, but it likely was Standard Partition. I didn’t encrypt it.
   • (Optional) You should have noticed that this screen also enables one to create partitions. There’s a chance I created mine using this instead of GParted, but that would mean I would have departed from my ways. If the method in which the partition is created with GParted didn’t work and you don’t know why, then it’s at least worth trying to create the partition here instead.
4. After you’re done with the previous screen, select “Done” in the upper-left corner. This should prompt a popup screen that summarizes the changes. Ensure that this doesn’t do something strange to your Windows partitions and make sure that it looks otherwise as you’d expect. If you’re done, then select “Accept Changes”.
5. The rest of the installation should progress like how you’d expect from there.
6. (Post-install) Depending on how you’d like to have GRUB (read: default bootloader on Fedora) configured, you might have to do a thing or two to ensure you can access both Fedora Silverblue/Kinoite and Windows however suits you best.

I’d also love to know what kind of issues the docs are actually warning about as far as dual-booting. Will Windows wipe the bootloader on update or will Silverblue / Kinoite wipe Windows out somehow? If it’s Silverblue wiping Windows out, that may cause me to go with a different distro - but if Windows wipes Silverblue, it’ll be annoying but not a deal breaker

As long as the EFI partitions are separated, there’s nothing to worry about. And if anything, it’s Windows that might wipe out whatever Linux distro you’re dualbooting.

I plan to use Silverblue / Kinoite for development exclusively, so everything will be on GitHub.

Perhaps it’s worth mentioning one of uBlue’s most ambitious projects; Project Bluefin, or to be more precise; the Bluefin developer experience.

General tips:

• Grab a USB with enough capacity (8 GB at the bare minimum), and use Ventoy to create a bootable USB drive out of it. Then, put the .iso files for both GParted and Fedora Silverblue (or uBlue) into the designated location (read: partition called “Ventoy”).
• Regarding Ventoy, ensure to set it up specifically for your needs (GPT vs MBR, SecureBoot or not etc).
• I recall to have greatly benefited from this excellent video guide on dualboot and multiboot by DorianDotSlash when I did my first dualboot ever. It’s very likely that I even watched it in its entirety before doing my most recent Windows 10 + Silverblue dualboot.

Please feel free to inquire if you so desire!

Thank you so much for your insights! Much appreciated!

Some packages haven’t been changed in 10 years, some are changed daily. It’s bleeding edge everything, and things don’t actually break that much. Lisp makes for (obviously IMO) beautiful, simple code, so most packages are a pleasure to fix, extend, or automate.

I want to have a better idea for much time is spend on ‘management’; fix, extend and/or automate etc.

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.

If you want to use Linux on your laptop, is there any reason not to go for ‘dedicated’ Linux laptops?

FWIW, I haven’t seen these Linux-first vendors being mentioned under your post yet: NovaCustom and Star Labs.

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

This looks kinda cool. Thank you for tagging/pinging me! I’ll take a look and perhaps bother you (or others) at a later moment with questions 😅.

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 😊!