an idea - universal Unix FAQ

i think this belongs in /tech/ more than /lambda/ (LC is the only place i can think of to share this idea with) there's this concept ive been cooking for a while now, the idea of essentially mitigating the various things that could go wrong whenever one installs and uses a *nix operating system that wasn't bolted down to its bare necessities and thoroughly tested you know what im talking about, people trying out Linux for the first time, booting it up and half their computer no longer works or an innocent update bricking their computer in unexpected ways oddest of all odd combinations of configurations that can make your OS behave like you want it to or become unusable - the camel that broke the strawman's back for me personally was the fact that a certain combination of thinkpad model and touchpad drivers result in extremely imprecise pointer movements (how do you even approach figuring this one out for soykaf sake? (i disabled the trackpoint, seems to work ok)) -- so i was thinking of like a universal diagnostic/configuration type of tool which you could download and access from both a GUI and a TTY and it'd make configuration and repair a bit saner ... but it's too much, really, and where would one even start? so first, then, one needs to have information of all the various things that can be configured, misconfigured, and all entire combinatorial explosion of things that can go wrong; so i propose a standardized information repository, a "universal unix FAQ" ("uuf" for short (name is very obviously a WIP)) where this information can be stored/kept in an obvious pattern having an obvious pattern would drastically help if i for example would be able to frequently update this FAQ/knowledgebased on my own computer then if anything goes wrong with it i can find out what happened and why

>>87586 i made a repo for it https://github.com/xapoc/universal-unix-faq also while typing this out i realized there should be a pattern for *which* version of some software has a problem when interacting with *which* version of some other software, so like info/category/something/v1.2.3/interactions/another-thing/v5.5/... nb

I think its better to contribute to the already existing distro wikis (arch/gentoo/debian/nixos) than attempt to create yet another universal standard that just leads to more fragmentation. Many non-arch users already rely on the arch wiki.

>>87591 ah but consider this: somrthing's broken and you have no internet connection. arch wiki can't help. is there an already existing standard for this kind of stuff?

I like the idea, and I can also see why it is not realizable, at least not exactly the way you expect it to be. I like it because the gentoo/arch wikis are inevitably tied to a specific distribution. They are certainly valuable, but they are not so general as to work for every user. I am a different type of user who likes to try niche distros and runs into trouble with essential linux components, such as bootloaders, the kernel itself, init systems, X11, etc. I understand this would be very difficult to realize because the problems that can affect users are truly innumerable. Then there are versioning issues, and so on and so forth. Still, an attempt would be nice, one that is not tied to specific distributions but provide a good troubleshooting guide to many topics not usually covered by the more user-oriented wikis. A sort of "expert system" could be developed that can help navigate these problems. I imagine all of this would be enormous work. Generating a documentation tree for a particular user's (expected) configuration to be stored locally would also be great. That way if I my system uses, say, syslinux and sysvinit, I wouldn't need to have the documentation for grub and systemd in my doc tree. If I can't connect to the network because my OS broke, it would be very helpful to have it stored on disk. Of course, there are manpages for that, but the idea is to help navigate issues in a way which manpages alone would be of little help. A sort of error message reference would probably be the first thing anybody would resort to: paste an error from dmesg and have a regexp look it up (or your expert system if you go that route) and bring up the relevant pages in the relevant sections. Again, the problems one may run into are potentially infinite, as there are a soykafload of subsystems these days. But starting from a core of the most used components: the bootloader, kernel, init system, graphics server, along with filesystem and network issues, would probably be a good place to start and extremely helpful. I wish I had enough knowledge of anything to be able to contribute at all.

>>87594 >Generating a documentation tree for a particular user's (expected) configuration to be stored locally would also be great. That way if I my system uses, say, syslinux and sysvinit, I wouldn't need to have the documentation for grub and systemd in my doc tree. If I can't connect to the network because my OS broke, it would be very helpful to have it stored on disk. i had a worse idea for approaching this, to somehow compress and decompress the entire thing on-demand, as it could likely grow into many gigabytes in size. yours is better. slices. >the problems one may run into are potentially infinite yep, this evolved from a smaller idea of making a blog post whenever i run into a problem and in like 3-4 years i'd have a sizeable knowledgebase to look up if i stumble upon a similar/same problem then i realized why not make the blog collaborative and distributed, as well as offline first. that way you can have a standardized FAQ of sorts. for each markdown file i'm thinking of a format like # <insert title here /> <insert issue description here /> ## Solution <insert the solution issue />

>>87593 that's why, when you have Internet access, you install Kiwix and download a copy of the Arch Wiki for it https://library.kiwix.org/#lang=eng&q=arch

Universal may be a lot, but having a package with html doc's about basic Linux troubleshooting in every distro would be great.

>>87614 didn't reply immediately because for a while i was thinking this is better than what im proposing HOWEVER it's not minimal enough kiwix is amazing though, thanks for the info! perhaps converting data from/to it would be beneficial >>87653 this xkcd has - over time - become blatantly harmful. sure juglging tonnes of flavors of similar standards isn't productive, but not having standards for things is much much more harmful in my personal experience the best tech i come across is built from the ground up, by combining different standards to accomplish novel goals

>>87586 It would be better if it was distributed as man-page(s) or texinfo (easy offline use). I recommend using Perl + POD + pod2man or Asciidoc(tor). >https://perldoc.perl.org/perlpod >https://perlmaven.com/pod-plain-old-documentation-of-perl

>>88181 Another idea: make a new Fortune file that has "tip of the day" -style hints. The file format seems easy: https://github.com/shlomif/fortune-mod/blob/master/fortune-mod/datfiles/perl

>>87659 id like this. it's simple, and most of the work's already done. it would save a ton of time and headache for people with garbage download speed whatever the reason for that may be.