• Kabutor@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    0
    ·
    3 days ago

    I had a problem with sendmail about 20 years ago, for several days I tried ro fix it, the only way I fixed it was reading the manual, not the whole manual because about half I read what was i doing wrong.

    If everything else fails, read the manual

  • technocrit@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    0
    ·
    4 days ago

    Yeah very true. I was floundering with an issue recently. I couldn’t find any help until I added “docs” to my search. RTFM.

  • varyingExpertise@feddit.org
    link
    fedilink
    English
    arrow-up
    0
    ·
    4 days ago

    Actually, several hours of cursing and trying are an excellent substitute for up to three minutes of manpage reading.

  • Modern_medicine_isnt@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    4 days ago

    Have you seen the manuals today? 90% of the content for a product manual is CYA. In the next year or so they will all be written by AI.

    Also, different people have different learning styles. A manual is just one. Many of us learn better by having something real to do, and learning by doing.

  • LeFantome@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    4 days ago

    Einstein reportedly said “Never memorize something you can look up in a book”. When asked the speed of sound he said , “I do not know but that number is commonly found in textbooks”.

    I am not going to spend my life reading manuals. Reading my furnace manual years before a problem arises is unlikely to help me.

    However, I completely agree that RTFM is a great thing to do with confronted with a gap in knowledge or problem to be solved. Not the whole manual probably, just the relevant parts.

    I think it is much more important to store ideas in your head than information. That said, those ideas do not come from nothing.

    I might not read the man pages of every command on a Linux system. At least, not all of them. But I should know high-level what commands are available and what they generally do. That allows me to think of them when they would be useful. But I probably have no idea what the proper syntax is for any of them when I go to use them.

    And “the manual” is not always the best place to get ideas, even if it is the authoritative source for specific knowledge.

    Time spent reading the manual is time not spent doing something else. Spend your time learning. Spend most of it learning what is possible. In my view, that is the best strategy.

    • brygphilomena@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      0
      ·
      4 days ago

      I think reading the manual gives you the concept of what something is capable of doing. No one is saying memorize all the commands and their flags.

      But if you read all of them, maybe some day you’ll have a problem and realize, wait… I’ve seen something like this before. And you can then look up the specifics.

  • Angel Mountain@feddit.nl
    link
    fedilink
    arrow-up
    0
    ·
    4 days ago

    You can even learn a new language if you first read the version in a language you know and then do a language you don’t know yet.

  • chaosmarine92@reddthat.com
    link
    fedilink
    arrow-up
    0
    ·
    4 days ago

    He skips over the extremely important points of first knowing that a manual exists and knowIng how to access it. Then knowing what all the jargon means and what the manual doesn’t say because its written assuming a high level of knowledge already.

  • esa@discuss.tchncs.de
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    4 days ago

    For those who want to give it a go:

    #!/bin/bash
    set -euo pipefail
    
    while read -rd ":" path
    do
      for bin in "$path"/*
      do
        # don't error out if there's no manpage
        set +e
        man "$(basename "$bin")"
        set -e
      done
    done < <(printf '%s%s' "$PATH" ":")
    

    when you get sick of it, hit ^Z (ctrl-z) and go kill %1. Then you get to start all over from the start next time!

    Bonus points for starting a tracker so you can count how long it takes to go from “eugh, what’s with that overwrought and excessively defensive bash script” to “fuck, now I’m doing it too”

    • LeFantome@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      4 days ago

      I am not much of a bash guy so it took me a moment to understand what this was doing.

      Too bad I have to read so many man pages before I get to bash or sh.

  • FizzyOrange@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    4 days ago

    This goes against what we know about good design. Where possible you shouldn’t need to use a manual. Telling people to always read the manual is a cop out.

    Also he apparently read his furnace’s manual and months/years later remembered what a flashing light meant, despite never having had to refer to it again? Either this guy has freakishly good memory (possible but unlikely) or he’s bullshitting. Given the overall tone I’d go with the latter.

    And what is even the advantage of knowing in advance? Does he think people would not read the manual after seeing a flashing error light? You can look up most issues when they happen you don’t have to memorise error codes in advance.

    This is just a dumb “I’m so great” post.

    • squaresinger@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      4 days ago

      I agree with you, but reading beforehand has the advantage of knowing what to look out for to keep your device from getting to the “flashing light” stage.

  • Buckshot@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    4 days ago

    At work people think I’m some kind of wizard with git.

    I tell them I’ve been using it every day for 15 years and I read the freely available book on the website, link them to it, and mention the first 3 chapters probably covers 90% of their normal usage so they should just read that.

    They won’t do it. I don’t get it. Something about written words is scary to them.

    • Feyd@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      4 days ago

      This is my exact experience with a lot of things. I just skimmed through the first party documentation for $thing and it pays huge dividends over time when compared to trying to learn from the relatively context-sparse stack overflow or chatbot

    • iglou@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      4 days ago

      Same here. I obviously don’t remember everything because I rarely if ever have to use them, but at least when the time finally comes that I need “git bisect”, I’ll know that “git bisect” exists and I’ll be able to go straight to the manual page that documents it.

      No one expects anyone to read the manual and remember it all… But you will naturally remember the big lines and be able to refer to the right place when you need something.

  • Pika@rekabu.ru
    link
    fedilink
    arrow-up
    0
    ·
    4 days ago

    Man pages in Linux are commonly meant for people already familiar with command structures, specific terms etc.

    They are often borderline useless for an inexperienced user.

  • fox2263@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    4 days ago

    Unfortunately, the manual on goods these days is roughly the size of a post-it note. And even if they have proper ones, none of them have the full technical readouts, blueprints and repair guides that they used to back in the day.