throwawayish

"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.

But that's the nature of the beast. Unless one defines their threat model^[1]^, there's an ever-expanding list of improvements one might apply to enhance security; with -at some point- (mostly) diminishing returns and we've yet to talk about the amount of comfort that's sacrificed along the way. Therefore, before you do anything else, define your threat model. Afterwards, try to apply step-by-step whatever is required to protect your assets to a degree you're comfortable with^[2]^. If, however, this seems like too much work for you, then consider either one of the following:

• Just go on with your life as if you hadn't become security-conscious. If you're just a random person that doesn't store anything valuable on their device in the first place and isn't a possible target to more sophisticated groups for whatever reason, then even in the worst-case scenario you can just reinstall your system and be done with it (assuming your home network hasn't been affected by malicious actors).
• Reconsider how you want to consume Arch and if Arch Linux is even the right distro for you. Distros like Fedora and openSUSE are better known for maintaining good security defaults and try to ever improve themselves in this regard. Sure, sometimes some of these changes are applied to Arch as well. However, by its very nature, Arch Linux is more akin to a blank slate.Thus, if you actually know what you're doing, then it's easier to get Arch Linux to wherever you want^[3]^. But, becoming that knowledgeable is easier said than done.
• If you really like Arch, but also really care about your security, then it's probably best to look into the most impactful changes (security-wise) with the least amount of work associated to it. Simply not using packages from the AUR is one such change for example, if you can afford it...

1. Digital security and/or cybersecurity is actually just one part of it.
2. In terms of initial setup, (possible) maintenance and lost comfort.
3. This even applies to hardening your system.

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:

   Click here to reveal image of the screen

   
   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.

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.

Deez Nuts.

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).