The Arch wiki has rapidly become my go-to source for every time I need a real answer... and honestly it should just become my default for everything Linux. It's astoundingly high quality, some of the best content out there whether or not you're using Arch.
So +1000, I love their work, and all the contributors! It's so, so good, and greatly appreciated.
I learned linux by using Arch back in the days when pacman -Syu was almost certain to break something and there was a good chance it would break something unique to your install. This was also back in the days when most were not connected to the internet 24/7 and many did not have internet, I updated when I went to the library which was generally a weekly thing but sometimes it be a month or two and the system breakage that resulted was rococo. Something was lost by Arch becoming stable and not breaking regularly, it was what drove the wiki and fixing all the things that pacman broke taught you a great deal and taught you quickly. Stability is not all that it is cracked up to be, has its uses but is not the solution to everything.
About a year ago, when I installed Arch, my first Linux distro, most things were great. However, while testing some commands in pacman, there were a bunch of Python-related packages (even though I hadn't downloaded them). Since I needed some disk space, I figured deleting them wouldn't hurt. Unfortunately, I couldn't boot again. I guess the ones related to Python were related to Hyprland and Quickshell.
They may be preferred, but in a lot of cases they’re pretty terrible.
I had a bit of a heated debate with ChatGPT about the best way to restore a broken strange mdadm setup. It was very confidently wrong, and battled its point until I posted terminal output.
Sometimes I feel it’s learnt from the more belligerent side of OSS maintenance!
At the same time, I suspect resources like the Arch Wiki are largely responsible for how good AI is at fixing this kind of stuff. So I'm hoping that somehow people realize this and can continue contributing good human-written content (in general).
Absolutely. Even though I don’t use arch (btw), the wiki is still a fantastic configuration reference for many packages: systemd, acpi, sensors, networkmanager I’ve used it for fairly recently.
You see it referenced everywhere as a fantastic documentation source. I’d love seeing that if I were a contributor
Definitely, being unpaid LLM trainer for big corporations while nobody actually reads your work is not very encouraging. I wonder what the future will bring.
Depends on how AI-pilled you are. I set Claude loose on my terminal and just have it fix shit for me. My python versions got all tuckered and it did it instead of me having to fuck around with that noise.
I believe this to be the entire ecosystem, not just Arch. It's been a long while since something like moving to 64bit happened. Or swapping out init systems.
Most distros were stable well before Arch because Arch worked out most of the bugs for them and documented them on their wiki. Arch and other bleeding edge distros are still a big part of the stability of linux even if they don't break all that often anymore, they find a lot of the edge cases before they are issue for the big distros. In 2005 it was not difficult to have a stable linux install, you may have had to hunt a bit for the right hardware and it may have taken awhile to get things working but once things were working they tended to be stable. I can only think of one time Slackware broke things for me since I started using it around 2005, it taking on PulseAudio caused me some headaches but I use Slackware for audio work and am not their target so this is to be expected. Crux was rock solid for me into the 10s, nearly a decade of use and not even a hiccup.
I didn't really get into custom kernels until I started using Crux. A few years after I started using Arch I got sick of the rolling release and Arch's constant breakages, so I started looking into the alternatives, that brought me to Crux (which Arch was based off of) and Slackware (which was philosophically the opposite of Arch without sacrificing the base understanding of the OS). Crux would have probably won out over Slackware if it were not for the switch to 64bit, when confronted with having to recompile everything, I went with the path of least resistance. Crux is what taught me to compile a kernel, in my Arch days I was lucky when it came to hardware and only had to change a few things in the config which the Arch wiki guided me through.
Crux is a great distro for anyone ok with a source distro and I think it might be the best source distro, unlike the more common source distros, it does not do most of the work for you. Also love its influence from BSD, which came in very handy when I started to explore the BSDs and FreeBSD which is my fallback for when Patrick dies or steps back, Crux deserves more attention.
Not OP, but used Arch for a while in 2011, and at some point doing an update moved /bin to /usr/bin or something like that and gave me an unbootable system. This was massive inconvenience and it took me many hours to un-hose that system, and I switched to Ubuntu. The Ubuntu became terrible with snaps and other user hostile software, so I switched to PopOS, then I got frustrated with out of date software and Cosmic being incomplete, and am now on Arch with KDE.
Back then I used Arch because I thought it would be cool and it's what Linux wizards use. Now Arch has gotten older, I've gotten older, and now I'm using Arch again because I've become (more of a) Linux wizard.
This would be back in the 00s. I would guess that Arch got stable around 2010? I was using Slackware as my primary system by then so don't know exactly when it happened, someone else can probably fill in the details. I started using Arch when it was quite new, within the first year or two.
I also find myself using https://man.archlinux.org/ a lot. It's much more readable/user-friendly than https://man7.org plus it contains man-pages from their `extra` repo which contains a lot of popular oss tooling.
I should write a tool that converts help output to troff, even if the result wouldn't be as detailed and nice to read as a good man page it would save me the frustration of having to stab at "will i get usage docs with a -h, a --help, a -help, or running it with no args at all".
For Rust programs there's https://docs.rs/clap_mangen/0.2.31/clap_mangen/ that will generate a man page out of the help. (I am sure most programming languages have something like this). However, that's only useful if you are compiling the program (maybe distros could patch Rust programs to generate the man page during the build process)
A more general tool would be pretty good. Either for distros to call during build, after building the program proper; or for users to call.
If users are calling directly, it would be useful to, by default, show the regular man page if it exists, and only if it doesn't exist generate and display one out of --help. Also give it the same flags as man etc. In this case, we could do alias man=better_man and pretend this problem is already solved (but it's still better if distros generate it, so that they can display the man page on the web, etc)
I've never used Arch but I can really get the vibe here. Wikis (especially toopical ones) are social media of sorts. There was a strong community around the #emacs IRC channel and emacswiki.org back in the day. About a 100 people who knew each other quite well. And an Emacs bot that could read from the wiki (pre-modern RAG I suppose) and answer questions.
I think with arch wiki it is even more than that. Before I switched to arch back then, you would consult the arch wiki for an unrelated distro, because it was (is) that good. Even the aur repository helps you alot, by checking the raw scripts, how to compile stuff. I can't make a good example but it feeled like reading vi specific wiki that helped you with plugin development for emacs.
Genuinely, the wiki, and the AUR are the two killer features that keep me on Arch (not that I have any reasons to change). Arch is an incredibly polished distro, and is a real pleasure to use.
Their wiki is what sold me on Arch. I ended up there solving most of my problems on other distros, and if they can make such a fine wiki, I figured they could make a great OS (which they did).
I came here to post a similar comment. I decided to use Arch because the documentation is amazing. And I wasn't disappointed. It's become my favorite distro.
A thanks from me too! I do not use Arch, but still use the wiki as a primary reference to understand various tools. Two recent examples were CUPS and SANE:
I also use ArchWiki as my personal software configuration journal. I know I'll be back to it when I'm going to have to re-install or re-configure something, so I make sure to record any new info I discover, worked out super well for me so far.
I don't even use Arch, but I agree that their Wiki is awesome. Unless my problem is super obscure (and sometimes even then), I can nearly always find an answer there. But the best part is that it seems to be never incorrect, unlike essentially every other result in Google.
NixOS. Having a config-defined system is a bit too different at first, but really nice when it comes to system reproducibility, and being able to roll back.
It made maintaining my laptop + workstations the "same" a breeze, although it took a bit to learn and settle into something that works for me. It seems today things are easier for newcomers, but Nix Flakes are still "experimental", and thus the documentation on things might seem confusing or misleading sometimes.
Not to worry: I try a lot of distros and still use the Arch wiki regardless. There are some things that differ between distros, but it's pretty generally applicable:)
The Arch wiki has rapidly become my go-to source for every time I need a real answer... and honestly it should just become my default for everything Linux. It's astoundingly high quality, some of the best content out there whether or not you're using Arch.
So +1000, I love their work, and all the contributors! It's so, so good, and greatly appreciated.
I learned linux by using Arch back in the days when pacman -Syu was almost certain to break something and there was a good chance it would break something unique to your install. This was also back in the days when most were not connected to the internet 24/7 and many did not have internet, I updated when I went to the library which was generally a weekly thing but sometimes it be a month or two and the system breakage that resulted was rococo. Something was lost by Arch becoming stable and not breaking regularly, it was what drove the wiki and fixing all the things that pacman broke taught you a great deal and taught you quickly. Stability is not all that it is cracked up to be, has its uses but is not the solution to everything.
About a year ago, when I installed Arch, my first Linux distro, most things were great. However, while testing some commands in pacman, there were a bunch of Python-related packages (even though I hadn't downloaded them). Since I needed some disk space, I figured deleting them wouldn't hurt. Unfortunately, I couldn't boot again. I guess the ones related to Python were related to Hyprland and Quickshell.
I've contributed 32 edits (1 new page) in the past 10 years, so despite being stable, there are still many things to add and fix!
Sadly, the edit volume will likely drop as LLMs are now the preferred source for technical Linux info/everything...
They may be preferred, but in a lot of cases they’re pretty terrible.
I had a bit of a heated debate with ChatGPT about the best way to restore a broken strange mdadm setup. It was very confidently wrong, and battled its point until I posted terminal output.
Sometimes I feel it’s learnt from the more belligerent side of OSS maintenance!
At the same time, I suspect resources like the Arch Wiki are largely responsible for how good AI is at fixing this kind of stuff. So I'm hoping that somehow people realize this and can continue contributing good human-written content (in general).
> So I'm hoping that somehow people realize this and can continue contributing good human-written content (in general).
AI walled-gardens break the feedback loop: authors seeing view-counts and seeing "[Solved] thank you!" messages helps morale.
Absolutely. Even though I don’t use arch (btw), the wiki is still a fantastic configuration reference for many packages: systemd, acpi, sensors, networkmanager I’ve used it for fairly recently.
You see it referenced everywhere as a fantastic documentation source. I’d love seeing that if I were a contributor
Definitely, being unpaid LLM trainer for big corporations while nobody actually reads your work is not very encouraging. I wonder what the future will bring.
Depends on how AI-pilled you are. I set Claude loose on my terminal and just have it fix shit for me. My python versions got all tuckered and it did it instead of me having to fuck around with that noise.
I'm not there yet. Not on my work system anyway.
Seen too many batshit answers from chatgpt when I know the answer but don't remember the exact command.
> Arch becoming stable and not breaking regularly
I believe this to be the entire ecosystem, not just Arch. It's been a long while since something like moving to 64bit happened. Or swapping out init systems.
Most distros were stable well before Arch because Arch worked out most of the bugs for them and documented them on their wiki. Arch and other bleeding edge distros are still a big part of the stability of linux even if they don't break all that often anymore, they find a lot of the edge cases before they are issue for the big distros. In 2005 it was not difficult to have a stable linux install, you may have had to hunt a bit for the right hardware and it may have taken awhile to get things working but once things were working they tended to be stable. I can only think of one time Slackware broke things for me since I started using it around 2005, it taking on PulseAudio caused me some headaches but I use Slackware for audio work and am not their target so this is to be expected. Crux was rock solid for me into the 10s, nearly a decade of use and not even a hiccup.
This brings back memories, same here!
I even bookmarked a page to remember how to rebuild the kernel because I can always expect it breaking.
I didn't really get into custom kernels until I started using Crux. A few years after I started using Arch I got sick of the rolling release and Arch's constant breakages, so I started looking into the alternatives, that brought me to Crux (which Arch was based off of) and Slackware (which was philosophically the opposite of Arch without sacrificing the base understanding of the OS). Crux would have probably won out over Slackware if it were not for the switch to 64bit, when confronted with having to recompile everything, I went with the path of least resistance. Crux is what taught me to compile a kernel, in my Arch days I was lucky when it came to hardware and only had to change a few things in the config which the Arch wiki guided me through.
Crux is a great distro for anyone ok with a source distro and I think it might be the best source distro, unlike the more common source distros, it does not do most of the work for you. Also love its influence from BSD, which came in very handy when I started to explore the BSDs and FreeBSD which is my fallback for when Patrick dies or steps back, Crux deserves more attention.
I have started using Arch in 2016 and it was stable back then. Are you describing an earlier era?
The switch to systemd is the last time I FUBARed my system. 2012 it looks like?? I simply did not even remotely understand what I was doing.
Not OP, but used Arch for a while in 2011, and at some point doing an update moved /bin to /usr/bin or something like that and gave me an unbootable system. This was massive inconvenience and it took me many hours to un-hose that system, and I switched to Ubuntu. The Ubuntu became terrible with snaps and other user hostile software, so I switched to PopOS, then I got frustrated with out of date software and Cosmic being incomplete, and am now on Arch with KDE.
Back then I used Arch because I thought it would be cool and it's what Linux wizards use. Now Arch has gotten older, I've gotten older, and now I'm using Arch again because I've become (more of a) Linux wizard.
> This was also back in the days when most were not connected to the internet 24/7 and many did not have internet
That does sound significantly longer ago then 2016 ;)
This would be back in the 00s. I would guess that Arch got stable around 2010? I was using Slackware as my primary system by then so don't know exactly when it happened, someone else can probably fill in the details. I started using Arch when it was quite new, within the first year or two.
> Something was lost by Arch becoming stable and not breaking regularly
...a smooth sea never made a skilled sailor
I also find myself using https://man.archlinux.org/ a lot. It's much more readable/user-friendly than https://man7.org plus it contains man-pages from their `extra` repo which contains a lot of popular oss tooling.
unfortunately there's a trend lately where many newer cli tools don't have a man page. they put up a --help and think it suffices
even though there are tools to automatically generate man pages those days
I should write a tool that converts help output to troff, even if the result wouldn't be as detailed and nice to read as a good man page it would save me the frustration of having to stab at "will i get usage docs with a -h, a --help, a -help, or running it with no args at all".
For Rust programs there's https://docs.rs/clap_mangen/0.2.31/clap_mangen/ that will generate a man page out of the help. (I am sure most programming languages have something like this). However, that's only useful if you are compiling the program (maybe distros could patch Rust programs to generate the man page during the build process)
A more general tool would be pretty good. Either for distros to call during build, after building the program proper; or for users to call.
If users are calling directly, it would be useful to, by default, show the regular man page if it exists, and only if it doesn't exist generate and display one out of --help. Also give it the same flags as man etc. In this case, we could do alias man=better_man and pretend this problem is already solved (but it's still better if distros generate it, so that they can display the man page on the web, etc)
Then again, the built-in help can not be seperated from the binary and be missing at run-time.
I agree. If it can be launched from the command line, it deserves a man page.
That's great! I didn't know that Arch had online manpages too. I frequently use https://manpages.debian.org/ for similar reasons.
I've never used Arch but I can really get the vibe here. Wikis (especially toopical ones) are social media of sorts. There was a strong community around the #emacs IRC channel and emacswiki.org back in the day. About a 100 people who knew each other quite well. And an Emacs bot that could read from the wiki (pre-modern RAG I suppose) and answer questions.
I think with arch wiki it is even more than that. Before I switched to arch back then, you would consult the arch wiki for an unrelated distro, because it was (is) that good. Even the aur repository helps you alot, by checking the raw scripts, how to compile stuff. I can't make a good example but it feeled like reading vi specific wiki that helped you with plugin development for emacs.
Genuinely, the wiki, and the AUR are the two killer features that keep me on Arch (not that I have any reasons to change). Arch is an incredibly polished distro, and is a real pleasure to use.
Their wiki is what sold me on Arch. I ended up there solving most of my problems on other distros, and if they can make such a fine wiki, I figured they could make a great OS (which they did).
I was definitely the same way at one point but it's worth mentioning that the wiki remains a valuable resource even if you aren't using Arch itself.
e.g., NixOS just links to the archwiki page here for help with systemd timers: https://nixos.wiki/wiki/Systemd/Timers
I came here to post a similar comment. I decided to use Arch because the documentation is amazing. And I wasn't disappointed. It's become my favorite distro.
A thanks from me too! I do not use Arch, but still use the wiki as a primary reference to understand various tools. Two recent examples were CUPS and SANE:
https://wiki.archlinux.org/title/CUPS
https://wiki.archlinux.org/title/SANE
I also use ArchWiki as my personal software configuration journal. I know I'll be back to it when I'm going to have to re-install or re-configure something, so I make sure to record any new info I discover, worked out super well for me so far.
I don't even use Arch, but I agree that their Wiki is awesome. Unless my problem is super obscure (and sometimes even then), I can nearly always find an answer there. But the best part is that it seems to be never incorrect, unlike essentially every other result in Google.
I don't use Arch anymore, yet I still find myself reading their wiki from time to time. It's a phenomenal resource.
What are you using now?
NixOS. Having a config-defined system is a bit too different at first, but really nice when it comes to system reproducibility, and being able to roll back.
It made maintaining my laptop + workstations the "same" a breeze, although it took a bit to learn and settle into something that works for me. It seems today things are easier for newcomers, but Nix Flakes are still "experimental", and thus the documentation on things might seem confusing or misleading sometimes.
Aside, but it's pretty neat that the author has been semi-regularly posting on their blog for over 20 years.
gentoo forums & wiki initially were the goto place until it was deleted.
Me too. I tried various of distros before, archwiki is the best thing. I learned so much Linux knowledge from it.
Not to worry: I try a lot of distros and still use the Arch wiki regardless. There are some things that differ between distros, but it's pretty generally applicable:)
aaaaand you can download it: https://bbs.archlinux.org/viewtopic.php?id=94201
ArchWiki is great. Lot's of useful details for any Linux user.