I haven't even used Arch on any of my machines but can't count how many times I've found their wiki useful for my workstations, servers and even custom Yocto-built systems. Arch supports many ways of doing a thing, so whatever tool I'm dealing with, Arch probably supports that and documents it on the wiki. And Arch makes few changes from upstream so the wiki instructions are often applicable on any distro. Sure, it takes some familiarity to recognize when something is e.g. Debian-specific and should be done in a Debian way, but as a user fairly familiar with Linux, I often find Arch to be the best source of documentation.
BSD ties the kernel and the software on top of it together pretty heavily, creating the expectation that the documentation should cover all of it.
Linux is meanwhile kernel and software kept separated, meaning that the documentation usually winds up assembled from separate tools, each with their own standards.
* Extremely short documentation. Everyone has seen these, a tool where the man page exists but provides almost no actual information.
* Unfriendly reference-type documentation. GNU programs are often guilty of this, coreutils certainly comes to mind. On the upside, it's usually comprehensive. But it's not good - it's a short description followed by a sequential list of every option, so the functionality is described in detail but there are no usage examples, no list of the most common options, or anything like that. Great reference, poor usage documentation.
* Too much info about ancient systems or historical details. Yes, it's great that many of these utilities are portable and can run on different systems or work with files from different systems. The man pages for zip/unzip mention MS-DOS, Minix and Atari systems, while defining the zip format as "commonly found on MS-DOS systems". The man page for less explains that it's a program "similar to more(1)" - completely useless info now - and mentions that it has some support for hardcopy terminals, again information that's not important enough for the first paragraph in 2025.
* Poor keywords in the description. There's the theoretically useful apropos command. My Xorg wouldn't start so I tried to remember how to start my wifi up. apropos 'wlan|wi-fi|wifi|wireless' doesn't mention nmcli, which I was thinking of, though it does at least provide the much more difficult iw command.
* Technical project-specific jargon that makes it easy to find the solution - if you already know it, that is. For example, Xorg documentation generally doesn't use the word "resolution". It's not in the xrandr or Xserver man page, and in the xorg.conf page it's only a reference to virtual screens. Because X uses the term screen size. That's fine, understandable and even accurate but most people would first search for 'resolution'.
A shared or central wiki sounds nice, but could quickly end up too messy. Arch having its own makes sense, as in the case of Linux - the distro is the operating system. Arch is a different OS from Fedora, which is a different OS from Ubuntu, etc. Sure, there's a lot of overlap but they are each their own unique OS.
Practically speaking ArchWiki has everything I'm likely to need as a poweruser, but it's not really all that comprehensive.
An interesting but gargantuan project would be a Linux distro that maintains patches for all of its packages that standardize directory structures, config file locations, CLI argument order, etc.
>why not try to turn it into a shared project?
This is basically both the highlight and the bane of the Linux world.
Why have another DE when there are already multiple ones? [0]
Why have another package manager when there are already multiple ones? [1]
Why have another distro when there are already multiple ones? [2]
So having another wiki makes perfect sense (or not depending on your POV)
0, https://en.wikipedia.org/wiki/Comparison_of_X_Window_System_...
1, https://en.wikipedia.org/wiki/List_of_software_package_manag...
Because then you have two bikesheds. An important aspect of the fact that the bikeshed exists, as a separate entity not integrated with the house, is that you can choose a different one. Specifically, the one that's already painted the way you want.
Maybe you don't think this is a feature in your current circumstance. Others do, which is why it persists.
Imagine if there was only Gnome or whatever unholy monstrosity is the most popular DE these days.
Young and niche wikis are happy to take any contributions they can get. The quality and timeliness of any given bit of text soon ends up wildly different from page to page or even section to section. Some people may decide to take their time not just contributing new content but also editing existing content. However, it becomes difficult to balance creation vs. curation. Too much creation, and the editors get overwhelmed, and then the users can never be sure what to trust, and so the wiki becomes irrelevant. Too much curation, and the information becomes uniformly stale and lowest-common-denominator, so the users start going elsewhere, and so the wiki becomes irrelevant.
Different wikis means each one can have its own people and policies. If the people who made one wiki great leave, there are still other wikis out there. If the policies choke the life out of one wiki, there are still other wikis out there. Some wiki can be full of deletionists while another wiki is full of inclusionists. Some wiki can be full of mergers while another wiki is full of splitters.
Forcing everybody onto one wiki forces them all to work together, but this is an entirely volunteer effort, and so many will just leave. Even if they were paid, some individuals would dominate while others would get crowded out. One can point to Wikipedia as a glaring exception, standing as basically the only wiki of note of its kind, but I think it's the exception that proves the rule.
Also, the whole sharing somehow seems to have died off over the decades. 25+ years ago, when wiki was new and shiny and everyone was experimental and motivated, there were strong movements for interwiki-content, sharing stuff between them openly. Then time happened, not much sharing was done, and every wiki-software slowly moved on, doing their own thing, becoming some semi-open silo or even a closed garden.
And today we had this same movement arising in the knowledge management-community, around their tools, and mainly in the context of Markdown, and it also kinda died down and never turned into anything substantial. Maybe, in the end, sharing information and knowledge is a bit harder to execute than it seems?
All of these are possible to answer, but they are also much easier to deal with when you're not sharing between different organizations.
The hard part about sharing is the different syntax of wikis, which could be slightly different even in the same wiki-software. Then there is the organization-part, and the sync-process itself.
Of course, today, 25 years later, we do have better solutions and much more experience for those problems.
> The maintaining is hard when there isn't clear ownership. How do the teams divide maintenance duties? How are vandalism and moderation dealt with across teams?
I would think those are pretty simply, as they all follow the same rules. I mean, handling vandalism isn't much different between Arch or Debian, it's always the same. And moderation really depends on the chosen sharing-mechanism. Which brings up again the hard part, just on a different level.
Or ... instead of admitting something, we can also just find a scapegoat instead. Let's say bad coorporations somehow prevented it?
On the other hand, sharing information is easy. The hard part is in trusting that information in the time and age of spam, propaganda and advertisers. And companies are quite secretive and don't want to share too much by default for other reasons.
Also it is way easier just do something to your own wiki, than coordinate with dozens of others where you share something.
I have many vague and some concrete ideas since a while about building trust right into the wiki system somehow, but never got around to actually implement something. Because ah well, I have to admit. It really ain't trivial after all, solving human trust.
How?
> On the other hand, sharing information is easy.
Not in the way we are talking about.
> The hard part is in trusting that information in the time and age of spam
No, it's not. We're talking here about moderated Knowledge bases. Of course, if it's a poor or even unmoderated wiki, this would be a problem. But I've never got the impression that Arch-wiki had this problem.
> don't want to share too much by default for other reasons.
Sharing what? This is about open source? Is this AI-slope? O_o
> Also it is way easier just do something to your own wiki, than coordinate with dozens of others where you share something.
I don't think Arch-Wiki has only one maintainer.
Wikis do tend to link a lot across one another. On the Alpine Wiki, I prefer to link to the ArchWiki when applicable, rather than copy content over.
This doesn't work as well as you think.
We did this in one large OSS project for documenting operations just for installs/setup/build/etc.
The problem is:
1. The list of differences get large fast if you aren't within the same family of OS like Debian/Ubuntu/Mint
2. Information will get out of date for some distros over others. Unhelpful pricks start bitching and moaning and nobody wants to deal with it at that point.
3. Unhelpful pricks will also bitch and moan you delete the out of date sections
Arch is essentially completely freeform; you, the user, are going to be making a lot of technical decisions on what you want your system to look like. It's perfectly okay for Arch to ship 4 different versions of the same type of tool, as long as all 4 are being used. The Arch wiki reflects this; it's focused around giving you a lot of options, while not going too in-depth on what you'd want to do with them. Want to swap out NetworkManager for wpa_supplicant because wpa_supplicant is easier to configure from a terminal? Perfectly fine, go ahead. Most arch packages as a result don't heavily deviate from upstream unless it's absolutely necessary to get them running.
Debian uh... isn't that. Debian still offers choice, but Debian has set the unenviable goal for themselves to provide a "stable" userland experience. This means Debian offers less options, but the options they do offer are also fixed on certain versions with sometimes pretty derivative versions compares to upstream. Their documentation as a result can get much more in-depth, just by virtue of having less to cover than Arch does.
A basic example here is setting up a webserver stack (so webserver, php and mysql); on Debian, you pick between apache2(+mod_php) or nginx/php-fpm and install mysql. Debian takes care of wiring all the permissions, user groups and all that stuff and giving you a "sane" default folder capable of serving PHP scripts on port 80 that anyone can use. It's a lot easier and nginx' configuration is specifically changed to resemble the apache2 vhosts. Arch doesn't do this; arch gives you the upstream versions of all these packages and then asks you to wire them together so that they work.
It means they attract pretty different audiences as a result; Debian users value stability/set and forget (also helped by Debian release cycles basically lasting the same length as most LTS releases of other distros), while Arch users are more conditioned to having to occasionally change their config files on updates.
That's also reflected in what their wikis aim at. Debian wikis generally can be version locked to their release; Arch wiki needs constant updating as things change.
They're different extremes here; most distros usually sit on one side or the other of this sorta thing (with the only real correlation being that dpkg-based distros usually lean more towards the Debian model), but there's also the pseudo-rolling release distros like Fedora, which try to offer similar stability to Debian but much shorter release cycles, so you'll always be running something at least close to the latest version.
But the entire point is how much better Arch's wiki is than anyone else's. I've never run Arch, I've only ever used Arch's wiki to help with Debian. Doing this ironically helps you keep in mind every weird Debianism to figure out how to apply what you're reading.
I know, FOSS is all about choice, yada yada.
Well, enjoy your optimized memory consumption instead.
Fragmentation, though ugly and inconvenient, works as a defense. systemd, along with all of the other goofy all-encompassing subsystems that were inflicted on Linux over one hot decade from Red Hat, was obviously a ploy to do the above. The jury is still out as to whether it will be successful.
Nobody wants Linux to be more like windows, and otherwise they’d just use windows.
I do, and this is why FOSS cannot reach its political goals - it won't ensure user's freedom, for almost everyone involved today would rather chase their own satisfaction.
I know, people have difference preferences, yada yada.
It wouldn't produce a FOSS OS, as they are not FOSS.
Try more.
That was an era when searching the Internet worked. Come to think of it, I haven't had Arch wiki pop up in my search results in years.
Scroll down to the long post by tomegun.
I kinda get the animosity now. I wasn't really using Linux at the time, but if I was, and my system was running great, and then I had a list of complicated instructions I had to perform to change my init system... I'd probably be peeved off.
The Wiki is the stronghold of Arch. As are the the packages. A lot of stuff makes good things good is a lot manual labor by all involved people.
PS: Removing stuff or not accepting changes is also a significant part of the Wiki. It hurts, as usual. But necessary for readability.
In recent years, NixOS has probably taken some of their enthusiast base too
These people have now moved to NixOS.
That's a common perception of Debian, perhaps even more than Arch. One difference being that Debian actually has a lot of notable use in production. It's also just as stable as any "LTS" distro, which is a welcome convenience for many beginners as well as more experienced users.
Not really.
The meme is from 4chan and the /g/ board that had some origins around 2011/2012. Gentoo was the main meme before this.
After 2012'ish the meme-culture from 4chan became mainstream internet culture with the popularity of reddit. Nothing has really progressed beyond that.
> These people have now moved to NixOS.
[citation needed]
Not many regrets aside from the times that I accidentally deleted my hard drives so many times that I can't count on fingers lol, its still a little fun lol. Ricing it with hyprland and I am truly happy with my system.
I also have nix but I couldn't really love it aside from the fact that nix-env is really really cool.
Arch also locked down their forum posts due to popularity in 2011.
> Where is it appropriate to post a subscriber link?
> Almost anywhere. Private mail, messages to project mailing lists, and blog entries are all appropriate. As long as people do not use subscriber links as a way to defeat our attempts to gain subscribers, we are happy to see them shared.
It's literally a feature.
A small intermediate goal for ArchWiki
It would be great if, when presented with different options, you could indicate which one you'd selected and have it hide the irrelevant stuff further down the page
[1] https://wiki.archlinux.org/title/Data-at-rest_encryption
This conformism is painful to witness, it happens to everything internet related, and the goal here seems to be related to the idea that internet should require a digital ID/wallet to browse
Sad era to live in
Good thing mwparserfromhell exists, then.
I hope debian sees improvement here with this announcement
People can't name them off the top of their heads, exactly because none of them have caught on. But they're easy to find.
Yes, there are some regulars on the forums that get might get snippy with you if you ask for troubleshooting help while refusing to read the forum rules, RTFM, or are incapable of following basic troubleshooting steps. I don't really see the issue.
Based. The Arch Code of Conduct is also free from wokeisms. Never used Arch, but I may make the switch considering these things.
