No problem!
technom
The problem I have is with the installer GUI. They often don't work well when doing complex partitioning or mounting. Theoretically, you could use fdisk/parted on the live CD to do the partitioning. But the mounting section of the GUI (the part that creates the fstab) still struggles to map these new partitions the way we want it. This happens often when using btrfs subvolumes, LVM, dmcrypt or standard/custom ESP mount points (individually or in combination).
None of these are a problem when you are using a regular terminal shell to install the distros. You can just write fstab manually the way you like. This is a classic example of GUIs being convenient, but CLIs being more complete and powerful.
Theoretically, it's possible to achieve CLI installation for other distros too. Debian, for example with debootstrap. However, those procedures aren't as well documented as for Arch and Gentoo, because you're expected to use the GUI installer. CLI installation just feels natural in Arch and Gentoo.
Another issue I have is with boot loader installation. I have 2 Linux distros (for genuine uses) and a BSD installed. I use rEFInd to manage them. GUI installers replace rEFInd with their boot loader. While this can be reverted manually, it's annoying. But Grub has a CLI option to disable this (--no-nvram).
Does Arch have other tools beyond that which are unique to Arch?
Arch and Gentoo has additional small utilities like pacstrap and eselect. They're not big, but are very helpful when you need them.
Is there a difference how you configure a window manager on Arch and Debian?
I always find it easier to configure things on Arch than on Debian. There are two reasons for this. First is that Arch has an extensive wiki written with the assumption that you'll customize things (which is actually helpful even for other distros). Second is that software on distros like Debian are heavily patched for system consistency, while Arch and Gentoo provide mostly vanilla packages. This means that user documentation from the upstream software developer can be used directly on Arch and Gentoo, whereas you need to be aware of the patching in Debian.
One interesting example of the last point is the recent xz backdoor. That backdoor wouldn't have worked if Debian and Fedora didn't patch OpenSSH to talk to systemd. While Arch and Gentoo also reverted these backdoors, their OpenSSH were never patched and didn't have this vulnerability.
They aren't talking about using recursion instead of loops. They are talking about the map method for iterators. For each element yielded by the iterator, map applies a specified function/closure and collects the results in a new iterator (usually a list). This is a functional programming pattern that's common in many languages including Python and Rust.
This pattern has no risk of stack overflow since each invocation of the function is completed before the next invocation. The construct does expand to some sort of loop during execution. The only possible overhead is a single function call within the loop (whereas you could have written it as the loop body). However, that won't be a problem if the compiler can inline the function.
The fact that this is functional programming creates additional avenues to optimize the program. For example, a chain of maps (or other iterator adaptors) can be intelligently combined into a single loop. In practice, this pattern is as fast as hand written loops.
I don't think that this is a hard rule. They probably look for the same signs that we do - plausible sounding utter gibberish. They just don't want the drop in quality due to that. If an author creates content with AI, but takes their time to edit and improve it, I think that the Gentoo team may give it a pass.
This is a problem with how Haskell is packaged for Arch.
That's hard to recollect off hand. But one thing I find easier with Arch (and Gentoo, which is my daily distro) is to create complex partitioning schemes (e.g encrypted swap and btrfs subvolume mounts) and boot loader configurations.
Another example is a window manager with a somewhat complex display manager setup and a ton of supporting services.
PS: I don't consider Arch to be the silver bullet. For example, I always prefer Debian for servers.
People favor Arch Linux for configurability, not lack of bloat. With the level of configurability that Arch offers, any DE can look bloated. On the other hand, if you are a new Linux user or someone who just wants to use the computer without so much personalization, anything Linux offers is lightweight enough. Even a decade old system has enough hardware to handle modern Linux distros effortlessly. This is probably what a regular user wants anyway.
For anyone looking to learn git, the official book and site are thorough and exceptional. You can even download the eBook for free. While there's no harm in using other sources to learn git, don't use them as an alternative to the canonical source.
Uuuh, am I no true Scotsman?
That's a terrible and disingenuous take. I'm saying that you won't understand why it's useful till you've used it. Spinning that as no true Scotsman fallacy is just indicative of that ignorance.
You keep iterating the same arguments as the rest here, and I still adhere to my statement above: hardly anybody needs those tools.
And you keep repeating that falsehood. Isn't that the real no true Scotsman fallacy? How do you even pretend to know that nobody needs it? You can't talk for everyone else. Those who use it find it useful in several other ways that I and others have explained. You can't just judge it away from your position of ignorance.
People are quick to judge without considering the circumstances. Wasn't the customer's attitude equally wrong? Aren't you implying that the service person should have let her bully him?
The entire purpose of Microsoft standardizing OOXML and implementing it wrongly in Office was to make other office suites irrelevant. ODF was already standardized and countries would have adopted it if MS didn't do the same with OOXML. They stuffed the ISO with members supporting them to do it.
And now that OOXML is a viable standard, they implement it wrongly so that other office suites can't be compatible with MS Office without a lot of extra effort. Any incompatibilities with MS Office will be considered as the fault of other office suites by the general public and government officials.
Expecting MS to do what's right for the customers is putting too much faith in their nonexistent sense of ethics.