Also: isn't the Arch wiki the new Gentoo wiki? Because that's the wiki early 2000s and, again, I've never used Gentoo!
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.
Then the LLM companies will notice, and they’ll start to create their own updated private training data.
But that may be a new centralization of knowledge which was already the case before the internet. I wonder if we are going to some sort of equilibrium between LLMs and the web or if we are going towards some sort of centralization / decentralization cycles.
I also have some hope that LLMs will annihilate the commercial web of "generic" content and that may bring back the old web where the point was the human behind the content (be it a web page or a discussion). But that what I’d like, not a forecast.
But longer form tutorials or even books with background might suffer more. I wonder how big the market of nice books on IT topics will be in the future. A wiki is probably in the worst place. It will not be changed with the MR like man pages could be and you do not get the same reward compared to publishing a book.
You see it referenced everywhere as a fantastic documentation source. I’d love seeing that if I were a contributor
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).
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!
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 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.)
A few years before the Xorg thing there was also the 2.4 to 2.6 kernel switchover. I think I maybe was using Slackware at that point, and I remember building my own kernel to try out the new shiny thing. You also had to update some userspace packages if I remember correctly: things like modprobe/insmod at the very least.
This was still the case when I switched to arch in like 2016 lol
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.
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.
The python (is python2) transition was even more silly though. Breaking changes to the API and they wanted (and did!) force re-pointing the command to python3? That's still actively breaking stuff today in places that are forsaken enough to have to support python2 legacy systems.
That does sound significantly longer ago then 2016 ;)
I do miss Arch but there is no way I am going to keep up with updates, I will do them when I discover I can't install anything new and then things will break because it has been so long since my last update. Slackware is far more suited to my nature but it will never be Arch.
...a smooth sea never made a skilled sailor
So +1000, I love their work, and all the contributors! It's so, so good, and greatly appreciated.
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)
It does expect quite particular format for --help though iirc if you want a good result. It predates the AI craze by a good 20 years, so it reliably either works or doesn't.
That's not true. The user-equivalent of the man pages directory on Linux and BSDs is `~/.local/share/man`. You can have your mandb index it too. You can achieve more complex manpath indexing setups using the `~/.manpath` file.
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.
e.g., NixOS just links to the archwiki page here for help with systemd timers: https://nixos.wiki/wiki/Systemd/Timers
It's also interesting to see that many other Linux distributions fail to have any wiki at all, yet alone one that has high quality content. This is especially frustrating because Google search got so worse now that finding resources is hard. I tried to explain this problem to different projects in general; in particular ruby-based projects tend to have really low quality documentation (with some exceptions, e. g. Jeremy Evans projects tend to have good quality documentation usually, but that is a minority if you look at all the ruby projects - even popular ones such as rack, ruby-wasm or ruby opal; horrible quality or not even any real quality at all. And then rubyists wonder why they lost to python ...)
Though not distro wikis, there's also a wealth of information on the Linux documentation site and the kernel newbies site. A lot of useful information is also present on Stack Overflow. I just wish that they hadn't shot themselves in the foot by alienating their contributors like this.
Other documentation sources like BSDs' are a bit more organized than that of Linux's, thanks to their strong emphasis on documentation. I wish Linux documentation was a more integrated single source, instead of being scattered around like this. It would have required more effort and discipline regarding documentation. Nevertheless, I guess that I should be grateful for these sources and the ability to leverage them. While I do rely on LLMs occasionally for solutions, I'm not very found of them because they're often very misguided, ill advised and lack the tiny bits of insight and wisdom that often accompany human generated documentation. It would be a disaster if the latter just faded into oblivion due to the over reliance on LLMs.
(I use Arch btw)
For example instead of the OS noticing that zstd was not supported, it would always use a zstd compressed initramfs image and would require the user to manually configure a supported compression their kernel supported. I don't understand why they thought it was a good idea to break my install for something that should be easy to do automatically. One could say that there is value in the forum having information on how to fix my system, but this isn't something I should have ever seen in the first place.
https://archlinux.org/news/moving-to-zstandard-images-by-def...
I've been running Ubuntu this or that since 2007. Desktops, laptops, work computers, personal computers, servers. There has been some BS to deal with, but frankly with common hardware it's exactly the same as any other system. Desktop runtime with web browser support. Except that you can do whatever you want, if you choose.
The idea of Arch was that it's supposed to be hard mode, if that's even true anymore. Any non-tech person I've showed my computer is like "oo, what is that?" I say "it's a desktop environment, here's the web browser." And that's all there is to it.
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.
I do prefer gentoo wiki over arch wiki from time to time as things feel less cluttered to me but that's just my opinion.
Do you know what the story was there, what happened? Why was it deleted?