This would -at least as far as I understand it- limit your swap’s functionality for hibernation etc. Because there your swap needs to be available early. You can still do it in theory, but the key file then would need to be included in you initrams, which kind of defeats the purpose.

There is however a much more easier option: either use LVM on luks (so the volume is decrypted with the password and then contains both, root and swap) or just use the same password for root and swap while switching over to the systemd hooks (as those encryption hooks try unlokcing everything with the first provided password by default, and only ask for additional password if this fails).

EDIT: Seeing that you crossposted this from an archlinux-specific community: You can find the guide here. It’s for using a fully enrcypted system with grub as bootloader, but the details (in 8.3 and 8.4) are true for all boot methods. Replace the busybox hooks with their systemd equivalents (in minitcpio.conf for archlinux but again this isn’t limited to that init system), then add “rd.luks.name=<your swap’s uuid=swap” to your kernel parameters and also replace the “cryptdevice=UUID=<your root’s uuid>:root” that should already be there for an encrypted system (that’s the syntax for the busybox hook) with “rd.luks.name=<your root’s uuid>=root”. On startup you will be asked for your password as usual, but then both root and swap will be decrypted with it (PS: the sd-encrypt hook only tries this once… so if you screw up and misstype your password on the first try, you will then have to type it again two times, once for root, once for swap…)

An immutable OS is fixed and mounted non-writable. Every update you get, every program you install is handled on top of it via containers or filesystem overlays so the underlying OS is untouched. Basically the same concept you know from smartphones or other devices with a “reset to factory settings” function. No matter how hard you screw up your system, you can always reset to the base OS, either by granulary deactivating things installed on top, or by a reset to the working base OS.

The software is the problem if it’s produced with a corporate mentality of “ship first, fix later”.

Ventoy and…

Clonezilla, (custom) ArchISO, Tails

the stuff you might need to safe other people’s PCs sigh …

HBCD_PE, Windows 11

If I hadn’t included those in my ArchISO already I would probably add…

one of the usual Rescue ISOs, GParted Live.

Bonus points for Ventoy’s ISO partiiton doubling as simple storage.

PS: Thanks for the reminder to update some of them again.

Yes, time consuming. But it’s still working hardware, not a now useless, now unrepairable paper weight…

Which is the definiton of “bricked” although people nowadays start to use the term inflationary.

Good thing is the kind of people making decisions based on buzzword-bongo filled PR campaigns like Crowdstrike’s are already forcing their IT to use Windows anyway.

It’s the other way around. All those PCs are bluescreening at boot. So that prevents fixing the system remotely and on a large scale. Now poor IT guys have to fix evey single one by hand.

Dual booting with Windows is always a pain, because Windows likes to nuke and replace your boot menu. The safest bet is keep Windows strictly separated: You create a 2nd efi system partition on your second drive with linux, use a boot loader there and then set everything up to start that as default. And then you configure the boot loader to chainload windows from it’s own ESP on disk one. This way Windows is oblivious about linux systems it might try to damage. And you can then set the boot loader menu to a default or to default to the last system booted. (2 separate ESPs on on disk might work, but that is not supported by UEFI, so it depends on your hardware’s implementation if they are recognized or if it just stops after having found the first…).

I would assume what you did was install the Linux boot loader (efi file) as the default like removable drives do (so grub’s efi file installed as esp/EFI/BOOT/BOOT64.efi which is the default for removably drives to take priority; done via grub-install with the --removable flag, some installations might use this by default…)

“One of the primary arguments for manually installing and configuring your system is that it will teach you a lot about linux and operating systems in general. While there is a small grain of truth to this, it’s incredibly misleading. […] A significant drawback of the “manual means advanced” slogan is that it creates a narrative that is precisely the opposite of the truth. Computing is about automation, and advanced users are those who write software or use existing software to make their computing lives more painless.”

Sure… and how exactly is one aquiring the “expertise to automate” when they never actually did it manually to know what to automate?

fsync is mainlined since January 2022 (5.16 iirc).

Zen Kernel is the opposite of “optimized for gaming”.

It was once the default kernel for out-of-the-box gaming simply because it had fsync patches integrated. But since fsync is in the normal kernel for quite some time now zen is obsolete for that purpose.

I mean it’s still an okay choice for any desktop environment but it is definitely not optimized for gaming as it sacrifices throughput and is more tailored to multitasking of a lot of smaller things running to provide a snappy desktop experience.

Doing that improved performance for Windows apps on Linux when using Wine or Valve’s Proton that is based on the former. […] benchmarks that show games running better with average improvement rates ranging from 50% to 150% when using the new driver compared to not using it.

Talking about improvements for Wine and Proton then providing no actual data for Proton (which is already using a completely different mehod for syncs - yes the basic wine method sucks) is either stupid or intentionally misleading.

Mice are so standardized that basically any problem with the basic buttons has to be a configuration issue. I have never seen a mouse not working under Linux. Unless of course you are talking about programmable and RGB stuff coming with proprietary software, but I never understood their appeal (in fact I’m also still prefering cables over batteries over recharging ones -as the internal battery is usually what fails first-).

Yes, there is.

Should XY be tagged as NSFW is not asking about if the tag should exist on certain topics (that’s indeed something you can ignore with your own settings) but about if people should be forced to flag stuff as NSFW. And I refuse to tag stuff as NSFW just because I can imagine someone, somehow, in some rare context wanting that tag. Because by then it lost all meaning and we should do an “Yes this is safe for 4 years olds”-tag instead.