• 0 Posts
  • 10 Comments
Joined 1 year ago
cake
Cake day: June 9th, 2023

help-circle




  • Others has answered the specific cases where TTM is paramount.

    When time is less of an issue, in my experience it’s in no particular order a mix of:

    • product owners or similar role wanting “everything and right now” for no reason whatsoever, except maybe some bonus;
    • bosses bossing around to try and justify their existence instead of easying progress ;
    • developers being not much more than code jockeys with a tendancy to develop by StackOverflow copy/paste;
    • operations lacking time, resources or knowledge to build a proper CI/CD pipeline - when it’s not an issue of operations by ServerFault copy/paste;
    • experts (DBA, virtualization, middlewares) being kept out of the project, and only asked for advice when things go terribly wrong later.

    All in all, instead of short term profit, it’s a lack of not-so-long term vision and engagement from everyone involved. They just don’t care.

    Yeah, I’m the one in charge of fixing the mess, why you ask?





  • Unplug your mouse. Seriously. Do it. It might sound like the “kicking and screaming” method but you’ll learn to rely on your keyboard even for GUI tools and you’ll vastly improve how fast you navigate your computer. You should find yourself more and more in the terminal, obviously, but you may learn also some nice tricks with everything else.


  • Simple: because it goes against the KISS principle. The GNU tools that constitute the user interface to the system comes from a philosophy that started with Unix: simple tools, doing one thing well, communicating through “pipes” - i.e. the output of one tool is supposed to be used as the input of the next one.

    Such philosophy allows to assemble complex logic and workflows with a few commands, automating a lot of mundane tasks, but also allowing to work at a large scale the same way you would work on a few files or tasks.

    Graphical tools don’t have such advantages:

    • UI are rarely uniform in their presentation or logic, as there’s so much way to present options and choices;
    • Apple did something nice in the way of automating with AppleScript, but I’ve not encountered anywhere else. GUIs are rarely automatable, which means you’ll need some clicking and pushing buttons if a task has to be repeated - or the GUI has to be altered to be able to replay a set of commands for multiple items;
    • interconnecting different GUIs so that they can exchange data is just impossible. You usually end up with files in dedicated format, and the needs to massage data from one format to another to be able to chain tasks from different GUIs
    • more importantly, command line work with minimal bandwidth and tooling on the client side. Tmux, Mosh and similar tools allow to work with an intermittent connection, and have a very low impact on the managed system;
    • in some specific fields - notably embedded and industrial systems - you just can’t justify allocating resources just for a graphical environment. On these system, CLI is as powerfull as on a full fledged server, and don’t requires stealing precious resources from the main purpose of the system.

    Beware though: as time passes, Unix founding principles seems to get forgotten, and some CLI tools manifest a lack of user experience design, diverging from the usual philosophy and making the life of system administrators difficult. I’ve often observed this on tools coming from recent languages - python, go, rust - where the “interface” of the tools is closer to the language it’s written with than the CLI uniform interface.