(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.
Calling it hard mode is putting it on a pedestal, a weird one that ignores much less opinionated linux distros and setups like Gentoo.
Also: isn't the Arch wiki the new Gentoo wiki? Because that was the wiki early 2000s and, again, I've never used Gentoo!
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.
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.
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.
(GNU info tried to be a more comprehensive CLI documentation system but never fully caught on.)
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.
It is, didn't Gentoo suffer some sort of data loss which made it lose its popularity?
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.
as I recall anyway. can't believe it's been so long.
man came here to say the same.
used gentoo for all of 5 minutes in 2005 but the wiki was amazing and I referenced it repeatedly for other things.
generally heard the same about the arch wiki, too
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
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
I'm sorry to say this but Debian's documentation sucked a lot some years ago.
What a concentration of knowledge. It's not always my first click for a given problem, but it's often my last.
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 ...)
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’ve always been dabbling in Linux since 2007 but I never really felt productive in it until i discovered arch. And it’s outstanding wiki
Do you know what the story was there, what happened? Why was it deleted?
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.
The Debian wiki has improved (from a total mess to the occasion helpful content). Sadly it's orders of magnitudes away from the rigorous approach of the Archwiki.
Back when I was just starting out with Ubuntu, the Arch wiki was super helpful to gain better understanding of various things I came across. I think the wiki in general is useful to anyone who wants to understand things deeper, not just power users and sysadmins :)
Reading this has me looking for a junker laptop on eBay.
Only a Linux user would consider the instability of a Linux distro to be a good thing.
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.
Sadly, the edit volume will likely drop as LLMs are now the preferred source for technical Linux info/everything...
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!
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 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.)
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.
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
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 ;)
...a smooth sea never made a skilled sailor
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.
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.
GNU info was an interesting experiment but it got replaced by online wikis.
But yes, comparing distros themselves, Gentoo will not out compete streamlined and prepackaged distros in the broader adoption metrics.
The wikis themselves are largely distro agnostic and exceptionally useful for everyone on Linux though.
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.
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.
However, my IPMI motherboard and FreeBSD's integrated ZFS boot environments might be considered cheating...
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.
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.
Why do I miss the stupid unconscious bravery of those days :)
Seen too many batshit answers from chatgpt when I know the answer but don't remember the exact command.
c-x alt-meta-shift eat-flaming-death
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.
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.
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.
You see it referenced everywhere as a fantastic documentation source. I’d love seeing that if I were a contributor
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.
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.
- 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.
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?
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.