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.
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).
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.
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.
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.
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 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:)
Sadly, the edit volume will likely drop as LLMs are now the preferred source for technical Linux info/everything...
AI walled-gardens break the feedback loop: authors seeing view-counts and seeing "[Solved] thank you!" messages helps morale.
Seen too many batshit answers from chatgpt when I know the answer but don't remember the exact command.
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.
I even bookmarked a page to remember how to rebuild the kernel because I can always expect it breaking.
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.
...a smooth sea never made a skilled sailor
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.
That does sound significantly longer ago then 2016 ;)
even though there are tools to automatically generate man pages those days
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)
e.g., NixOS just links to the archwiki page here for help with systemd timers: https://nixos.wiki/wiki/Systemd/Timers
https://wiki.archlinux.org/title/CUPS
https://wiki.archlinux.org/title/SANE
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.