Live data from Hacker News

I love the work of the ArchWiki maintainers

k7r.eu

151–160 of 177 posts

Re: I love the work of the ArchWiki maintainers

#151
post #130

Earlier quoted context omitted.

unfortunately there's a trend lately where many newer cli tools don't have a man page. they put up a --help and think it suffices even though there are tools to automatically generate man pages those days

I suspect a significant amount of that is due to requiring more than one file (the binary itself) and having to learn about multiple packaging and distribution systems. That's a gigantic wall to climb compared to "put a binary on github"

A lot of developers today want to play the maintener role as well. Where the idiomatic way is to publish source, docs about building and let other people take over distribution. Software like emacs and vim just publish a tarball.

Re: I love the work of the ArchWiki maintainers

#152

Earlier quoted context omitted.

I've contributed 32 edits (1 new page) in the past 10 years, so despite being stable, there are still many things to add and fix! Sadly, the edit volume will likely drop as LLMs are now the preferred source for technical Linux info/everything...

They may be preferred, but in a lot of cases they’re pretty terrible. 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!

Arguing with an LLM is silly because you’re dealing with two adversarial effects at once:

- 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

Re: I love the work of the ArchWiki maintainers

#153
post #114
post #85

Very useful because the information is almost distribution agnostic as Arch will stick to upstream as much as possible; or at least that's my impression as Debian user reading their wiki. Also: isn't the Arch wiki the new Gentoo wiki? Because that was the wiki early 2000s and, again, I've never used Gentoo!

I get the sense the Arch wiki pages has more detail than the man pages themselves. 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.

Anecdotally the arch wiki expands on the vauge man pages, often with examples for cases actually used by people. And they are much more easily accessible to modify and have instant gratification of publishing changes. Publishing to upstream man pages of a project, need to wait for it to trickle down.

Re: I love the work of the ArchWiki maintainers

#155

I learned linux by using Arch back in the days when pacman -Syu was almost certain to break something and there was a good chance it would break something unique to your install. This was also back in the days when most were not connected to the internet 24/7 and many did not have internet, I updated when I went to the library which was generally a weekly thing but sometimes it be a month or two and the system breaka…

>>Something was lost by Arch becoming stable and not breaking regularly Only a Linux user would consider the instability of a Linux distro to be a good thing.

It is the sort of mentality required to reach the place in computing which linux has. Decent chance you have linux running on something you own even if you do not run it on your computer and even if you don't, you do use the internet.

Re: I love the work of the ArchWiki maintainers

#156

Earlier quoted context omitted.

> Also: isn't the Arch wiki the new Gentoo wiki? Because that was the wiki early 2000s and, again, I've never used Gentoo! It is, didn't Gentoo suffer some sort of data loss which made it lose its popularity?

Gentoo's source based approach was always destined to be less popular than a precompiled distro. Compile times & customization options select for a certain clientele.

I think the reference was to Gentoo's wiki, which was indeed hacked and lost data iirc.

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.

Re: I love the work of the ArchWiki maintainers

#157
post #8

Their wiki is what sold me on Arch. I ended up there solving most of my problems on other distros, and if they can make such a fine wiki, I figured they could make a great OS (which they did).

Yep. Wiki and AUR completeness are hard to pass by.

Re: I love the work of the ArchWiki maintainers

#158

Earlier quoted context omitted.

> Also: isn't the Arch wiki the new Gentoo wiki? Because that was the wiki early 2000s and, again, I've never used Gentoo! It is, didn't Gentoo suffer some sort of data loss which made it lose its popularity?

Gentoo's source based approach was always destined to be less popular than a precompiled distro. Compile times & customization options select for a certain clientele.

All my machines still run Gentoo (I have used it for over 25 years). I just love the package manager. It has become much more low friction with the binary packages and gentoo-kernel(-bin). I regularly visit both the Gentoo and Arch documentation. They even cross reference each other and both are a great resource.

Re: I love the work of the ArchWiki maintainers

#159
post #16

Earlier quoted context omitted.

unfortunately there's a trend lately where many newer cli tools don't have a man page. they put up a --help and think it suffices even though there are tools to automatically generate man pages those days

I should write a tool that converts help output to troff, even if the result wouldn't be as detailed and nice to read as a good man page it would save me the frustration of having to stab at "will i get usage docs with a -h, a --help, a -help, or running it with no args at all".

It always struck me as a missed opportunity not to set a standard of `--man` for man page output from everything. GNU could have done that instead of their `info` nonsense.

Re: I love the work of the ArchWiki maintainers

#160
post #114
post #85

Very useful because the information is almost distribution agnostic as Arch will stick to upstream as much as possible; or at least that's my impression as Debian user reading their wiki. Also: isn't the Arch wiki the new Gentoo wiki? Because that was the wiki early 2000s and, again, I've never used Gentoo!

I get the sense the Arch wiki pages has more detail than the man pages themselves. 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.

Arch wiki is far better than most man pages. I've referred to Arch for my own non-Arch systems and when building Yocto systems. Most Arch info applies.

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.

Post reply on HN