Live data from Hacker News

I love the work of the ArchWiki maintainers

k7r.eu

121–130 of 177 posts

Re: I love the work of the ArchWiki maintainers

#121

Earlier quoted context omitted.

NixOS. Having a config-defined system is a bit too different at first, but really nice when it comes to system reproducibility, and being able to roll back. 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 t…

Nix Flakes are around for years and still experimental?

Yup. I wish they graduate soon, they have been great for a long while. I'm not sure what's blocking them today.

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.

Re: I love the work of the ArchWiki maintainers

#122
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.

Most man pages are written for someone who knows pretty precisely what they want to do, but don't recall which nobs to turn in the program to get that done. The Arch wiki instead focuses on someone who has a vague idea of what tools to use but doesn't know how those tools operate.

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.

Re: I love the work of the ArchWiki maintainers

#124
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".

As others have mentioned, such tools exist. However, I believe they do more harm than help. Good --help output does not make for good --man output. In particular, while man pages are terse, good ones are more than just lists of command line options, and the part of them that are a list of command line options will usually have more detail than --help. The writing of documentation is a place where I often see programmers employ automation inappropriately.

Re: I love the work of the ArchWiki maintainers

#126
I agree. It reads like a cook book rather than a dictionary of tech specs. No spam getting in in the way of getting things running and getting things right; If you need details you can go to individual package docs from maintainers and project docs from devs, no need for misaligned redundancy. It is also pretty comprehensive, or at least I have not missed anything yet. And up to date. So, in my opinion, the best distro documentation I know of. And I like their community process too: The most trustworthy and reliable I have seen so far without a big corporation backing it up, except for maybe Debian. Let's keep the donations going, these good people deserve it!

Re: I love the work of the ArchWiki maintainers

#127

Earlier quoted context omitted.

I have started using Arch in 2016 and it was stable back then. Are you describing an earlier era?

Not OP, but used Arch for a while in 2011, and at some point doing an update moved /bin to /usr/bin or something like that and gave me an unbootable system. This was massive inconvenience and it took me many hours to un-hose that system, and I switched to Ubuntu. The Ubuntu became terrible with snaps and other user hostile software, so I switched to PopOS, then I got frustrated with out of date software and Cosmic be…

Arch + KDE is pretty sweet. It looks gorgeous out of the box, and gives you a system that mostly just works but is still everything you love about Arch

Re: I love the work of the ArchWiki maintainers

#128

Earlier quoted context omitted.

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!

Why would you bother arguing with an LLM? If you know the answer, just walk away and have a better day. It is not like it will learn from your interaction.

The Gell-Mann effect? If you can't trust LLM to assist with troubleshooting in the domain one is very familiar (mdadm), then why trust it in another that one is less familiar such as zfs or k8s?

Re: I love the work of the ArchWiki maintainers

#130

I also find myself using https://man.archlinux.org/ a lot. It's much more readable/user-friendly than https://man7.org plus it contains man-pages from their `extra` repo which contains a lot of popular oss tooling.

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"
Post reply on HN