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.

Let me google that for you: Quark

Car-brains don’t do standard logic, only car-logic…

So this is what happens when a Fiat Multipla develops into its final form in all its glorious ugliness…

Depends on the intended effect… I personally see this as just one single piece in a big wave of equally dilettante articles used to convey one message to the caual reader: that 3d printing is bad, dangerous and needs to be regulated.

And we all know who’s willing to pay money to push that story…

There is a difference here.

Unlocking home later in the boot process is not a problem, so the you can indeed have a keyfile on your root and get your home unlocked and mounted after root is done.

Swap however needs to be available early, at least if you want to use it for hibernation.

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

Hydrogen or battery?

The answer is battery. If battery is an option then the answer is battery. Always.

This will only change if either there is an unlimited amount of free energy available or the laws of thermodynamics stop being valid.

with Apple dominating Europe…

Your own map diagrees, with 100% of the picked examples from Europe having Samsung as market leader.

Stick to a specific distro and train your staff

Linux is Linux. Train your staff to properly use one and they can use them all. “Distro” is just a fancy word for “which package manager and update cycle to we chose and what logo do we put on our pre-installed wallpaper”.

Yes, I actually just use Wine with a default prefix and pray it works. If it doesn’t (rarely) then the game gets his own prefix to tweak the settings.

you didn’t say what file system your /boot partition was using, so I don’t want to guess

It’s actually easy to guess. There is exactly one filesystem UEFI has to support by its specification, everything else is optional… so unless you produce for Apple -because they demand apfs support for their hardware- no vendor actually cares to implement anything but FAT.

When you say system drive this will also have your efi system partition (usually FAT-formated as that’s the only standard all UEFI implementations support), maybe also a swap partition (if not using a swap file instead) etc… so it’s not just copiying the btrfs partition your system sits on.

Yes clonezilla will keep the same UUID when cloning (and I assume your fstab properly uses UUIDs to identify drivees). In fact clonezilla uses different tools depending on filesystem and data… on the lowest level (so for example on unlocked encrypted data it can’t handle otherwise) clonezilla is really just using dd to clone everything. So cloning your disk with clonezilla, then later expanding the btrfs partition to use up the free space works is an option

But on the other hand just creating a few new partitions, then copying all data might be faster. And editing /etc/fstab with the new UUIDs while keeping everything else is no rocket science either.

The best thing: Just pick a method and do it. It’s not like you can screw up it up as long if your are not stupid and accidently clone your empty new drive to your old one instead…

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.

Germans are still suffering from having to integrate another failed quasi-soviet state more than 30 years later, so you couldn’t pay them enough for taking Königsberg back.

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