I've decided to stop using Arch Linux, because I believe in The Arch Way. I'm tempted to leave it at that, but more detail is below the cut.
The thing is, I want to have complete control over my system. Providing such control is the stated goal of Arch, but it doesn't seem to work very well in practice. Also, Arch Linux's development team and Web-forum moderators are consistently rude to users who object to Arch Linux's violations of its own published philosophy, and that's a big problem and itself a violation of the "user-centric" principle of the published philosophy.
So Arch is a nice idea on paper, but not so good in practice. There's also the same pattern I've noticed in present-day atheism, feminism, libertarianism, and Wikipedia: the goals actually pursued by members of the community differ greatly from the officially stated goals of the community, and anyone who objects to the goals revealed by members' actual behaviour, or points out the gap between the two sets of goals, is accused of being against the very different goals stated in the official documents. I don't want to be a member of a community like that, and engaging with such a community as an outsider seems to be a losing game too.
Below are some of the ways in which Arch Linux prevents me from having complete control of my system. I've probably missed a few. All this in less than a year.
- I would like to have /usr on a separate partition from /. Just because I said so is a good enough reason; see below. Arch makes it difficult to boot this configuration. A workaround has been grudgingly provided, but it involves mounting /usr very early in the boot process from initrd, and thus it defeats most of the purposes served by separating /usr onto its own partition in the first place. The changes that made separate /usr stop working were introduced as part of a routine update, were not optional, and broke my boot sequence. Users who complained about it were treated rudely.
- I would prefer not to use initrd, but it is not optional on Arch - even apart from the necessity for initrd to work around the separate-/usr issue.
- Most of /usr/bin was moved into /bin, causing trouble for separate-/usr, small-/ configurations like mine, as part of a routine update that was not optional. The stated reason for the move ("lots of people don't know the difference between /usr and / anyway, so it'll be less confusing if we put everything in /") makes no sense even if one were to accept the arguments for keeping the two on the same partition, and users who complained about it were treated rudely.
- All of /lib was moved into /usr/lib. This move directly conflicts with the project's stated (and ridiculous, but at least they took the trouble to state it) goal of moving everything from /usr into / in the previous point. This change broke my boot process, too, as well as breaking my ability to run programs written in C or C++ or in languages whose interpreters are written in C or C++ (in other words, pretty much all software); it was introduced as part of a routine update and was not optional; and users who complained about it were treated rudely.
- The published instructions for mitigating the damage of the /lib to /usr/lib move were unsuitable, causing the boot sequence to break, for systems on which GCC (!) had been installed. Users who complained about this were rudely told, in the face of considerable evidence to the contrary, that they must not have read the instructions.
- Systemd! It:
- Does not use configuration files to specify what will happen during boot, requiring that services be turned on and off using its proprietary command line utility instead of editing a config file;
- justifies the previous point by the fact that its configuration needs to be written in C and compiled (!), and that is understandably difficult to do on the fly;
- does not write a text log file, requiring that all examination of the logs be done using its proprietary command line utility instead of grep;
- is quite willing to keep logs only in RAM, to be discarded on shutdown, and although that is not supposed to be the default configuration, it appears to be what I ended up getting when I followed the instructions, although it's kind of hard to tell because (see next point) I can't actually run the utility that would let me look at the logs if they in fact exist;
- must be already up and running in order for the proprietary command line utilities to be able to run, creating a fucking hilarious chicken and egg problem when the issue being debugged is "services necessary for getting to a command line are not being started";
- replaces the logging facility used by the rest of the system, meaning that now one can't read text log files from completely unrelated software anymore either;
- when installed on my system according to the instructions, caused my system to stop accepting console logins (both GUI and text console), which made any kind of debugging difficult;
- apparently includes no provision for dropping to the command line in single-user mode in the event of an emergency (such as the GUI login not starting) during boot;
- was introduced as part of a routine update; and
- is not optional.
As I type this, my computer is still running Arch, my having invoked the "fallback" boot option to start the previously known to work configuration without SystemD. Unfortunately, I don't have a lot of time for debugging right now between getting ready to move house, working on multiple job applications, and planned trips to BC and Ontario within the next three weeks. I can limp along for a while like this. I think my debugging time is better spent on the new system that will replace Arch than on fixing what the most recent Arch update broke. I'm somewhat protected by the fact that I have multiple computers; if the desktop breaks I can use the laptop, and my email is all on my leased server. The leased server is itself running Arch, and will probably have to be migrated to something else in the near future because I don't dare run the Arch update process on it now, but that can wait until I have worked out the kinks on my home equipment.
I think the next thing I'll try will probably be Slackware. I'm familiar with it, and I only left before because I wanted to try something new. My biggest gripe with Slackware at the time was that I was having a hard time retrofitting XFCE onto my old Slackware installation, and a brand new Slackware installation probably wouldn't have that problem. I remain well satisfied with XFCE.
On the separation of root and /usr: I'd like to emphasize that I don't need a reason, and it doesn't matter who I am. The point of what we're doing here, with Linux in general and Arch Linux in particular, is supposed to be giving power to the user. If the user says "I want / and /usr on separate partitions" then that alone is a good enough reason. It is not for the system, nor for the distribution developers by remote control, to impose their view of how the system should be used. Especially not rudely. This is basically the same point I raised regarding GIMP 2.8.
It's true that I may not be the greatest expert on Linux administration. I only have 19 years worth of experience with Linux. Linus Torvalds has 21. Then again, his PhD in computer science is honorary. Mine isn't. Anybody should think twice before calling me a clueless newbie - as the Arch Linux development team has repeatedly done - but that's not the point. Even the clueless newbie should be allowed to have separate root and /usr if they say that's what they want, just because that's how we do it. At best it may be appropriate to offer the reasons why one thinks it might not be be a good idea, confirm that it's really what the user wants, and then do what the user wants because the user is the boss. Just because I said so is plenty reason enough.