Linux is Linux.

We should send all those people, pages and guides suggesting distros to hell.

And then instead we suggest update-schemes (fixed, rolling, slow-roll), package managers and Desktop environments. People with enough brain cells to start a computer are then absolutely able to chose a distro fitting them based on that. Everything else coming with a distro is just themeing/branding anyway…

(and just for the use statistic: Archlinux, Opensuse (Leap and Kalpa), Debian here…)

I’ve been using Arch and Manjaro for couple years each and in my experience they both break regularly. But, for some weird reason, Arch Linux is praised, when Manjaro is shamed upon.

No, there is not some weird reason but actual very good ones.

Things can break on a bleeding edge update scheme. That’s to be expected from time to time. But the questions are “why did it break” and “what is done to fix it”.

If something breaks on Archlinux it’s because of some new package with a issue that escaped testing. Then the fix come out as fast as possible (often within minutes even, but let’s assume hours as those things need to move through mirrors first…).

If something breaks on Manjaro it’s either because of the exact same reason as above, but 2 weeks later. Because Manjaro keeps back updates for two weeks “for stability reasons”, yet doesn’t do anything in those 2 weeks. So they just add the same problem later, completely defeating the argumant about stability. Oh, and fixes are of course kept back for 2 weeks, too, because… reasons.

Or it breaks because they fucked up their internal QA. For example by letting their certificates expire again and again and again and again… of by screwing up their very own pacman-wrapper and then ddos’ing the AUR for all users, not only Manjaro ones.

Or -speaking about the AUR- it breaks because they give their users full access to the Arch User Repository (without any warnings about user content being less reliable and used at your own risk) pre-installed. Also they do it on a system generally out-of-date because it lags 2 weeks behind. Which is not what AUR packages are build for (they assume up-to-date systems) and is a straight path to dependency hell and breakings… not because something went wrong but because the whole concept of an out-of-date system not running their own also 2-weeks behind version onf the AUR is idiotic. On the “plus” side they have an easy fix: blame the user, because he should obviously know that an pre-installed part of Manjaro is conceptionally flawed and shouldn’t be trusted.

Right decision but for the wrong reason.

misinformation != desinformation

Both exist plenty…

And just lke with the war on drugs, countries will realize it’s a lost cause. And will then instead try to coopt the system to spread their own desinformation. If you can’t win, exploit it for your own gains…

Welcome to our wonderful post-factual age.

Btrfs can mostly fo everything you would normaly use LVN or raid for natively.

Btrfs raid0 lets you combine any number of differently sized drives into one (just without the speed boost of traditional raid0 because with flexible drive sizes data is not symmetrical striped). And btrfs raid1 keeps every data duplicated, again with flexible number and sizes of drive (also with metadata on every drive).

The sytemd hooks (instead of the traditional busybox ones) then manage the one other task you use LVM for: unlocking multiple partitons (for example multiple raid partitons and swap) with just one password. Because the systemd encrypt function tries unlooking all luks partitions it finds with the first password provided and only asks for passwords for each partition if that doesn’t work.

PS: btrfs subvolumes are already flexible in size and don’t need predefined sizes. So the only things that need to be created separately are non-btrfs stuff like the efi system partition or a physical swap (which you can also skip by using a swap file instead of a partition).

BTRFS raid on LUKS-encrypted devices (no LVM, all unlocked with one password via SystemD encrypt hooks).

They are written but don’t replace something in the read-only OS. They are just overlayed, so once removed the original is still there. How they do it differs. There are actual overlay filesystems for the job, or some use btrfs where all subvolumes behave mostly like virtual partitions (and copies of a subvolume only take space for changes of the original).

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.

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.

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.

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

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