The Arch wiki is one of the best things the Linux community has produced. It's like a modern, improved and more complete version of TLDP.
I haven't even used Arch on any of my machines but can't count how many times I've found their wiki useful for my workstations, servers and even custom Yocto-built systems. Arch supports many ways of doing a thing, so whatever tool I'm dealing with, Arch probably supports that and documents it on the wiki. And Arch makes few changes from upstream so the wiki instructions are often applicable on any distro. Sure, it takes some familiarity to recognize when something is e.g. Debian-specific and should be done in a Debian way, but as a user fairly familiar with Linux, I often find Arch to be the best source of documentation.
I remember long before I started using Arch I would google something nuanced for Ubuntu and there it was on the Arch Linux wiki with a “for Ubuntu users do this” section to fix whatever my issue was, this happened multiple times.
The special instructions for other distros could be at risk for being deleted, as "something that will not work on Arch as-is is not something we will be hosting on our site".
I think one reason the arch wiki thrives is that it IS a generic linux wiki.
The arch wiki describes the upstream package.
I say this because Arch tries to use the upstream software as-is, and describes requirements and helps make configuration choices.
Other distributions tend to make the choices for you, configuring and modifying upstream to fit the distribution.
With respect to a wiki, this would be another layer of documentation to add. Describe the package, describe the distro, and explain the configuration choices.
The arch wiki could expand to support distro switching, with each distro having its own domain, and all that could link back to a general linux wiki. It'd be beautiful.
Yeah, the Arch wiki is the Gentoo wiki we lost. I was around for it and the Gentoo wiki was amazing, it was one of the best Linux resources all-around, it was tremendously useful even if you didn't use Gentoo.
From what I can gather, the event happened in 2008. At the time gentoo had no official wiki, it was an unofficial wiki that died or went offline for a significant amount of time.
After using FreeBSD and OpenBSD, it is frankly shocking how bad Linux documentation is in comparison. On the BSDs every command, every program, every system call, and every configuration file are thoroughly documented in man pages and other guides. The FreeBSD Handbook in particular is a treasure. It more than makes up for some of the more difficult aspects of the OS by providing thorough and approachable documentation.
It's a different model of development, leading to different expectations.
BSD ties the kernel and the software on top of it together pretty heavily, creating the expectation that the documentation should cover all of it.
Linux is meanwhile kernel and software kept separated, meaning that the documentation usually winds up assembled from separate tools, each with their own standards.
Yes, BSD is a single coherent system but so are many Linux distros. It's just that we've come to accept bad documentation as the norm for Linux-based tools. In my experience there's several types of problems that are very common for Linux tools:
* Extremely short documentation. Everyone has seen these, a tool where the man page exists but provides almost no actual information.
* Unfriendly reference-type documentation. GNU programs are often guilty of this, coreutils certainly comes to mind. On the upside, it's usually comprehensive. But it's not good - it's a short description followed by a sequential list of every option, so the functionality is described in detail but there are no usage examples, no list of the most common options, or anything like that. Great reference, poor usage documentation.
* Too much info about ancient systems or historical details. Yes, it's great that many of these utilities are portable and can run on different systems or work with files from different systems. The man pages for zip/unzip mention MS-DOS, Minix and Atari systems, while defining the zip format as "commonly found on MS-DOS systems". The man page for less explains that it's a program "similar to more(1)" - completely useless info now - and mentions that it has some support for hardcopy terminals, again information that's not important enough for the first paragraph in 2025.
* Poor keywords in the description. There's the theoretically useful apropos command. My Xorg wouldn't start so I tried to remember how to start my wifi up. apropos 'wlan|wi-fi|wifi|wireless' doesn't mention nmcli, which I was thinking of, though it does at least provide the much more difficult iw command.
* Technical project-specific jargon that makes it easy to find the solution - if you already know it, that is. For example, Xorg documentation generally doesn't use the word "resolution". It's not in the xrandr or Xserver man page, and in the xorg.conf page it's only a reference to virtual screens. Because X uses the term screen size. That's fine, understandable and even accurate but most people would first search for 'resolution'.
I for one really enjoy the historical anecdotes you get in the "NOTES", "PORTABILITY" or even "BUGS" sections.
But I do realise that my context is mostly recreational, work doesn't really require glueing POSIX commands together.
Yep. There is no "Linux Operating System." There's the Linux Kernel, and that kernel is used in tons of different OSes. It's sounds like a small nitpick but its a huge deal and a common misconception for those outside of the Linux world anytime a topic of unifying something in the Linux world comes up.
A shared or central wiki sounds nice, but could quickly end up too messy. Arch having its own makes sense, as in the case of Linux - the distro is the operating system. Arch is a different OS from Fedora, which is a different OS from Ubuntu, etc. Sure, there's a lot of overlap but they are each their own unique OS.
Its consistent conventions also help a lot — it means learning a handful of things once, which can then be applied numerous other places (which as an aside, used to also be a strength of macOS). No need to even consult the manpage in many cases then.
An interesting but gargantuan project would be a Linux distro that maintains patches for all of its packages that standardize directory structures, config file locations, CLI argument order, etc.
I learned how to do NetBSD kernel hacking from just the man pages. They're still my first-line documentation on the NetBSD file system work I'm doing. The state of Linux documentation is appalling by contrast.
I don’t think anyone is confused about this. Linux is a shorthand for the family of Unix like operating systems that use Linux as the kernel.
The only ambiguity in this shorthand is if android or chrome os are being referenced, but it’s pretty clear from context that they are not relevant to the discussion.
Instead of creating multiple wikis with probably 80% of duplicate information between them, it would be great to have a cross distribution wiki with separate sections for distribution-specific instructions where it makes sense. Gentoo had a fantastic wiki before they lost it to disk array failure (IIRC) around ten years ago, now pretty much everyone is going to the Arch wiki, why not try to turn it into a shared project?
What matters in the long run for making a good wiki are the people and policies.
Young and niche wikis are happy to take any contributions they can get. The quality and timeliness of any given bit of text soon ends up wildly different from page to page or even section to section. Some people may decide to take their time not just contributing new content but also editing existing content. However, it becomes difficult to balance creation vs. curation. Too much creation, and the editors get overwhelmed, and then the users can never be sure what to trust, and so the wiki becomes irrelevant. Too much curation, and the information becomes uniformly stale and lowest-common-denominator, so the users start going elsewhere, and so the wiki becomes irrelevant.
Different wikis means each one can have its own people and policies. If the people who made one wiki great leave, there are still other wikis out there. If the policies choke the life out of one wiki, there are still other wikis out there. Some wiki can be full of deletionists while another wiki is full of inclusionists. Some wiki can be full of mergers while another wiki is full of splitters.
Forcing everybody onto one wiki forces them all to work together, but this is an entirely volunteer effort, and so many will just leave. Even if they were paid, some individuals would dominate while others would get crowded out. One can point to Wikipedia as a glaring exception, standing as basically the only wiki of note of its kind, but I think it's the exception that proves the rule.
And it's not without problems, not the least of with is that being the default Wiki attracts the kind of people would would love to control the definite source of information.
>Why make a green bikeshed when there's already a red bikeshed?
Because then you have two bikesheds. An important aspect of the fact that the bikeshed exists, as a separate entity not integrated with the house, is that you can choose a different one. Specifically, the one that's already painted the way you want.
Maybe you don't think this is a feature in your current circumstance. Others do, which is why it persists.
It probably just never worked out that way. Usually everyone starts with documenting the distro-specific parts first, and then adds more and more, until even general parts are there. But at the same time, everyone probably thinks that those general parts are supposed in the specific projects' documentation, so nobody really cares about sharing. Until the point is reached that some wiki is so big and successful, that it just silently took over the whole domain.
Also, the whole sharing somehow seems to have died off over the decades. 25+ years ago, when wiki was new and shiny and everyone was experimental and motivated, there were strong movements for interwiki-content, sharing stuff between them openly. Then time happened, not much sharing was done, and every wiki-software slowly moved on, doing their own thing, becoming some semi-open silo or even a closed garden.
And today we had this same movement arising in the knowledge management-community, around their tools, and mainly in the context of Markdown, and it also kinda died down and never turned into anything substantial. Maybe, in the end, sharing information and knowledge is a bit harder to execute than it seems?
I think the sharing is easy. The maintaining is hard when there isn't clear ownership. How do the teams divide maintenance duties? How are vandalism and moderation dealt with across teams? How do disagreements between teams over style and quality dealt with? Cost of hosting split?
All of these are possible to answer, but they are also much easier to deal with when you're not sharing between different organizations.
The hard part about sharing is the different syntax of wikis, which could be slightly different even in the same wiki-software. Then there is the organization-part, and the sync-process itself.
Of course, today, 25 years later, we do have better solutions and much more experience for those problems.
> The maintaining is hard when there isn't clear ownership. How do the teams divide maintenance duties? How are vandalism and moderation dealt with across teams?
I would think those are pretty simply, as they all follow the same rules. I mean, handling vandalism isn't much different between Arch or Debian, it's always the same. And moderation really depends on the chosen sharing-mechanism. Which brings up again the hard part, just on a different level.
I think it's more of, let's say, unify the 2 wikis in one, what team should moderate Debian's or Arch's, and which rules should be applied Debian's or Arch's?
"Maybe, in the end, sharing information and knowledge is a bit harder to execute than it seems?"
Or ... instead of admitting something, we can also just find a scapegoat instead. Let's say bad coorporations somehow prevented it?
On the other hand, sharing information is easy.
The hard part is in trusting that information in the time and age of spam, propaganda and advertisers. And companies are quite secretive and don't want to share too much by default for other reasons.
Also it is way easier just do something to your own wiki, than coordinate with dozens of others where you share something.
I have many vague and some concrete ideas since a while about building trust right into the wiki system somehow, but never got around to actually implement something. Because ah well, I have to admit. It really ain't trivial after all, solving human trust.
> Let's say bad coorporations somehow prevented it?
How?
> On the other hand, sharing information is easy.
Not in the way we are talking about.
> The hard part is in trusting that information in the time and age of spam
No, it's not. We're talking here about moderated Knowledge bases. Of course, if it's a poor or even unmoderated wiki, this would be a problem. But I've never got the impression that Arch-wiki had this problem.
> don't want to share too much by default for other reasons.
Sharing what? This is about open source? Is this AI-slope? O_o
> Also it is way easier just do something to your own wiki, than coordinate with dozens of others where you share something.
Wikis work in a open way, if they are niche, to not attract trolls or spam too much, otherwise they work by restricting guest rights, banning ip, etc.
Usually pragmatically.
"No, it's not. We're talking here about moderated Knowledge bases. Of course, if it's a poor or even unmoderated wiki, this would be a problem. But I've never got the impression that Arch-wiki had this problem."
And arch wiki (and wikipedia itself) is a outlier, not the average wiki, that usually is outdated or plain wrong with no one caring.
I remember a while ago there was a small computer vision wiki that was very useful and somewhat widely used, not that many computer vision people at the time. Then, after around 2010 they decided to move the wiki to Wikipedia. You can guess what happened, original wiki was gone, very few articles survived because, of course, it's Wikipedia. A great resource just gone.
If the scope is too wide, then it's hard to see when content is outdated or irrelevant. The clear focus helps archwiki for example to not turn into a graveyard of obsolete howtos.
There are not just differences between distributions to consider, but also different distributions being on different versions of things. This would be difficult to organize.
In the case of Debian, they have a pretty different stance when it comes to what the role of a distro is compared to Arch.
Arch is essentially completely freeform; you, the user, are going to be making a lot of technical decisions on what you want your system to look like. It's perfectly okay for Arch to ship 4 different versions of the same type of tool, as long as all 4 are being used. The Arch wiki reflects this; it's focused around giving you a lot of options, while not going too in-depth on what you'd want to do with them. Want to swap out NetworkManager for wpa_supplicant because wpa_supplicant is easier to configure from a terminal? Perfectly fine, go ahead. Most arch packages as a result don't heavily deviate from upstream unless it's absolutely necessary to get them running.
Debian uh... isn't that. Debian still offers choice, but Debian has set the unenviable goal for themselves to provide a "stable" userland experience. This means Debian offers less options, but the options they do offer are also fixed on certain versions with sometimes pretty derivative versions compares to upstream. Their documentation as a result can get much more in-depth, just by virtue of having less to cover than Arch does.
A basic example here is setting up a webserver stack (so webserver, php and mysql); on Debian, you pick between apache2(+mod_php) or nginx/php-fpm and install mysql. Debian takes care of wiring all the permissions, user groups and all that stuff and giving you a "sane" default folder capable of serving PHP scripts on port 80 that anyone can use. It's a lot easier and nginx' configuration is specifically changed to resemble the apache2 vhosts. Arch doesn't do this; arch gives you the upstream versions of all these packages and then asks you to wire them together so that they work.
It means they attract pretty different audiences as a result; Debian users value stability/set and forget (also helped by Debian release cycles basically lasting the same length as most LTS releases of other distros), while Arch users are more conditioned to having to occasionally change their config files on updates.
That's also reflected in what their wikis aim at. Debian wikis generally can be version locked to their release; Arch wiki needs constant updating as things change.
They're different extremes here; most distros usually sit on one side or the other of this sorta thing (with the only real correlation being that dpkg-based distros usually lean more towards the Debian model), but there's also the pseudo-rolling release distros like Fedora, which try to offer similar stability to Debian but much shorter release cycles, so you'll always be running something at least close to the latest version.
> Their documentation as a result can get much more in-depth, just by virtue of having less to cover than Arch does.
But the entire point is how much better Arch's wiki is than anyone else's. I've never run Arch, I've only ever used Arch's wiki to help with Debian. Doing this ironically helps you keep in mind every weird Debianism to figure out how to apply what you're reading.
> it would be great to have a cross distribution wiki with separate sections for distribution-specific instructions where it makes sense.
This doesn't work as well as you think.
We did this in one large OSS project for documenting operations just for installs/setup/build/etc.
The problem is:
1. The list of differences get large fast if you aren't within the same family of OS like Debian/Ubuntu/Mint
2. Information will get out of date for some distros over others. Unhelpful pricks start bitching and moaning and nobody wants to deal with it at that point.
3. Unhelpful pricks will also bitch and moan you delete the out of date sections
What would be even better - just a single, unified distro. Imagine if all those man-hours where actually focused on delivering a single working and polished FOSS OS.
Then you get to handle all the same criticisms that are usually lobbed at MS Office: no single user ever needs more than 15% of the functionality, but still receives the additional baggage of the other 85% -- whether in terms of memory footprint, reduced performance or UI clutter. The ability of FOSS to be optimized for specific use cases is one of its biggest strengths, and that has nothing to do with "choice" itself, no matter how much you try to disparage it.
Except that a lot of FOSS ends up pulling in huge dependencies to use tiny parts of them, doesn't tree-shake (granted not all languages make this easy), vendors a specific version of something you already have that would work fine, etc.
It also includes the freedom to choose any product from the shelf in any store. But let's have a thought experiment - does the society that allows completely free consumption of material goods, but punishes any criticism against the government, economical policy etc. has more freedom than society that have some prohibition on consumption, yet allows free speech and political action?
There is more than one facet of freedom, and personally I care more about collective freedom of the people and it would be served better by having few, but more polished FOSS options when it comes down to technology.
> What you're proposing is actually making the Linux kernel and userland closed source and controlled by a company like Microsoft.
I am not proposing anything. I am saying we would all be better if FOSS contributors focused and consolidated their effort.
> There is simply no other way to get "one distro"
You are probably right, this is why I am pessimist.
I'm not sure I understand your position. You seem to be saying that allowing customization is bad for human freedom? Would you mind ELI5'ing that for me?
What is customization, if all you can customize are countless half-baked distros for tinkerers, teared through constant drama, ambitions of snowflake devs trying to make 100 competing solutions obsolete by introducing 101st, and forking, and, as a typical non-dev computer user, you are more and more dependent on adversary Big Techs?
If Cyberpunk dystopia ever comes, I am sure we still will be able to choose between GNOME and KDE, and there will be people saying that we are still good, for we have a choice.
You realize people do this for fun right? It’s fun to create your own distro (you should try it some time) and it’s fun to play with different ones as well.
Nobody wants Linux to be more like windows, and otherwise they’d just use windows.
> You realize people do this for fun right? It’s fun to create your own distro (you should try it some time) and it’s fun to play with different ones as well.
I do, and this is why FOSS cannot reach its political goals - it won't ensure user's freedom, for almost everyone involved today would rather chase their own satisfaction.
It already insures user freedom, and has for decades. The lecturing is a bad tone. You wouldn't even know this was possible if GNU, Debian, and Linux in general hadn't done it. They shaped your understanding of software.
I have no issue with GNU, Linux or Debian. The opposite, I am postulating that we would all be better if every one worked on those instead of creating yet another distro or grep clone, even if they provide their creators with satisfaction.
As for ensuring - how it is, that in 2025 AD we have more FOSS projects than ever, yet your typical computer user has less freedom and privacy than, let's say, in 2000 AD?
Bad take. If you can only ever improve what's there, there is no opportunity to try something new. For grep specifically, you can't much about its defaults, which makes "innovating" on its user experience very difficult.
The "political goals" are pretty fringe, to most people that enjoy FOSS, the goal is to get something that works for themselves and if other people don't like it, that's fine. Most people aren't RMS style revolutionaries trying to convert the global population to FOSS users. I admire that man, but his goals aren't my goals.
For that matter, if political victory were to be achieved in the way you've suggested, it would be utterly Pyrrhic. The only way to achieve a unified singular FOSS operating system that nobody forks or otherwise competes with would be to strip users of their freedoms to do so. So that's not a victory at all for the political side of FOSS.
You might conclude then that FOSS victory is impossible. I think so too, and that's fine. It doesn't stop FOSS from being useful to me and many other people. Some people will never use it, and that's fine.
But I didn't stated at any point I would like to prevent people from forking or starting something from scratch. I only stated that if FOSS contributors would focus their efforts more, we all would be in a better place.
That they won't, I agree, for, as this thread shows, libertarian and individualist ideas are stronger in this demographics. I also agree that FOSS is useful even in its current state, but being useful is not a goal of free software. Freedom is a political notion.
And common people do not need to care that much about free software ideas to consider political goals of the movement to be fulfilled, the same way today's workers do not need to care about socialist theory to enjoy workers rights.
Yep, and who cares about the FOSS OS part? We could combine Macos and Windows too! Think of all the money and time that could be saved by having a single global unified OS team!
I know, people have difference preferences, yada yada.
Some corporate entity will just take it over and Linux will just be another piece of software constantly trying to figure out ways to rob you.
Fragmentation, though ugly and inconvenient, works as a defense. systemd, along with all of the other goofy all-encompassing subsystems that were inflicted on Linux over one hot decade from Red Hat, was obviously a ploy to do the above. The jury is still out as to whether it will be successful.
But I believe there is a degree of fragmentation.
If the fragmentation would look like this that we have, for example, just Debian, Arch and Fedora, we would still have a choice and escape hatches, and I wouldn't complain, even if it would be less effective than single distro.
That's part of what systemd is supposed to do: make distros irrelevant by providing a uniform software base, after which redundant distros would wither and die, yielding a few main ones which are cross-compatible with one another in terms of how they are configured.
I"m still absolutely floored with how good the archwiki is. I can't hype it up enough. I really did't know what I was doing with systemd until I read that wonderful article, and also, the link to why the arch maintainer switched that distro to systemd made my accept the change to it.
When I was starting with Linux (15 years ago) with Fedora, Ubuntu, etc., for all of my questions I kept finding answers on the Arch wiki. So eventually I just switched to Arch, so the answers would always work.
That was an era when searching the Internet worked. Come to think of it, I haven't had Arch wiki pop up in my search results in years.
I kinda get the animosity now. I wasn't really using Linux at the time, but if I was, and my system was running great, and then I had a list of complicated instructions I had to perform to change my init system... I'd probably be peeved off.
The Arch wiki is the PostgreSQL documentation of Linux. Even if you're not using Arch or Postgres, it's a great starting point for how something is supposed to work and it covers enough details that you can extrapolate a bit.
Look at the "ArchWiki active users per month" graph. What happened in 2013? With the exception of the lockdown period, it has been decreasing since then.
I switched from Arch to NixOS and I know many others who did too. For users inclined to use a distro such as Arch, NixOS feels like the natural next step.
I’ve had to do very, very little to my Artix desktop since setting it up that I don’t think I’ll ever switch unless my life constraints changed significantly. NixOS seems like a lot to learn. I’m happy to be proven otherwise and know I’m not alone in becoming very complacent to my setup once getting to Arch.
Many people used Arch for its status as "the pro Linux distribution" i.e. not beginner friendly, but secretly still easy enough that you don't need much effort. That's how "I use Arch btw" became a meme.
> "the pro Linux distribution" i.e. not beginner friendly, but secretly still easy enough that you don't need much effort.
That's a common perception of Debian, perhaps even more than Arch. One difference being that Debian actually has a lot of notable use in production. It's also just as stable as any "LTS" distro, which is a welcome convenience for many beginners as well as more experienced users.
The meme is from 4chan and the /g/ board that had some origins around 2011/2012. Gentoo was the main meme before this.
After 2012'ish the meme-culture from 4chan became mainstream internet culture with the popularity of reddit. Nothing has really progressed beyond that.
I mean, I was using nobara and my brother had showed me arch once and it looked so cool and he used to say, " that I have ran arch" and so I was watching a lot more arch content / linux too so I decided to try it to be "good at linux"
Not many regrets aside from the times that I accidentally deleted my hard drives so many times that I can't count on fingers lol, its still a little fun lol. Ricing it with hyprland and I am truly happy with my system.
I also have nix but I couldn't really love it aside from the fact that nix-env is really really cool.
It's one the reasons I'm using Arch. Great features are worth little to me if I don't know about them. What I like particularly about the wiki is their why sections that explain why one would want to choose one way over another. A good example of this is the page on data-at-rest encryption [1].
> MediaWiki markup is different. It is weird and fragile; changing a single token can completely break a page. It is also, he said, difficult to write a proper or robust parser for the language.
Documentation is super important for complex things. I feel like it’s highly underrated by many otherwise great open source projects, to the severe detriment of the project. Nice to see an explicit focus on it.
Underrated in proprietary and non-software tech, too. It's horrible when infrequent tasks turn into bespoke shitshows every time they crop up because nobody wrote down how to solve the problem. Having to figure things out from scratch every time is ridiculously inefficient. Even worse if it leads to customers having slightly different copies of the same kind of software or device configuration because there's no documented process to follow. I know from experience.
> Where is it appropriate to post a subscriber link?
> Almost anywhere. Private mail, messages to project mailing lists, and blog entries are all appropriate. As long as people do not use subscriber links as a way to defeat our attempts to gain subscribers, we are happy to see them shared.
The occasional sharing of subscriber links in this way only does us good. If you enjoy the content, please subscribe and help ensure that there will be more of it!
They're usually shared links (note the 'share a free link' button at the bottom, above comments) ime - I've never seen it styled like this before. Weird that it's a subscriber-only link that doesn't require login, but does for other subscriber-only actions like sharing a free link or replying to a comment.
Joining lwn makes you a gatekeeper for lwn (and allows you to browse and comment on lwn), it doesn't simply allow you to be a reader of lwn. I'm sure their traffic has almost no relationship to their number of subscribers. Subscribers are just the people actively marketing the journalism. It's like a two-level pyramid scheme - you're spreading their journalism and looking smart, and 1/500 of the people you send it to become new subscribers.
This is really exciting. I've used the Arch Wiki countless times for setting up or configuring something in Debian but wanting a resource more native to the platform. I hope they're able to produce a comparable wiki for Debian-based OSes.
This seems heavy on self-promotion. Meanwhile, Arch is still x86-centric (in spite of fragmented, unofficial forks) and doesn't do LTS, while Debian supports multiple architectures and stability. Debian does have a lot of rambling, aspirationally-unfinished, outdated, and duplicated wiki pages.
I switched from Ubuntu to Arch because of the quality of the Arch wiki. Ubuntu search results were filled with so much misinformation that I realized it was a culture problem. Arch, with its higher barrier to entry, attracts users who maintain its standards.
The Arch Linux community is one of the most toxic I know. First and foremost, there are members with tens of thousands of posts who become condescending and insulting when other members don’t dance to their tune. The Code of Conduct exists only on paper and is not enforced by the Arch leadership. This results in such behavior not only being tolerated but actively encouraged. Shame on them and shame on Debian for further encouraging this behaviour by inviting them to the DebConf.
The Arch wiki is one of the best things the Linux community has produced. It's like a modern, improved and more complete version of TLDP.
I haven't even used Arch on any of my machines but can't count how many times I've found their wiki useful for my workstations, servers and even custom Yocto-built systems. Arch supports many ways of doing a thing, so whatever tool I'm dealing with, Arch probably supports that and documents it on the wiki. And Arch makes few changes from upstream so the wiki instructions are often applicable on any distro. Sure, it takes some familiarity to recognize when something is e.g. Debian-specific and should be done in a Debian way, but as a user fairly familiar with Linux, I often find Arch to be the best source of documentation.
I remember long before I started using Arch I would google something nuanced for Ubuntu and there it was on the Arch Linux wiki with a “for Ubuntu users do this” section to fix whatever my issue was, this happened multiple times.
The special instructions for other distros could be at risk for being deleted, as "something that will not work on Arch as-is is not something we will be hosting on our site".
Feels like someone needs to make a generic Linux wiki then.
I think one reason the arch wiki thrives is that it IS a generic linux wiki.
The arch wiki describes the upstream package.
I say this because Arch tries to use the upstream software as-is, and describes requirements and helps make configuration choices.
Other distributions tend to make the choices for you, configuring and modifying upstream to fit the distribution.
With respect to a wiki, this would be another layer of documentation to add. Describe the package, describe the distro, and explain the configuration choices.
The arch wiki could expand to support distro switching, with each distro having its own domain, and all that could link back to a general linux wiki. It'd be beautiful.
They already had it fine, now its out of their scope.
This sounds exactly like what we used to say about Gentoo back in its early days.
Yeah, the Arch wiki is the Gentoo wiki we lost. I was around for it and the Gentoo wiki was amazing, it was one of the best Linux resources all-around, it was tremendously useful even if you didn't use Gentoo.
This was still the case of Gentoo until they wiped/lost their wiki and didn't have proper backups.
When did this happen? I haven't seen anything about it online
From what I can gather, the event happened in 2008. At the time gentoo had no official wiki, it was an unofficial wiki that died or went offline for a significant amount of time.
<https://web.archive.org/web/20081023145740/http://www.gentoo...>
And when it came back online in november,
> Gentoo-Wiki recently had it's database lost; this is the rewrite of the site
<https://web.archive.org/web/20081204053828/http://en.gentoo-...>
After using FreeBSD and OpenBSD, it is frankly shocking how bad Linux documentation is in comparison. On the BSDs every command, every program, every system call, and every configuration file are thoroughly documented in man pages and other guides. The FreeBSD Handbook in particular is a treasure. It more than makes up for some of the more difficult aspects of the OS by providing thorough and approachable documentation.
It's a different model of development, leading to different expectations.
BSD ties the kernel and the software on top of it together pretty heavily, creating the expectation that the documentation should cover all of it.
Linux is meanwhile kernel and software kept separated, meaning that the documentation usually winds up assembled from separate tools, each with their own standards.
Yes, BSD is a single coherent system but so are many Linux distros. It's just that we've come to accept bad documentation as the norm for Linux-based tools. In my experience there's several types of problems that are very common for Linux tools:
* Extremely short documentation. Everyone has seen these, a tool where the man page exists but provides almost no actual information.
* Unfriendly reference-type documentation. GNU programs are often guilty of this, coreutils certainly comes to mind. On the upside, it's usually comprehensive. But it's not good - it's a short description followed by a sequential list of every option, so the functionality is described in detail but there are no usage examples, no list of the most common options, or anything like that. Great reference, poor usage documentation.
* Too much info about ancient systems or historical details. Yes, it's great that many of these utilities are portable and can run on different systems or work with files from different systems. The man pages for zip/unzip mention MS-DOS, Minix and Atari systems, while defining the zip format as "commonly found on MS-DOS systems". The man page for less explains that it's a program "similar to more(1)" - completely useless info now - and mentions that it has some support for hardcopy terminals, again information that's not important enough for the first paragraph in 2025.
* Poor keywords in the description. There's the theoretically useful apropos command. My Xorg wouldn't start so I tried to remember how to start my wifi up. apropos 'wlan|wi-fi|wifi|wireless' doesn't mention nmcli, which I was thinking of, though it does at least provide the much more difficult iw command.
* Technical project-specific jargon that makes it easy to find the solution - if you already know it, that is. For example, Xorg documentation generally doesn't use the word "resolution". It's not in the xrandr or Xserver man page, and in the xorg.conf page it's only a reference to virtual screens. Because X uses the term screen size. That's fine, understandable and even accurate but most people would first search for 'resolution'.
I for one really enjoy the historical anecdotes you get in the "NOTES", "PORTABILITY" or even "BUGS" sections. But I do realise that my context is mostly recreational, work doesn't really require glueing POSIX commands together.
Yep. There is no "Linux Operating System." There's the Linux Kernel, and that kernel is used in tons of different OSes. It's sounds like a small nitpick but its a huge deal and a common misconception for those outside of the Linux world anytime a topic of unifying something in the Linux world comes up.
A shared or central wiki sounds nice, but could quickly end up too messy. Arch having its own makes sense, as in the case of Linux - the distro is the operating system. Arch is a different OS from Fedora, which is a different OS from Ubuntu, etc. Sure, there's a lot of overlap but they are each their own unique OS.
Its consistent conventions also help a lot — it means learning a handful of things once, which can then be applied numerous other places (which as an aside, used to also be a strength of macOS). No need to even consult the manpage in many cases then.
An interesting but gargantuan project would be a Linux distro that maintains patches for all of its packages that standardize directory structures, config file locations, CLI argument order, etc.
I learned how to do NetBSD kernel hacking from just the man pages. They're still my first-line documentation on the NetBSD file system work I'm doing. The state of Linux documentation is appalling by contrast.
Came in here to say the same thing. NetBSD should get more love.
Practically speaking ArchWiki has everything I'm likely to need as a poweruser, but it's not really all that comprehensive.
Linux != software that runs on Linux. Those are two completely different things.
I don’t think anyone is confused about this. Linux is a shorthand for the family of Unix like operating systems that use Linux as the kernel. The only ambiguity in this shorthand is if android or chrome os are being referenced, but it’s pretty clear from context that they are not relevant to the discussion.
I can't agree more
Instead of creating multiple wikis with probably 80% of duplicate information between them, it would be great to have a cross distribution wiki with separate sections for distribution-specific instructions where it makes sense. Gentoo had a fantastic wiki before they lost it to disk array failure (IIRC) around ten years ago, now pretty much everyone is going to the Arch wiki, why not try to turn it into a shared project?
What matters in the long run for making a good wiki are the people and policies.
Young and niche wikis are happy to take any contributions they can get. The quality and timeliness of any given bit of text soon ends up wildly different from page to page or even section to section. Some people may decide to take their time not just contributing new content but also editing existing content. However, it becomes difficult to balance creation vs. curation. Too much creation, and the editors get overwhelmed, and then the users can never be sure what to trust, and so the wiki becomes irrelevant. Too much curation, and the information becomes uniformly stale and lowest-common-denominator, so the users start going elsewhere, and so the wiki becomes irrelevant.
Different wikis means each one can have its own people and policies. If the people who made one wiki great leave, there are still other wikis out there. If the policies choke the life out of one wiki, there are still other wikis out there. Some wiki can be full of deletionists while another wiki is full of inclusionists. Some wiki can be full of mergers while another wiki is full of splitters.
Forcing everybody onto one wiki forces them all to work together, but this is an entirely volunteer effort, and so many will just leave. Even if they were paid, some individuals would dominate while others would get crowded out. One can point to Wikipedia as a glaring exception, standing as basically the only wiki of note of its kind, but I think it's the exception that proves the rule.
Wikipedia is definitely the exception. It works because almost everyone on the Internet uses it.
And it's not without problems, not the least of with is that being the default Wiki attracts the kind of people would would love to control the definite source of information.
>Instead of creating multiple wikis with probably 80% of duplicate information between them
>why not try to turn it into a shared project?
This is basically both the highlight and the bane of the Linux world.
Why have another DE when there are already multiple ones? [0]
Why have another package manager when there are already multiple ones? [1]
Why have another distro when there are already multiple ones? [2]
So having another wiki makes perfect sense (or not depending on your POV)
0, https://en.wikipedia.org/wiki/Comparison_of_X_Window_System_...
1, https://en.wikipedia.org/wiki/List_of_software_package_manag...
2, https://distrowatch.com/dwres.php?resource=popularity
>Why make a green bikeshed when there's already a red bikeshed?
Because then you have two bikesheds. An important aspect of the fact that the bikeshed exists, as a separate entity not integrated with the house, is that you can choose a different one. Specifically, the one that's already painted the way you want.
Maybe you don't think this is a feature in your current circumstance. Others do, which is why it persists.
Bane? It's what makes the Linux desktop great. I get to choose a system that works like I want.
Imagine if there was only Gnome or whatever unholy monstrosity is the most popular DE these days.
If there were only one, someone would launch a new one within a week. Just how Linux is.
It probably just never worked out that way. Usually everyone starts with documenting the distro-specific parts first, and then adds more and more, until even general parts are there. But at the same time, everyone probably thinks that those general parts are supposed in the specific projects' documentation, so nobody really cares about sharing. Until the point is reached that some wiki is so big and successful, that it just silently took over the whole domain.
Also, the whole sharing somehow seems to have died off over the decades. 25+ years ago, when wiki was new and shiny and everyone was experimental and motivated, there were strong movements for interwiki-content, sharing stuff between them openly. Then time happened, not much sharing was done, and every wiki-software slowly moved on, doing their own thing, becoming some semi-open silo or even a closed garden.
And today we had this same movement arising in the knowledge management-community, around their tools, and mainly in the context of Markdown, and it also kinda died down and never turned into anything substantial. Maybe, in the end, sharing information and knowledge is a bit harder to execute than it seems?
I think the sharing is easy. The maintaining is hard when there isn't clear ownership. How do the teams divide maintenance duties? How are vandalism and moderation dealt with across teams? How do disagreements between teams over style and quality dealt with? Cost of hosting split?
All of these are possible to answer, but they are also much easier to deal with when you're not sharing between different organizations.
> I think the sharing is easy
The hard part about sharing is the different syntax of wikis, which could be slightly different even in the same wiki-software. Then there is the organization-part, and the sync-process itself.
Of course, today, 25 years later, we do have better solutions and much more experience for those problems.
> The maintaining is hard when there isn't clear ownership. How do the teams divide maintenance duties? How are vandalism and moderation dealt with across teams?
I would think those are pretty simply, as they all follow the same rules. I mean, handling vandalism isn't much different between Arch or Debian, it's always the same. And moderation really depends on the chosen sharing-mechanism. Which brings up again the hard part, just on a different level.
I think it's more of, let's say, unify the 2 wikis in one, what team should moderate Debian's or Arch's, and which rules should be applied Debian's or Arch's?
"Maybe, in the end, sharing information and knowledge is a bit harder to execute than it seems?"
Or ... instead of admitting something, we can also just find a scapegoat instead. Let's say bad coorporations somehow prevented it?
On the other hand, sharing information is easy. The hard part is in trusting that information in the time and age of spam, propaganda and advertisers. And companies are quite secretive and don't want to share too much by default for other reasons.
Also it is way easier just do something to your own wiki, than coordinate with dozens of others where you share something.
I have many vague and some concrete ideas since a while about building trust right into the wiki system somehow, but never got around to actually implement something. Because ah well, I have to admit. It really ain't trivial after all, solving human trust.
> Let's say bad coorporations somehow prevented it?
How?
> On the other hand, sharing information is easy.
Not in the way we are talking about.
> The hard part is in trusting that information in the time and age of spam
No, it's not. We're talking here about moderated Knowledge bases. Of course, if it's a poor or even unmoderated wiki, this would be a problem. But I've never got the impression that Arch-wiki had this problem.
> don't want to share too much by default for other reasons.
Sharing what? This is about open source? Is this AI-slope? O_o
> Also it is way easier just do something to your own wiki, than coordinate with dozens of others where you share something.
I don't think Arch-Wiki has only one maintainer.
"Sharing what? This is about open source?"
About sharing information in general.
Wikis work in a open way, if they are niche, to not attract trolls or spam too much, otherwise they work by restricting guest rights, banning ip, etc. Usually pragmatically.
"No, it's not. We're talking here about moderated Knowledge bases. Of course, if it's a poor or even unmoderated wiki, this would be a problem. But I've never got the impression that Arch-wiki had this problem."
And arch wiki (and wikipedia itself) is a outlier, not the average wiki, that usually is outdated or plain wrong with no one caring.
I remember a while ago there was a small computer vision wiki that was very useful and somewhat widely used, not that many computer vision people at the time. Then, after around 2010 they decided to move the wiki to Wikipedia. You can guess what happened, original wiki was gone, very few articles survived because, of course, it's Wikipedia. A great resource just gone.
I don't know if i agree. Good documentation is focused. If you try to cover everything it becomes dilluted and confusing.
If the scope is too wide, then it's hard to see when content is outdated or irrelevant. The clear focus helps archwiki for example to not turn into a graveyard of obsolete howtos.
> Instead of creating multiple wikis with probably 80% of duplicate information between them
Wikis do tend to link a lot across one another. On the Alpine Wiki, I prefer to link to the ArchWiki when applicable, rather than copy content over.
There are not just differences between distributions to consider, but also different distributions being on different versions of things. This would be difficult to organize.
In the case of Debian, they have a pretty different stance when it comes to what the role of a distro is compared to Arch.
Arch is essentially completely freeform; you, the user, are going to be making a lot of technical decisions on what you want your system to look like. It's perfectly okay for Arch to ship 4 different versions of the same type of tool, as long as all 4 are being used. The Arch wiki reflects this; it's focused around giving you a lot of options, while not going too in-depth on what you'd want to do with them. Want to swap out NetworkManager for wpa_supplicant because wpa_supplicant is easier to configure from a terminal? Perfectly fine, go ahead. Most arch packages as a result don't heavily deviate from upstream unless it's absolutely necessary to get them running.
Debian uh... isn't that. Debian still offers choice, but Debian has set the unenviable goal for themselves to provide a "stable" userland experience. This means Debian offers less options, but the options they do offer are also fixed on certain versions with sometimes pretty derivative versions compares to upstream. Their documentation as a result can get much more in-depth, just by virtue of having less to cover than Arch does.
A basic example here is setting up a webserver stack (so webserver, php and mysql); on Debian, you pick between apache2(+mod_php) or nginx/php-fpm and install mysql. Debian takes care of wiring all the permissions, user groups and all that stuff and giving you a "sane" default folder capable of serving PHP scripts on port 80 that anyone can use. It's a lot easier and nginx' configuration is specifically changed to resemble the apache2 vhosts. Arch doesn't do this; arch gives you the upstream versions of all these packages and then asks you to wire them together so that they work.
It means they attract pretty different audiences as a result; Debian users value stability/set and forget (also helped by Debian release cycles basically lasting the same length as most LTS releases of other distros), while Arch users are more conditioned to having to occasionally change their config files on updates.
That's also reflected in what their wikis aim at. Debian wikis generally can be version locked to their release; Arch wiki needs constant updating as things change.
They're different extremes here; most distros usually sit on one side or the other of this sorta thing (with the only real correlation being that dpkg-based distros usually lean more towards the Debian model), but there's also the pseudo-rolling release distros like Fedora, which try to offer similar stability to Debian but much shorter release cycles, so you'll always be running something at least close to the latest version.
> Their documentation as a result can get much more in-depth, just by virtue of having less to cover than Arch does.
But the entire point is how much better Arch's wiki is than anyone else's. I've never run Arch, I've only ever used Arch's wiki to help with Debian. Doing this ironically helps you keep in mind every weird Debianism to figure out how to apply what you're reading.
> it would be great to have a cross distribution wiki with separate sections for distribution-specific instructions where it makes sense.
This doesn't work as well as you think.
We did this in one large OSS project for documenting operations just for installs/setup/build/etc.
The problem is:
1. The list of differences get large fast if you aren't within the same family of OS like Debian/Ubuntu/Mint
2. Information will get out of date for some distros over others. Unhelpful pricks start bitching and moaning and nobody wants to deal with it at that point.
3. Unhelpful pricks will also bitch and moan you delete the out of date sections
What would be even better - just a single, unified distro. Imagine if all those man-hours where actually focused on delivering a single working and polished FOSS OS.
I know, FOSS is all about choice, yada yada.
Then you get to handle all the same criticisms that are usually lobbed at MS Office: no single user ever needs more than 15% of the functionality, but still receives the additional baggage of the other 85% -- whether in terms of memory footprint, reduced performance or UI clutter. The ability of FOSS to be optimized for specific use cases is one of its biggest strengths, and that has nothing to do with "choice" itself, no matter how much you try to disparage it.
Except that a lot of FOSS ends up pulling in huge dependencies to use tiny parts of them, doesn't tree-shake (granted not all languages make this easy), vendors a specific version of something you already have that would work fine, etc.
And I thought that free software is about human freedom.
Well, enjoy your optimized memory consumption instead.
Human freedom includes the freedom to fork.
What you're proposing is actually making the Linux kernel and userland closed source and controlled by a company like Microsoft.
There is simply no other way to get "one distro"
> Human freedom includes the freedom to fork.
It also includes the freedom to choose any product from the shelf in any store. But let's have a thought experiment - does the society that allows completely free consumption of material goods, but punishes any criticism against the government, economical policy etc. has more freedom than society that have some prohibition on consumption, yet allows free speech and political action?
There is more than one facet of freedom, and personally I care more about collective freedom of the people and it would be served better by having few, but more polished FOSS options when it comes down to technology.
> What you're proposing is actually making the Linux kernel and userland closed source and controlled by a company like Microsoft.
I am not proposing anything. I am saying we would all be better if FOSS contributors focused and consolidated their effort.
> There is simply no other way to get "one distro"
You are probably right, this is why I am pessimist.
I'm not sure I understand your position. You seem to be saying that allowing customization is bad for human freedom? Would you mind ELI5'ing that for me?
See my reply to sibling comment.
What is customization, if all you can customize are countless half-baked distros for tinkerers, teared through constant drama, ambitions of snowflake devs trying to make 100 competing solutions obsolete by introducing 101st, and forking, and, as a typical non-dev computer user, you are more and more dependent on adversary Big Techs?
If Cyberpunk dystopia ever comes, I am sure we still will be able to choose between GNOME and KDE, and there will be people saying that we are still good, for we have a choice.
You realize people do this for fun right? It’s fun to create your own distro (you should try it some time) and it’s fun to play with different ones as well.
Nobody wants Linux to be more like windows, and otherwise they’d just use windows.
> You realize people do this for fun right? It’s fun to create your own distro (you should try it some time) and it’s fun to play with different ones as well.
I do, and this is why FOSS cannot reach its political goals - it won't ensure user's freedom, for almost everyone involved today would rather chase their own satisfaction.
It already insures user freedom, and has for decades. The lecturing is a bad tone. You wouldn't even know this was possible if GNU, Debian, and Linux in general hadn't done it. They shaped your understanding of software.
I have no issue with GNU, Linux or Debian. The opposite, I am postulating that we would all be better if every one worked on those instead of creating yet another distro or grep clone, even if they provide their creators with satisfaction.
As for ensuring - how it is, that in 2025 AD we have more FOSS projects than ever, yet your typical computer user has less freedom and privacy than, let's say, in 2000 AD?
Bad take. If you can only ever improve what's there, there is no opportunity to try something new. For grep specifically, you can't much about its defaults, which makes "innovating" on its user experience very difficult.
I'm glad ripgrep exists and also glad grep itself doesn't try to parse .gitingore
The "political goals" are pretty fringe, to most people that enjoy FOSS, the goal is to get something that works for themselves and if other people don't like it, that's fine. Most people aren't RMS style revolutionaries trying to convert the global population to FOSS users. I admire that man, but his goals aren't my goals.
For that matter, if political victory were to be achieved in the way you've suggested, it would be utterly Pyrrhic. The only way to achieve a unified singular FOSS operating system that nobody forks or otherwise competes with would be to strip users of their freedoms to do so. So that's not a victory at all for the political side of FOSS.
You might conclude then that FOSS victory is impossible. I think so too, and that's fine. It doesn't stop FOSS from being useful to me and many other people. Some people will never use it, and that's fine.
But I didn't stated at any point I would like to prevent people from forking or starting something from scratch. I only stated that if FOSS contributors would focus their efforts more, we all would be in a better place.
That they won't, I agree, for, as this thread shows, libertarian and individualist ideas are stronger in this demographics. I also agree that FOSS is useful even in its current state, but being useful is not a goal of free software. Freedom is a political notion.
And common people do not need to care that much about free software ideas to consider political goals of the movement to be fulfilled, the same way today's workers do not need to care about socialist theory to enjoy workers rights.
>I admire that man,
He's a pdf file, there's not much to admire.
That would be horrible.
Yep, and who cares about the FOSS OS part? We could combine Macos and Windows too! Think of all the money and time that could be saved by having a single global unified OS team!
I know, people have difference preferences, yada yada.
> We could combine Macos and Windows too!
It wouldn't produce a FOSS OS, as they are not FOSS.
Try more.
Some corporate entity will just take it over and Linux will just be another piece of software constantly trying to figure out ways to rob you.
Fragmentation, though ugly and inconvenient, works as a defense. systemd, along with all of the other goofy all-encompassing subsystems that were inflicted on Linux over one hot decade from Red Hat, was obviously a ploy to do the above. The jury is still out as to whether it will be successful.
But I believe there is a degree of fragmentation. If the fragmentation would look like this that we have, for example, just Debian, Arch and Fedora, we would still have a choice and escape hatches, and I wouldn't complain, even if it would be less effective than single distro.
That's part of what systemd is supposed to do: make distros irrelevant by providing a uniform software base, after which redundant distros would wither and die, yielding a few main ones which are cross-compatible with one another in terms of how they are configured.
I"m still absolutely floored with how good the archwiki is. I can't hype it up enough. I really did't know what I was doing with systemd until I read that wonderful article, and also, the link to why the arch maintainer switched that distro to systemd made my accept the change to it.
When I was starting with Linux (15 years ago) with Fedora, Ubuntu, etc., for all of my questions I kept finding answers on the Arch wiki. So eventually I just switched to Arch, so the answers would always work.
That was an era when searching the Internet worked. Come to think of it, I haven't had Arch wiki pop up in my search results in years.
Both Kagi and DuckDuckGo have search bangs (!aw) to search ArchWiki articles. I also have ArchWiki boosted in my Kagi settings.
almost the same reason i started using arch: i wanted to install linux into my macbook, and the only wiki with enough info to make it work was arch's.
Sounds worth reading. Is this the article you mean? https://wiki.archlinux.org/title/Systemd
That's the systemd article, and this is the forum post explaining why arch moved to systemd: https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530
https://archive.is/Mi9DP
Scroll down to the long post by tomegun.
I kinda get the animosity now. I wasn't really using Linux at the time, but if I was, and my system was running great, and then I had a list of complicated instructions I had to perform to change my init system... I'd probably be peeved off.
I shall edit more in the Wiki and post less here.
The Wiki is the stronghold of Arch. As are the the packages. A lot of stuff makes good things good is a lot manual labor by all involved people.
PS: Removing stuff or not accepting changes is also a significant part of the Wiki. It hurts, as usual. But necessary for readability.
Hopefully they share it with NixOS next
Nix in general has some of the worst documentation I've ever encountered.
The Arch wiki is the PostgreSQL documentation of Linux. Even if you're not using Arch or Postgres, it's a great starting point for how something is supposed to work and it covers enough details that you can extrapolate a bit.
Look at the "ArchWiki active users per month" graph. What happened in 2013? With the exception of the lockdown period, it has been decreasing since then.
A spike in pages needing updates for the systemd migration which started in 2012 returned to a more normal level.
In recent years, NixOS has probably taken some of their enthusiast base too
I switched from Arch to NixOS and I know many others who did too. For users inclined to use a distro such as Arch, NixOS feels like the natural next step.
I’ve had to do very, very little to my Artix desktop since setting it up that I don’t think I’ll ever switch unless my life constraints changed significantly. NixOS seems like a lot to learn. I’m happy to be proven otherwise and know I’m not alone in becoming very complacent to my setup once getting to Arch.
Many people used Arch for its status as "the pro Linux distribution" i.e. not beginner friendly, but secretly still easy enough that you don't need much effort. That's how "I use Arch btw" became a meme.
These people have now moved to NixOS.
> "the pro Linux distribution" i.e. not beginner friendly, but secretly still easy enough that you don't need much effort.
That's a common perception of Debian, perhaps even more than Arch. One difference being that Debian actually has a lot of notable use in production. It's also just as stable as any "LTS" distro, which is a welcome convenience for many beginners as well as more experienced users.
> That's how "I use Arch btw" became a meme.
Not really.
The meme is from 4chan and the /g/ board that had some origins around 2011/2012. Gentoo was the main meme before this.
After 2012'ish the meme-culture from 4chan became mainstream internet culture with the popularity of reddit. Nothing has really progressed beyond that.
> These people have now moved to NixOS.
[citation needed]
I mean, I was using nobara and my brother had showed me arch once and it looked so cool and he used to say, " that I have ran arch" and so I was watching a lot more arch content / linux too so I decided to try it to be "good at linux"
Not many regrets aside from the times that I accidentally deleted my hard drives so many times that I can't count on fingers lol, its still a little fun lol. Ricing it with hyprland and I am truly happy with my system.
I also have nix but I couldn't really love it aside from the fact that nix-env is really really cool.
2013 is around the time Manjaro got popular.
Arch also locked down their forum posts due to popularity in 2011.
https://bbs.archlinux.org/viewtopic.php?id=113819
The baseline has been covered and there's not as much to write about anymore?
It's one the reasons I'm using Arch. Great features are worth little to me if I don't know about them. What I like particularly about the wiki is their why sections that explain why one would want to choose one way over another. A good example of this is the page on data-at-rest encryption [1].
[1] https://wiki.archlinux.org/title/Data-at-rest_encryption
> MediaWiki markup is different. It is weird and fragile; changing a single token can completely break a page. It is also, he said, difficult to write a proper or robust parser for the language.
Good thing mwparserfromhell exists, then.
On the topic of Arch wiki, I know there are a couple of offline and cli / tui solutions. Which do you use and recommend?
Documentation is super important for complex things. I feel like it’s highly underrated by many otherwise great open source projects, to the severe detriment of the project. Nice to see an explicit focus on it.
Underrated in proprietary and non-software tech, too. It's horrible when infrequent tasks turn into bespoke shitshows every time they crop up because nobody wrote down how to solve the problem. Having to figure things out from scratch every time is ridiculously inefficient. Even worse if it leads to customers having slightly different copies of the same kind of software or device configuration because there's no documented process to follow. I know from experience.
For lwn.net articles, aren't these subscriber-only links meant to be used only by the subscriber? Is sharing them on HN sabotaging lwn?
https://lwn.net/op/FAQ.lwn#slinks
> Where is it appropriate to post a subscriber link?
> Almost anywhere. Private mail, messages to project mailing lists, and blog entries are all appropriate. As long as people do not use subscriber links as a way to defeat our attempts to gain subscribers, we are happy to see them shared.
The occasional sharing of subscriber links in this way only does us good. If you enjoy the content, please subscribe and help ensure that there will be more of it!
It’s a feature. I actually ended up subscribing to LWN precisely because of the quality of these types of articles.
They're usually shared links (note the 'share a free link' button at the bottom, above comments) ime - I've never seen it styled like this before. Weird that it's a subscriber-only link that doesn't require login, but does for other subscriber-only actions like sharing a free link or replying to a comment.
>The following subscription-only content has been made available to you by an LWN subscriber.
It's literally a feature.
Joining lwn makes you a gatekeeper for lwn (and allows you to browse and comment on lwn), it doesn't simply allow you to be a reader of lwn. I'm sure their traffic has almost no relationship to their number of subscribers. Subscribers are just the people actively marketing the journalism. It's like a two-level pyramid scheme - you're spreading their journalism and looking smart, and 1/500 of the people you send it to become new subscribers.
This is really exciting. I've used the Arch Wiki countless times for setting up or configuring something in Debian but wanting a resource more native to the platform. I hope they're able to produce a comparable wiki for Debian-based OSes.
I went to install debian recently, but ended up with ubuntu because debian docs were so convoluted. Could not find the minimal iso I was looking for
I hope debian sees improvement here with this announcement
> We are still quite a small wiki compared to Wikipedia
A small intermediate goal for ArchWiki
It's great to see such inter-project information sharing and cooperation!
I found myself on Arch Wiki for so many non-Arch issues that I decided that I'll just install Arch and use it.
This seems heavy on self-promotion. Meanwhile, Arch is still x86-centric (in spite of fragmented, unofficial forks) and doesn't do LTS, while Debian supports multiple architectures and stability. Debian does have a lot of rambling, aspirationally-unfinished, outdated, and duplicated wiki pages.
I switched from Ubuntu to Arch because of the quality of the Arch wiki. Ubuntu search results were filled with so much misinformation that I realized it was a culture problem. Arch, with its higher barrier to entry, attracts users who maintain its standards.
The Arch Linux community is one of the most toxic I know. First and foremost, there are members with tens of thousands of posts who become condescending and insulting when other members don’t dance to their tune. The Code of Conduct exists only on paper and is not enforced by the Arch leadership. This results in such behavior not only being tolerated but actively encouraged. Shame on them and shame on Debian for further encouraging this behaviour by inviting them to the DebConf.
Make a wiki with Markdown syntax and GIT backend.
I wonder how well git scales as a backend. Access patterns of wikis seem kind of different than software.
These are a dime a dozen. Jet non of them has any significant share in the pure wiki space
Name a few of them.
https://duckduckgo.com/?q=markdown+based+wiki
People can't name them off the top of their heads, exactly because none of them have caught on. But they're easy to find.