I love the work of the ArchWiki maintainers (opens in new tab)

I think the Gentoo wiki that gp is referring to is the old gentoo-wiki.info that went down after a hardware failure or something like that and never came back.

The wiki.gentoo.org we have now restores some of that but probably not everything - and there was a void left between them that let the Arch wiki gain mindshare.

Most man pages are written for someone who knows pretty precisely what they want to do, but don't recall which nobs to turn in the program to get that done. The Arch wiki instead focuses on someone who has a vague idea of what tools to use but doesn't know how those tools operate.

I've found that with an intermediate understanding, the Arch wiki is so much better that I often times won't even check the man pages. But on the occasions where I know the thing pretty well, they can be quite spotty, especially when it's a weird or niche tool among Arch users. So, depending on how you define "more detail", that might be an illusion.

Man pages were always intended to be concise reference material, not tutorials or full docs. More akin to commented header files or a program's --help output, before the latter became common.

(GNU info tried to be a more comprehensive CLI documentation system but never fully caught on.)

Anecdotally the arch wiki expands on the vauge man pages, often with examples for cases actually used by people. And they are much more easily accessible to modify and have instant gratification of publishing changes. Publishing to upstream man pages of a project, need to wait for it to trickle down.

Arch wiki is far better than most man pages. I've referred to Arch for my own non-Arch systems and when building Yocto systems. Most Arch info applies.

In the ancient days I used TLDP to learn about Linux stuff. Arch wiki is now the best doc. The actual shipped documentation on most Linux stuff is usually terrible.

GNU coreutils have man pages that are correct and list all the flags at least, but suffer from GNU jargonisms and usually a lack of any concise overview or example sections. Most man pages are a very short description of what the program does, and an alphabetic list of flags. For something as versatile and important as dd the description reads only "Copy a file, converting and formatting according to the operands" and there's not even one example of a full dd command given. Yes, you can figure it out from the man page, but it's like an 80s reference, not good documentation.

man pages for util-linux are my go-to example for bad documentation. Dense, require a lot of implicit knowledge of concepts, make references to 90s or 80s technology that are now neither relevant nor understandable to most users.

Plenty of other projects have typical documentation written by engineers for other engineers who already know this. man pipewire leaves you completely in the dark as to what the thing even does.

Credit to systemd, that documentation is actually comprehensive and useful.

Gentoo's source based approach was always destined to be less popular than a precompiled distro. Compile times & customization options select for a certain clientele.

Interestingly enough, the ArchWiki itself seems to slowly be getting augmented by NixOS its wiki. Due to the way NixOS works, new packages constantly hit weird edge cases, which then requires deep diving into the package to write a workaround, the info of which either ends up in the wiki or the .nix package comments.

Arch and its wikin were already pretty good when it happened, but the real turning point was when the Gentoo wiki got hacked. After that, it never really recovered, and the Arch wiki must have absorbed a lot of that expertise because that's when it really took off.

as I recall anyway. can't believe it's been so long.

If your goal is to learn how it works this was great, a new challenge every day.

Perhaps we need a chaosmonkey Linux distro.

Also FreeBSD did this well recently, migrating libc and libsys in the wrong order so you have no kernel API. That was fun.

You don't become a mechanic without fixing broken down cars. So in that sense, the shittier the car, the better.

My Linux story is similar. In retrospect I learned it on hard mode, because Gentoo was the first distro I used (as in really used). And Gentoo, especially back around 2004 or so, really gave you fully automatic, armour-piercing, double-barreled footguns.

If you choose not to upgrade, it is stable. There is no QA department for Linux (or windows, they were let go around 2015) so someone has to endure the instability if there is to be any progress. We should all thank those who run nascent software so those who run stable distros can have stability.

It is the sort of mentality required to reach the place in computing which linux has. Decent chance you have linux running on something you own even if you do not run it on your computer and even if you don't, you do use the internet.

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).

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!

I think it all comes down to curiosity, and I dare think that that's one of the main reasons why someone will be using Arch instead of the plethora of other distros.

Now, granted, I don't usually ask an LLM for help whenever I have an issue, so I may be missing something, but to me, the workflow is "I have an issue. What do I do?", and you get an answer: "do this". Maybe if you just want stuff to work well enough out of the box while minimizing time doing research, you'll just pick something other than Arch in the first place and be on your merry way.

For me, typically, I just want to fix an annoyance rather than a showstopping problem. And, for that, the Arch Wiki has a tremendous value. I'll look up the subject, and then go read the related pages. This will more often than not open my eyes to different possibilities I hadn't thought about, sometimes even for unrelated things.

As an example, I was looking something up about my mouse the other day and ended up reading about thermal management on my new-to-me ThinkPad (never had one before).

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.

Slackware only does long term stable releases but Slackware current is a rolling release that does not really feel like a rolling release because of how Slackware provides a full and complete system as the base system. I avoided Slackware current for years because I did not want to deal with the hassle of rolling release, but it is almost identical in experience to using the release.

I actually got a lot of Linux knowledge from the Suse handbooks, but when I was still buying a box in the book store because of slow internet connection in the beginning of the 2000. For Linux content nowadays the Arch wiki is still one of my most used resources although I did not use Arch in years.

> The xserver (x11 or what as its old name)

It was XFree86 until around mid 00s after which the X.org fork took over.

Other good examples: Linuxthreads to NTPL (for providing pthreads), XFree86 to Xorg.

I was using Gentoo at the time, which meant recompiling the world (in the first case) or everything GUI (in the second case). With a strict order of operations to not brick your system. Back then, before Arch existed (or at least before it was well known), the Gentoo wiki was known to be a really good resource. At some point it languished and the Arch wiki became the goto.

(I haven't used Gentoo in well over a decade at this point, but the Arch wiki is useful regardless of when I'm using Arch at home or when I'm using other distros at work.)

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.

Not to mention that they broke EAC only a few years ago.

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 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 ;)

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.

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 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".

I suspect a significant amount of that is due to requiring more than one file (the binary itself) and having to learn about multiple packaging and distribution systems. That's a gigantic wall to climb compared to "put a binary on github"

I agree. If it can be launched from the command line, it deserves a man page.

Because installing a man page requires root and a writeable root fs for that matter

AUR is particularly useful because Arch has really simple build scripts. They are bash with some particular function names that you need to define (like "build" and "check") and a few bits of package metadata in variables. Pretty intelligible even if you don't know the format beforehand.

Contrast that with Debian build scripts which I never managed to figure out. It's dozens of layers of helpers for "common cases" with lots of Makefile magic. Completely inscrutable if you aren't already a Debian package maintainer. Very compact though.

I used to be in awe of the Arch Wiki, then I found the way FreeBSD and OpenBSD does documentation. I found that Arch Wiki mostly has trick and gotchas explanations, which is fine for a wiki. But sometimes I would prefer that Distros provide a centralized documentation about the base systems they provide.

Being on the internet archive and being able to pick up from a restored backup are two very different things

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.

And it matches the mindset of some linux users quite strongly. We regularly see people relying on it even though there were other well documented distros, ubuntu for instance, but it's not the same (too newcomer focused, or too administrative in spirit..). the only wiki that felt close, was the sadly gone gentoo wiki, sharp and full of gems.

That guy has a history of harassment in Debian, and is not a credible source.

This wiki is NOT Arch specific. A ton of advice and information is for all Linux distros and the Linux kernel itself, e.g.

https://wiki.archlinux.org/title/AMDGPU

The idea of arch was never that its "supposed to be hard mode", its meant to hit what many of it's users consider the sweet spot of not being too opinionated but not leaving every single factor up to the user either. For many people that balance makes it in fact easymodo.

Calling it hard mode is putting it on a pedestal, a weird one that ignores much less opinionated linux distros and setups like Gentoo.