You must log in or # to comment.
I once read the first 3 chapters of the Git book and my coworkers think I’m some kind of Git wizard
One of the first things I did at my first full time job (while my very under prepared boss was looking for “junior-dev-friendly” tasks for me to work) was go to git-scm.com and just read through all the man pages I could. I spent a few days doing that, then my boss asked me to create a PowerPoint and present what I learned to the team. It was instantly apparent that I was the only one who knew anything beyond
git commit -aon the team at that point, and I was promptly appointed the “title” of “source control SME”. I’ve been heading up version control best practices for every team I’ve been on since (which is scary because the git cli has changed quite a bit since I read all those man pages but I haven’t had a chance to go back and refresh my knowledge).These days I just ask llm to fork me a branch and whatever else I need :p
Do you have a blog or something? Do you write about your experiences regarding this?
Lol no, the most writing I do is comments on Lemmy
Literally same 💀
I think LBD is the other half of it. If you have the confidence to try and fix or build something you Learn By Doing it. That eventually compounds and you could pretty much do anything. Maybe takes a bit longer than a professional would do it. A great shortcut would be to RTFM
After a while it’s basically muscle memory so you don’t have to go digging as much. OpenBSD’s are my favorite. So well-written.
Yea I run OpenBsd on my VPS. So much nicer than having to wonder where this particular Linux distro decided to keep this particular config file.
devdocs.io is beloved.
I don’t Linux (yet), but I do work in Audio Production. I LIVE for good manuals. I always read them, and because of that, I’m always working from a starting line of intelligence with new gear. I keep manuals in pdf format on my computer in like borderline autistic order. RTFM is the best piece of advice anyone can have, ever.
I too, work in audio production, and keep a meticulously organized folder of manuals. I love products that still ship with a physical printed manual, especially the spiral bound ones.
The idea that manuals in linux are a good way to learn and understand new software is peak linux neckbeard bs, and I will die on this hill. I congratulate OP on the exact type of autism that lets them feel this is an effective and useful method for learning new software, but if there is desire to have a greater adoption of linux maybe its bad to be snarky at folks for not instantly understand the terminal based documentation conventions of some dudes in the 70s. Maybe an alphabetical* list of all possible options is okay for referencing or searching, but is objectively insane way to learn or understand a problem.
as a professional sociotechnical problem solver I will join you on this fatal hill
like take the 4 types of documentation in diátaxis
manpages usually fulfill the reference need, and sometimes kind of that of how-to guides if you’re lucky and your localmanhas examplesbut that leaves more than 50% of documentation needs lacking
and discoverability is atrocious – you have to already know that the command (or commands) you need exists and what it’s called
one of the most useful things I learned in a linux sysadmin course was
apropos/man -k, which lets you search installedmanpages by keyword. but hardly anyone else seems to know about it – I only learned of it because a teaching assistant mentioned it off hand! – and even then it only helps if you guess the right keyword for your problemI am vexed by this situation
I think it should be the default if you don’t use parameters. A little usage help and the list of commands (with a “do you want to see the list of commands? (Y/n)” message)
People don’t know about man -k because of all the man pages they should have read, they forgot the man one.
Name calls people who read documentation.
Does not offer any alternative.
“No John, you are the neckbeards!”
initially when I was learning linux. I had troubles finding the command I needed. I could have first gone and read everything and then come back to try, which I did. But sometimes the man pages, the ubuntu and arch forums weren’t as great of a help as messing up myself.
Could there be a better way to document with slightly more examples: yes. Would it help: tons
But this is just my opinion, and I am just a noob
THIS. I feel like linux
manpages are as useful as an Analytical mechanics textbook for someone who just wants to drive. Like yes, sure, it’s amazing we have such a detailed documentation but for God’s sake just introduce basic usages firstssh connects and logs into the specified destination, which may be specified as either [user@]hostname or a URI of the form ssh://[user@]hostname[:port]
ssh [admin@]192.168.1.1 ssh: Could not resolve hostname ]192.168.1.1: No address associated with hostnameThat’s how I would interpret that part of the man page had I no familiarity with ssh. It doesn’t seem reasonable to expect the reader to know what those brackets mean.
Agreed, and I think a larger part of it is that most folks pick it up based on context after long enough, so it’s rarely explained. The square brackets are optional arguments. So I could use
ssh 192.168.1.1orssh postimo@192.168.1.1with the first asking for the account after I connect, and the second just asking for the password. You can see how the computer took it in the response you got.hostname ]192.168.1.1being it saw theand assumed everything after was the hostname and included the ]It’s worth noting that you can’t just connect to a random machine like this, they need to also be running an ssh server. But I wouldn’t expect you to know that without reading a great deal more of the documentation 🫠
I’ve been using ssh for decades, you don’t have to explain it to me. It was a purely contrived example to simulate what I think a new user might experience if faced with that particular man page as their only documentation.
Oh my mistake, I didn’t mean to demean at all. Yeah I think even in your example there are baked in knowledge we’ve picked up that we don’t realize, and that a very likely response from fully fresh eyes would seeing the synopsis is “oh this isn’t for me.”
No worries, didn’t feel demeaned but wanted to be clear that it was an attempt to try to ignore ~23 years of ssh muscle memory to try to guess what might trip up a new Linux user
Very much true in my case - I couldn’t explain what the, like… “idiomatic” meaning of those brackets is, I only guess from context and experience, and it remains a minor peeve of mine that such symbology is widely used but rarely explained
You get to learn the notation conventions with <> and [] fairly early on. Maybe a very new user would make that mistake. If he doesn’t get it fairly quick, maybe computers aren’t for him.
Nah m8, I’m generally on board with asking people to read the manual, but these unexplained conventions are nonsense. Pages really should be explicit about notation being added to commands that aren’t actually a part of them
They’re explained right at the beginning of the manpage.
The man manpage. I’m sure it was the first one you read? Because you wanted to know how man worked?
Sure, but that is very far from obvious, and very few people who don’t already have an understanding of this stuff are going to know to look there. When I search for how to do something on the internet I mostly find 2 kinds of sources: stuff that’s way dumbed down (and usually out of date/incorrect) and stuff full of unexplained notation/abbreviations/arbitrary conventions without any links to resources that explain them.
I guess my issue with the man pages is mostly that they just don’t try to be approachable to the not-so-tech-litterate folk who might be interested in Linux if we had resources that didn’t assume all this foreknowledge.
This mentality suuucckkss
hard agree
BS. I’ve been using linux for over 20 years and I still don’t know what those mean. I can only guess from context. It’s a stupid convention to just use symbols like that and never explain it.
Read the man manpage and all will be revealed.
Following the openbsd example from the original comment I replied to, it has absolutely nothing to say about what brackets mean, so this advice would not be helpful for an openbsd system: https://man.openbsd.org/man
On my personal linux system (arch derivative, by the way), it at least mentions brackets meaning optional, but only in the context of arguments:
[-abc] any or all arguments within [ ] are optional.I think this would trip up some new users. The destination, with or without the username to connect as, may not seem like an “argument” to a new user since it doesn’t have a dash before it like the example does
this advice would not be helpful for an openbsd system
Sorry, I wasn’t aware of that. BSD usually has excellent
panman pages.Here’s the relevant section in the Linux one:
The following conventions apply to the SYNOPSIS section and can be used as a guide in other sections. **bold text** type exactly as shown. *italic text* replace with appropriate argument. [-abc] any or all arguments within [ ] are optional. -a|-b options delimited by | cannot be used together. argument ... argument is repeatable. [expression] ... entire expression within [ ] is repeatable.The destination, with or without the username to connect as, may not seem like an “argument” to a new user since it doesn’t have a dash before it like the example does
Then the new user should real the ssh manpage which very clearly specifies that it is.
It’s a good thing there are other resources, then. You can read tldr-pages. You can look at various official and unofficial wikis. You can look at Stackoverflow. You can look at Youtube tutorials. You can ask other people. Hell, you can ask a chatbot.
If the average user is unwilling to do that, maybe it’s better that Linux does not see a wider adoption.
is the fact that people can with effort and error figure out how to do something a reason not to make it easier for them to do?
I mean
you can in theory write multi-threaded bug-free C code – just read the docs and the specs and the source of your libs and never ever do something that seems to work but is subtly fatally incorrect
and yet we still have golang and rust and many other options to do things more safely and easily
if someone wants to use Linux but doesn’t want to memorize the Hundred Mandatory Commands and Thousand Flags lest they accidentally
cat > /dev/sda, why shouldn’t there be a system for them?The community abhors change. Especially changes that break conventions, even informal ones. Look at the temper tantrums people are throwing because Wayland does things differently from X.org. Changing output redirection in Bash, or how
ddworks, or any number of long-standing conventions because new users are unwilling to adapt to a new system and might end updding over the root partition would break established workflows, and worse, existing scripts and services.But the solution already exists, it’s called wrapper programs. You don’t have to manually update AUR packages because
yayandparualready do that. You don’t have to figure out howfdiskandmkfswork because Gparted and Partition Manager do it for you.Nevertheless, using a system should always and forever be the user’s responsibility. Otherwise Linux would turn into a locked-down play pen like Apple products.
Agreed! You can look elsewhere, and that’s how I, and I think many other folks, learned. The OP was talking about the manuals though, specifically mentioning
/usr/bin. So to restate my point is not to say it’s impossible to learn linux, but that man pages are weird and bad place to push folks looking to learn.
There’s other ways to get info. And man pages are a great way to learn how something is expected to work on your system. And it’s offline, without ads, scams, ai generated false info.
deleted by creator
You might be thinking of
infopages. Themanpages are just the instructions, feature flags, etc. generally, whileinfo(when available) usually has a more general / layman description of the command with examples.deleted by creator
It’s possible. A lot of things merge the info and man pages now if both are installed, that could be the case here. Or Mac just documents it further.
RTFM
this joke is way older than HTML
I just learned about “man thing” in terminal a couple days ago. I had no idea they’re kept in that folder.
Part of the fun of buying a game was getting to RTFM on the way home.
public transit, ftw… unless “I wish I died pecefully like my grandfather… the driver who was RTFMing, instead of his screaming passengers”
Last time I could buy a game with an instruction manual I was lucky that I could ride in a car without a car seat.
WTFM is job one. Honestly WTFMs and RTFMs should just be a requirement to any computer science degree.
CS101: RTFM - Someone has already helped you.
CS102: WTFM - You also need to help others.
CS103: FTFM - What to do when help isn’t provided.
CS104: GDFL - What to do when there is no more help.
Edit: Other courses I teach include
CS201: WTFPM - Code Quality
CS202: UTC - The only time that makes sense
CS203: 1 - Counting for machines
Technical writing was a required class in my CS program. Is that not the norm?
You drive a vehicle with a manual transmission.
You steer a vehicle with an automatic.
I mean in general, “read things -> learn” is a good approach to life imo.
Too long and difficult. I’ll let chat gpt tell me instead and read that between adverts on Love Island
Grok, is this true?
we’re cooked
I’ll be honest, I’m guilty of using Chat GPT at times for stuff I know barely anything about and know I probably won’t be able to find through research as quickly as I’d like to. I always try the old-fashioned way of using a search engine first, go through reddit and forums and stuff, but sometimes I just need to use AI for a good first pointer
It’s not a terrible idea. ChatGPT is great at summarizing info, especially stuff you’d use manuals for. I make sure to ask it where certain info came from (so I can try to verify) OR having it explain its approach so I get it in the future.
I’ve been using Linux for about a year now, I have no clue what is even in /usr/bin …you people have manuals?! I needed a manual to find the thing.
Keep in mind this is FreeBSD, but this is the perfect structure that FreeBSD obeys.
Linux distros fuck it up on a daily basis. App devs interpret it themselves and fuck it up even further.
But if you dont know what etc, usr or bin or local means, it should give you a better understanding. Navigating docs, manuals and commands should be easier.
You can look at the Filesystem Hierarchy Standard for starters.
About manuals, tryman manin the command line, then something likeman ls.Just type in man <your binary> to go through the binary manual, also called man page :)
it is where all the binaries (programs) live (that are not system critical, those would be in sbin). so whenever you execute ls? it is actually /usr/bin/ls and so on and so forth.
then there is the “man” command. basically a manual. you can use it to find out stuff about other commands and such by just typing “man [command]” for example “man ls”
edit: this knowledge has NOT been acquired by RTFM but rather by watching YouTube
Thanks that’s a massive help, I’m usually just searching around GitHub, forums and YouTube for info, literally never used the man command.
I’ve acquired a reputation as the go-to frontend wizard by reading the MaterialUI documentation. Now half my job is randomly getting called on Teams, listening to someone ramble about what crazy ideas they have for their frontend, and pointing them to the MUI implementation that already exists (because there are no new ideas). It’s stupid, those docs are modern and well-structured, people just refuse to read them.
The issues come up when I read the manuals and they do not explain anything to a person who doesn’t already know most things.
Linux fails in too many places at having instructions written by people who care even slightly whether humans will ever be able to comprehend them.
