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.
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.
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.
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.
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 know, people have difference preferences, yada yada.
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.
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
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.
