Every time I encounter a tmux recommendation it has me pondering whether it's worth learning minicom. When I first read the author's rationale for tmux it rubbed me the wrong way, because the main feature they dismiss as cruft- the ability to use it as a terminal emulator for a serial port - is something I still find myself using from time to time. Is tmux really so much nicer than screen it's worth learning minicom?
You could also learn screen instead of minicom. screen supports communication over serial.
Terminals Are Sexy
51–60 of 84 posts
Re: Terminals Are Sexy
#52This is a lot to take in. Not sure if you're the author, OP, but in case the author is reading: Where would you suggest someone starts? (Note: Don't answer here! Use your answer to shape the organization of information on the site!) For example, I use ZSH. Should I switch to fish? The list suggests I'd be sacrificing power and the ability to write scripts but gaining, uh, intelligence and user-friendliness? Is that t…
Just pick something and stick with it a bit....
Re: Terminals Are Sexy
#53This is a lot to take in. Not sure if you're the author, OP, but in case the author is reading: Where would you suggest someone starts? (Note: Don't answer here! Use your answer to shape the organization of information on the site!) For example, I use ZSH. Should I switch to fish? The list suggests I'd be sacrificing power and the ability to write scripts but gaining, uh, intelligence and user-friendliness? Is that t…
(In zsh's case, i think that's partly the project's own fault; it has very underwhelming defaults and a very overwhelming set-up process for new users.)
Re: Terminals Are Sexy
#54I hate non-discoverable UI's. The first thing I do with any software, is click through all possible menu's, windows, ribbons, whatever. After some time, I usually get quite a grasp on what the software is capable of. The two notable exceptions are textbased UI's (terminals, dsls, ...) and softwar requiring domain specific knowledge (e.g. geomodeling software, specific 3D modeling software, ...). I never understood th…
A command line interface lets you communicate to the computer using language. Learning a language is something you can practise and get better at until you find that you're able to communicate very complicated tasks that the original authors of the programs had never even imagined. Graphical user interfaces are a caveman interface. You go to the market, see what's on offer, point to it and grunt. That's fine as long…
A language to do stuff is actually a great thiing, especially if it can produce readable and reproducable objects (programs). However, I get really scared looking to most commandline scripts. It's an incomprehensible mess people only can start to grok after years of experience with the particualr commandline tool.
Re: Terminals Are Sexy
#55I hate non-discoverable UI's. The first thing I do with any software, is click through all possible menu's, windows, ribbons, whatever. After some time, I usually get quite a grasp on what the software is capable of. The two notable exceptions are textbased UI's (terminals, dsls, ...) and softwar requiring domain specific knowledge (e.g. geomodeling software, specific 3D modeling software, ...). I never understood th…
For full TUI applications I'd agree, there are usually worse at discover-ability, they are used because the make up for it in other ways like speed and learn-ability.
Re: Terminals Are Sexy
#56Earlier quoted context omitted.
A command line interface lets you communicate to the computer using language. Learning a language is something you can practise and get better at until you find that you're able to communicate very complicated tasks that the original authors of the programs had never even imagined. Graphical user interfaces are a caveman interface. You go to the market, see what's on offer, point to it and grunt. That's fine as long…
But most commandline languages are inconsistent, have inconsistent abbreviations, have inconsistent command parameter naming/defaults, contain acronyms of incomprehensible words, have plain weird names, contain inconsistent or outright incorrect documentation... A language to do stuff is actually a great thiing, especially if it can produce readable and reproducable objects (programs). However, I get really scared lo…
Re: Terminals Are Sexy
#57Earlier quoted context omitted.
A command line interface lets you communicate to the computer using language. Learning a language is something you can practise and get better at until you find that you're able to communicate very complicated tasks that the original authors of the programs had never even imagined. Graphical user interfaces are a caveman interface. You go to the market, see what's on offer, point to it and grunt. That's fine as long…
But most commandline languages are inconsistent, have inconsistent abbreviations, have inconsistent command parameter naming/defaults, contain acronyms of incomprehensible words, have plain weird names, contain inconsistent or outright incorrect documentation... A language to do stuff is actually a great thiing, especially if it can produce readable and reproducable objects (programs). However, I get really scared lo…
And how is this different for GUIs? Location / icons / description / ... depends entirely on the application. Some will have hotkey handles, some won't. Same app on a different system will look differently. (Possibly with different layout) Creating a discoverable GUI takes as much will and attention as a good set of CLI options.
Re: Terminals Are Sexy
#58http://linuxbrew.sh/ but… why? We have distributions that are providing perfectly packaged things like Debian/Arch/RedHat. I find already Homebrew hacky on macOS so why porting it on Linux distributions :D Is there anyone on HN using it, I'd be curious to know what are the advantages.
Linuxbrew, like Homebrew, is useful for non-invasive non-system/infrastructure packages. Compared to system package managers, it is (arguably) simpler to use and contribute to, and often has more up-to-date packages (especially compared to e.g. RHEL) because it tries to solve a much simpler problem. I think there is room for a package manager that focuses more on managing your user-specific CLI tools than your system…
> it is (arguably) simpler to use and contribute to, and often has more up-to-date packages (especially compared to e.g. RHEL) because it tries to solve a much simpler problem.
Unfortunately, this often means it breaks or doesn’t do certain things…doing something simple like getting an old version of a package is nigh unto impossible, both because there doesn’t seem to be a built-in way to do this, and also because old packages are constantly removed from the package index. The fact that package inclusion is easy is nice, but it also opens issues that we’re already seeing in the npm community with regards to malicious packages.
The ability to install software to a non-system location is useful, but that’s really not something that Homebrew itself really recommends doing on macOS because it breaks a lot of things. It’s really only designed for a single user machine with the regular user being an admin, which is likely true for the majority of its authors, but for those who don’t fit into this you need to resort to a bunch of hacks to make it work.
Re: Terminals Are Sexy
#59came for some actual, physical (preferably sexy) terminals. was disappoint.
Re: Terminals Are Sexy
#60Earlier quoted context omitted.
But most commandline languages are inconsistent, have inconsistent abbreviations, have inconsistent command parameter naming/defaults, contain acronyms of incomprehensible words, have plain weird names, contain inconsistent or outright incorrect documentation... A language to do stuff is actually a great thiing, especially if it can produce readable and reproducable objects (programs). However, I get really scared lo…
> But most commandline languages are inconsistent, have inconsistent abbreviations, have inconsistent command parameter naming/defaults, contain acronyms of incomprehensible words, have plain weird names, contain inconsistent or outright incorrect documentation... And how is this different for GUIs? Location / icons / description / ... depends entirely on the application. Some will have hotkey handles, some won't. Sa…