1. 33
  1.  

  2. 16

    Ironically, Linux with the GNU tools makes for the noisiest “unix-like” system I know. This is reflected in kernel messages, logs, compiler output and indeed output from many other tools, interactive tools that start by printing a version and a copyright banner, huge scripts and config files with lots of comments and examples, man pages that manage to say little in so many words and then refer to info for even more noise. The attitude many developers and users have is that more noise is better because it helps debug problems when you run into them. Others just don’t care, or can’t write well. And then, GNU forbids.

    I’ve chatted about the noise issues a few times but the overwhelming response I get is that GNU/Linux users actually prefer it. EDIT: And that the solution, for those who don’t like it, is to just hide the output behind pretty graphics and GUIs.

    1. 15

      Upvoted for:

      man pages that manage to say little in so many words and then refer to info for even more noise.

      Or the alternative scenario, when the manpage just says “this man page is a stub, refer to info XYZ for the documentation” and griding your teeth you figure out how to load info pages (again) and find it says “this man page is a stub, refer to info XYZ for the documentation.” – having been generated from the man page in question.

      1. 5

        Info pages are the worst.

      2. 4

        Is BSD any better here? (Curious, not insinuating).

        1. 5

          Fewer GNU banners, for sure.

          1. 5

            Yes it is.

            1. 1

              BSD sets the gold standard for documentation in my book.

              1. 1

                You should try out Solaris then :-)

                1. 5

                  Solaris non-manpage documentation is very good, but I don’t particularly like the manual pages; better than GNU, but that’s a pretty low benchmark to beat. I like BSD manual pages better, albeit I can’t say they are that much better.

                  The best manual pages were written for Research Unix by Doug McIlroy: http://man.cat-v.org/unix_10th/. The best part of them is their concision, which if course is greatly helped by the fact that Research Unix commands had few options (see Rob Pike’s UNIX Style, or cat -v Considered Harmful).

          2. 11

            This idea that programs should shut up and stay out of the way is one of the big reasons why I prefer macOS. It has been getting way more intrusive in the past few years, particularly around updates, however.

            Many, many mobile apps ignore this idea by nagging for reviews or pushing for IAPs. Websites are often horrible in this regard, with flashing banner ads, autoplaying video (why is this okay?), survey popups, even reflows can be jarring. Expensify managed to outdo all of the previous items with their own version of Clippy recently.

            1. 11

              Reminds me of http://www.calmtech.com/

            2. 11

              I was all ready to rant and roar about how I HATE this line of thinking because I’ve seen it used as an excuse for a ton of REALLY sloppy programs through the years.

              The way the author explains it, the goal is to eliminate verbose and unnecessary output from cluttering user’s terminals and making pipelines less useful. I am all about that!

              What I hate, hate HATE is people going too far with this and saying “if the program returns no output, it can be assumed to have been successful.

              HOLY JEEBUS THIS IS AN ANTI-PATTERN.

              UNIX was designed with exit codes for a reason. Use them. They are 100% unambiguous and won’t create logistical nightmares for someone using your program as a part of a complex pipeline.

              1. 4

                Painful memories triggered! A surprising number of utilities simply do not set the exit pattern and require stupid amounts of regexes/parsing code to determine if they succeeded in doing what they claimed to do. Whenever a tool that does nontrivial things (like talking to hardware), it really makes you wonder if the tool is something you can actually rely on in production.

                Exit codes may be slightly cryptic and convey little information, but at least they are simple to obtain in parent processes and have defined meanings.

                1. 2

                  They may be cryptic, but when you’re using individual programs as the UNIX gods intended, chaining them together to form more useful tools, it’s absolutely critical to recognize success or failure.

              2. 5

                this is why I cringe every time some documentation says to use tar -v. I love blinkenlights as much as the next guy, but it is bloody annoying when tar finishes, only to say there was an error somewhere, and your terminal only keeps 65k lines of scrollback so you can’t see it.

                Worse still is when you don’t notice that there was an error (unless you use a fancy prompt you don’t normally get to see the exit codes of your commands) until it’s too late.

                1. 2

                  The rule of silence originated because UNIX was originally developed prior to the availability of high quality video displays. Most output was sent to slow printing terminals, and each line of unnecessary output was a significant drain on the user’s time. Although that constraint is long gone, excellent reasons for terseness remain.

                  Well, I disagree, this constraint is not gone at all. Even if the print speed is now blazing fast, the human read speed is still the same. Worst, it seems like the attention spam could be declining.

                  I do not think we made huge progress in transmitting lots of information between computer and human mind. We are mostly using text, images and videos: technologies who already existed long before interactive computers.

                  Maybe instead of thinking about transmitting less information to the user, we should re-think about how we want to transmit these information and maybe rethink our traditional output multi-modal interfaces and find a way to transfer information between computers and us in a more effective way?

                  Do you know any promising ideas or device trying to achieve that?