The Arch wiki is one of the best things the Linux community has produced. It's like a modern, improved and more complete version of TLDP.
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.
I remember long before I started using Arch I would google something nuanced for Ubuntu and there it was on the Arch Linux wiki with a “for Ubuntu users do this” section to fix whatever my issue was, this happened multiple times.
After using FreeBSD and OpenBSD, it is frankly shocking how bad Linux documentation is in comparison. On the BSDs every command, every program, every system call, and every configuration file are thoroughly documented in man pages and other guides. The FreeBSD Handbook in particular is a treasure. It more than makes up for some of the more difficult aspects of the OS by providing thorough and approachable documentation.
Instead of creating multiple wikis with probably 80% of duplicate information between them, it would be great to have a cross distribution wiki with separate sections for distribution-specific instructions where it makes sense. Gentoo had a fantastic wiki before they lost it to disk array failure (IIRC) around ten years ago, now pretty much everyone is going to the Arch wiki, why not try to turn it into a shared project?
What matters in the long run for making a good wiki are the people and policies.
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.
It probably just never worked out that way. Usually everyone starts with documenting the distro-specific parts first, and then adds more and more, until even general parts are there. But at the same time, everyone probably thinks that those general parts are supposed in the specific projects' documentation, so nobody really cares about sharing. Until the point is reached that some wiki is so big and successful, that it just silently took over the whole domain.
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?
I remember a while ago there was a small computer vision wiki that was very useful and somewhat widely used, not that many computer vision people at the time. Then, after around 2010 they decided to move the wiki to Wikipedia. You can guess what happened, original wiki was gone, very few articles survived because, of course, it's Wikipedia. A great resource just gone.
If the scope is too wide, then it's hard to see when content is outdated or irrelevant. The clear focus helps archwiki for example to not turn into a graveyard of obsolete howtos.
> it would be great to have a cross distribution wiki with separate sections for distribution-specific instructions where it makes sense.
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
In the case of Debian, they have a pretty different stance when it comes to what the role of a distro is compared to Arch.
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.
There are not just differences between distributions to consider, but also different distributions being on different versions of things. This would be difficult to organize.
What would be even better - just a single, unified distro. Imagine if all those man-hours where actually focused on delivering a single working and polished FOSS OS.
I"m still absolutely floored with how good the archwiki is. I can't hype it up enough. I really did't know what I was doing with systemd until I read that wonderful article, and also, the link to why the arch maintainer switched that distro to systemd made my accept the change to it.
When I was starting with Linux (15 years ago) with Fedora, Ubuntu, etc., for all of my questions I kept finding answers on the Arch wiki. So eventually I just switched to Arch, so the answers would always work.
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.
Documentation is super important for complex things. I feel like it’s highly underrated by many otherwise great open source projects, to the severe detriment of the project. Nice to see an explicit focus on it.
Underrated in proprietary and non-software tech, too. It's horrible when infrequent tasks turn into bespoke shitshows every time they crop up because nobody wrote down how to solve the problem. Having to figure things out from scratch every time is ridiculously inefficient. Even worse if it leads to customers having slightly different copies of the same kind of software or device configuration because there's no documented process to follow. I know from experience.
Look at the "ArchWiki active users per month" graph. What happened in 2013? With the exception of the lockdown period, it has been decreasing since then.
Many people used Arch for its status as "the pro Linux distribution" i.e. not beginner friendly, but secretly still easy enough that you don't need much effort. That's how "I use Arch btw" became a meme.
> 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.
The occasional sharing of subscriber links in this way only does us good. If you enjoy the content, please subscribe and help ensure that there will be more of it!
Joining lwn makes you a gatekeeper for lwn (and allows you to browse and comment on lwn), it doesn't simply allow you to be a reader of lwn. I'm sure their traffic has almost no relationship to their number of subscribers. Subscribers are just the people actively marketing the journalism. It's like a two-level pyramid scheme - you're spreading their journalism and looking smart, and 1/500 of the people you send it to become new subscribers.
They're usually shared links (note the 'share a free link' button at the bottom, above comments) ime - I've never seen it styled like this before. Weird that it's a subscriber-only link that doesn't require login, but does for other subscriber-only actions like sharing a free link or replying to a comment.
The Arch wiki is the PostgreSQL documentation of Linux. Even if you're not using Arch or Postgres, it's a great starting point for how something is supposed to work and it covers enough details that you can extrapolate a bit.
One feature I wish the Arch wiki had last time I used it was conditionally hiding sections. It presented various options throughout their guides and depending on which options you chose later sections weren't relevant. I often found I'd get partway through a step only to discover it wasn't relevant.
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
It's one the reasons I'm using Arch. Great features are worth little to me if I don't know about them. What I like particularly about the wiki is their why sections that explain why one would want to choose one way over another. A good example of this is the page on data-at-rest encryption [1].
This seems heavy on self-promotion. Meanwhile, Arch is still x86-centric (in spite of fragmented, unofficial forks) and doesn't do LTS, while Debian supports multiple architectures and stability. Debian does have a lot of rambling, aspirationally-unfinished, outdated, and duplicated wiki pages.
This obsession with changing what works for something else to please some shady people is annoying
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
This is really exciting. I've used the Arch Wiki countless times for setting up or configuring something in Debian but wanting a resource more native to the platform. I hope they're able to produce a comparable wiki for Debian-based OSes.
> MediaWiki markup is different. It is weird and fragile; changing a single token can completely break a page. It is also, he said, difficult to write a proper or robust parser for the language.
I switched from Ubuntu to Arch because of the quality of the Arch wiki. Ubuntu search results were filled with so much misinformation that I realized it was a culture problem. Arch, with its higher barrier to entry, attracts users who maintain its standards.
The Arch Linux community is one of the most toxic I know. First and foremost, there are members with tens of thousands of posts who become condescending and insulting when other members don’t dance to their tune. The Code of Conduct exists only on paper and is not enforced by the Arch leadership. This results in such behavior not only being tolerated but actively encouraged. Shame on them and shame on Debian for further encouraging this behaviour by inviting them to the DebConf.
> First and foremost, there are members with tens of thousands of posts who become condescending and insulting when other members don't dance to their tune.
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.
ACS_Solver|6 months ago
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.
giancarlostoro|6 months ago
_ea1k|6 months ago
_mlbt|6 months ago
sbinnee|6 months ago
homebrewer|6 months ago
haunter|6 months ago
>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...
2, https://distrowatch.com/dwres.php?resource=popularity
kbolino|6 months ago
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.
slightwinder|6 months ago
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?
kelipso|6 months ago
kzrdude|6 months ago
WhyNotHugo|6 months ago
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.
delfinom|6 months ago
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
bawolff|6 months ago
noirscape|6 months ago
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.
layer8|6 months ago
wolvesechoes|6 months ago
I know, FOSS is all about choice, yada yada.
samgranieri|6 months ago
bo1024|6 months ago
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.
tempfile|6 months ago
fernandotakai|6 months ago
LadyCailin|6 months ago
gary_0|6 months ago
ho_schi|6 months ago
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.
nylonstrung|6 months ago
dundarious|6 months ago
blueflow|6 months ago
Macha|6 months ago
In recent years, NixOS has probably taken some of their enthusiast base too
xdfgh1112|6 months ago
These people have now moved to NixOS.
aeonik|6 months ago
Arch also locked down their forum posts due to popularity in 2011.
https://bbs.archlinux.org/viewtopic.php?id=113819
homebrewer|6 months ago
abhijeetpbodas|6 months ago
rmccue|6 months ago
> 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.
corbet|6 months ago
stingraycharles|6 months ago
pessimizer|6 months ago
ThePowerOfFuet|6 months ago
It's literally a feature.
OJFord|6 months ago
jbirer|6 months ago
mauvehaus|6 months ago
IsTom|6 months ago
A small intermediate goal for ArchWiki
sam_bristow|6 months ago
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
Voultapher|6 months ago
[1] https://wiki.archlinux.org/title/Data-at-rest_encryption
burnt-resistor|6 months ago
WhereIsTheTruth|6 months ago
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
smjburton|6 months ago
Gander5739|6 months ago
Good thing mwparserfromhell exists, then.
verdverm|6 months ago
I hope debian sees improvement here with this announcement
w4rh4wk5|6 months ago
reedlaw|6 months ago
krunck|6 months ago
zoobab|6 months ago
jxbsbdbd|6 months ago
bawolff|6 months ago
7bit|6 months ago
umbra07|6 months ago
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.
anonfordays|6 months ago
Based. The Arch Code of Conduct is also free from wokeisms. Never used Arch, but I may make the switch considering these things.