It's to the point where if I see 'archlinix-keyring' in my system update, I immediately abort and run through the manual process of updating keys. That's prevented any arch nuclear disasters for the last couple years

Exactly my thought! 20 years ago, I used Gentoo, and their wiki was the best. Somewhen the Arch wiki appeared and became better and better. At some point, I was tired of compiling for hours and switched one machine at a time to Arch, and today, the Arch wiki is the number one.

The wiki captures the knowledge that developers of said apps assume to be common, but don’t actually make sense unless you are bootstrapped into the paradigm.

It is, didn't Gentoo suffer some sort of data loss which made it lose its popularity?

Sadly, the edit volume will likely drop as LLMs are now the preferred source for technical Linux info/everything...

Only a Linux user would consider the instability of a Linux distro to be a good thing.

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

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

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.

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.

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

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

I'm sorry to say this but Debian's documentation sucked a lot some years ago.

e.g., NixOS just links to the archwiki page here for help with systemd timers: https://nixos.wiki/wiki/Systemd/Timers

Many other distributions fragment their knowledge across mailing lists, forum posts, bug trackers, and random blog entries. That worked when search engines were good at surfacing niche technical content. With current search quality, especially the SEO noise layer, the absence of a canonical, well-curated wiki becomes very visible.

What a concentration of knowledge. It's not always my first click for a given problem, but it's often my last.

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

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!

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.

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.

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.

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.

even though there are tools to automatically generate man pages those days

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.

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

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.

GNU info was an interesting experiment but it got replaced by online wikis.

- As the context window grows the LLM will become less intelligent [1] - Once your conversation takes a bad turn, you have effectively “poisoned” the context window, and are asking an algorithm to predict the likely continuation of text that is itself incorrect [2]. (It emulating the “belligerent side of OSS maintenance” is probably quite true!)

If you detect or suspect misunderstanding from an LLM, it is almost always best to remove the inaccuracies and try again. (You could, for example, ask your question again in a new chat, but include your terminal output + clarifications to get ahead of the misunderstanding, similar to how you might ask a fresh Stack Overflow question).

(It’s also a lot less fun to argue with an LLM, because there’s no audience like there is in the comments section with which to validate your rhetorical superiority!)

1 - https://news.ycombinator.com/item?id=44564248 2 - https://news.ycombinator.com/item?id=43991256

The "good" news is a lot of newer LLMs are grovelling, obsequious yes-men.

Seen too many batshit answers from chatgpt when I know the answer but don't remember the exact command.

However, my IPMI motherboard and FreeBSD's integrated ZFS boot environments might be considered cheating...

That you could always just boot from the CD and start again was nice. I think I reinstalled 4-5 times the "first time" before I got it where I wanted to be.

AI walled-gardens break the feedback loop: authors seeing view-counts and seeing "[Solved] thank you!" messages helps morale.

The best successor I've found is Alpine. It's minimal and secure by design, has an excellent package manager (I much prefer apk to pacman or xbps, or apt and rpm for that matter), has stable and LTS releases while letting people who want to be rolling release do so by running edge. People think it's only for containers but it has every desktop package anyone would need, all up to date and well maintained. Their wiki isn't at Arch's level, but it's pretty damn good in its own right.

You see it referenced everywhere as a fantastic documentation source. I’d love seeing that if I were a contributor

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.

I just use them like they are stable and will deal with any breakages later. I doubt any breakage will be too bad and that it'd even affect me.

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.

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.

c-x alt-meta-shift eat-flaming-death

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.

I think there will be differences based on how centralized the repository of knowledge is. Even if textbooks and wikis largely die out, I imagine individuals such as myself will continue to keep brief topic specific "cookbook" style collections for purely personal benefit. There's no reason to be averse to publishing such things to github or the like and LLMs are fantastic at indexing and integrating disparate data sources.

Historically sorting through 10k different personal diaries for relevant entries would have been prohibitive but it seems to me that is no longer the case.

THe problem with LLMs is that a single token (or even a single book) isn't really worth that much. It's not like human writing, where we'll pay far more for "Harry Potter" and "The Art of Computer Programming" than some romance trash with three reads on Kindle.

I wonder about this a lot when I ask LLMs niche technical questions. Often there is only one canonical source of truth. Surely it's somehow internally prioritising the official documentation? Or is it querying the documentation in the background and inserting it into the context window?