Can you use the terminal for everything? [video]
youtube.com
youtube.com
The guy is absolutely right. Mutt is not a gimmick like ascii video on terminal.
It actually makes a lot of sense as an email client and is surprisingly ergonomic. I also enjoy the fact that my config is a normal dotfile that I can version control etc. Also, your passwords can be encrypted using the tools that you choose, as opposed to whatever home grown crypto (if any) the [insert random Electron email client] uses. Some ways are outlined here:
https://www.mail-archive.com/mutt-users@mutt.org/msg36375.ht...
For a more up-to-date guide on how to use GPG for your e-mail password [1]
[1] https://pthree.org/2012/01/07/encrypted-mutt-imap-smtp-passw...
I personally use (al)pine and I could not agree more.
But here is a different, and I hope very provocative, reason that you should consider a terminal email client:
Local mail delivery does not traverse the Internet, or any network.
So, for instance, when I send an email to one of my engineers at rsync.net, even though it is sent in plaintext, it is a private communication and cannot be intercepted by either an ISP or some global observer. It's nothing but a local file operation between two mailspools...
Further, it would be extremely difficult to phish someone who is viewing their email in the terminal. The effort that it takes to view and copy a URL is greater than the discernment required to identify it as suspicious - so you'll catch them every time.
> Local mail delivery does not traverse the Internet, or any network.
The implication here being that you are running the clients on the email server. Wouldn't you effectively get the same security by tunneling IMAP over SSH?
That's a common scenario, but most linux/BSD distros ship with some mail server software installed and configured to run out of the box, even if also set to not allow external connections, as that's how the system delivers messages to users (e.g. cron output, etc). So almost every linux/BSD is a mail server, even if it may not be the mail server. If there's a main box that people in your company connect to as a terminal, email to local accounts on that box is essentially a internal messaging system. Hell, you could throw an IRC server on there with no outside access and use terminal IRC clients to have your own private chat channel as well. Who needs slack?
If you want to send someone a message, there is write (if the person have mesg set to yes). There is also talk, but it requires its own daemon.
Seriously, _nix started out in the mainframe era. Meaning that the basic assumption was multiple terminals hooked up to a single computer, with a different user on each terminal.
Sadly we have a generation or more that grew up with single user computers, and seems to insist on turning _nix into that rather than embrace what it can offer.
Yes... that's the point of the discussion. They exist, but there is (or is perceived to be) lack of knowledge about their existence and how to make use of them from some newer users, either because of the push for desktop linux, or for whatever reason.
> Yet here we all are having a discussion on HN instead.
I have no idea what you're trying to imply here. I suspect maybe we are discussing similar, but ultimately different, things.
And it is not about thin clients, thin clients btw is yet another Windows-ism, it is about the concepts embedded in the unix concept that current day devs seems to either sidestep or downplay while building house of cards in userspace that poorly replicate said concepts.
I'd probably run it in a non-privileged container.
Infact, I should be doing that for Mutt ...
Does mutt talk to the network or have a daemon or run as a service ? I don't know the answer to that but I know that for my own use-case, pine is basically a text editor. It executes no programs or code and does not talk to anything but the local SMTP daemon.
How much sanity checking and bounds checking does sendmail (or postfix or whatever) do on email ? That's the question, I think, because again, in my case, the threat vector is very limited - basically an arbitrary (weird) email or piece of an email that somehow breaks pine.
So no, I don't run it in a container - in fact, I run it as the user whose mail spool is the highest sensitivity asset that user owns ... so a container wouldn't help. If you get the mail spool, you get everything - at least or that user...
The only thing that might throw people off is that it uses nano for creating your email... (from the video)
Actually, IIRC it uses the EDITOR environment variable, with some sane fallbacks. I happily wrote emails in vim for years. That said, defaulting to nano with a quick and well known way to swap your buffer to vim (and possibly back) might be a better solution overall. I love vim and use it as my IDE, but the cost/benefit ratio isn't in it's favor when your average time spent on a reply might be very short or when you're writing freeform. Especially if your default config is for wordwrap off because you use it as an IDE...
The other thing to make sure you get nailed down in Mutt is to set up links or elinks as your html view handler, so HTML-only emails can actually be read without extreme difficulty for those cases where a client sent an HTML email without a plain-text companion.
The thing to remember for any program that allows complex configuration like mutt is that you can often search for other people's configs[1] and copy them as your own, and once you get better, you can copy portions of them and tweak as needed to get your own specific customized behavior. I ran FVWM2 as my window manager for over a decade, and I remember every 5-6 months I would do some searching to find interesting new behavior people had implemented that I could tweak and steal (like here[2]). Every time some interesting new UI feature would come out somewhere someone would implement it in FVWM within a couple months.
1. [https://smalldata.tech/blog/2016/09/10/gmail-with-mutt]
2. [http://stevelosh.com/blog/2012/10/the-homely-mutt/]
3. [https://baptiste-wicht.com/posts/2014/07/a-mutt-journey-my-m...]
Is there a transcript? Or is the summary "no"?
How old are your "older colleagues"? I'm 35 and I remember "the land before Git", let alone the time before GUI Git clients...
My first Linux install didn't have a GUI at all, at the start. I didn't have enough floppy disks to download all of the Slackware A, N, and X packages, so I downloaded A and a subset of N onto floppies, which let me bootstrap PPP so that I could start downloading the X packages to get a working GUI going. That was on 33k6, and only when my parents didn't want to use the phone, so it took a while...
There's no training that can prepare you for that, except for training in how to train yourself in something, quickly.
You'd have to hunt around for things, hope that whatever you were doing didn't have weird unpredictable effects, and was repeatable. While you could write down everything you typed, and some precis of what resulted, or even in some cases record the result (eg ssh-ing to a machine from inside an emacs buffer or something like that.
And not all GUIs are tailored for novice users. I use StumpWM, and despite being a GUI system, it'd be very difficult for a new user without some instruction.
But I think what's behind your question is the fact that part of UX/UI is to abstract experience and interface. So maybe if I first had to poke at an alien OS I would try its UI as part of familiarity in getting to know it, but ultimately as a system architect, hardware developer, and former O/S dev with 4 decades experience, I want to see how it really works. The UI is always the topmost layer.
I'd love to encounter a literal "alien" OS in my lifetime. That'd be a pinnacle of my pentesting & reverse engineering creds.
Good question.
GUIs are discoverable, and have lower friction for first time users. Example : a video codec GUI will always be easier to use than ffmpeg. I still Google how to use ffmpeg after 10years , and I have to read the entire man page because I don’t know what I don’t know! Is there a newer, better option to this flag available? Like lame for mp3s (another great example), a man page which (used to?) start off with bitrate options, but at the end says; forget all that, just use --preset. Or imagemagick, which decides to go for undiscoverability gold and split their entire program up over multiple binaries so you now get to read multiple man pages! After you guess what the names of those programs are, of course.
Hell. Give me a gui for any unfamiliar task, any time.
Of course, were I encodig movies every day, I’d be singing a very different tune.
Edit: another example: I resize images about once a week and I still have to google imagemagick’s convert. I keep forgetting how to resize to known width, keeping height ratio. It’s so frustrating that I’ve just given up and sort of guess with % instead, until it’s close enough. Not to mention resizing to a desired file size (is that even possible? With a gui, at least I’d know if it were at all. Now I’m just tired of reading the man page. I give up. Imagemagick wins.)
had a pervasive semi structured fuzzy matching at the OS level so anybody writing a program can have a good completion without resorting to shell generators and enjoy easy discoverability.
GUIs are easier to explore right now but they also have lots of hidden state and obscure organization (good luck knowing which options interferes with who and where they are some times)
The other day I was doing some basic data collection and graphing, with the initial version being done in Excel, for something as basic as adding a trendline I had to resort to googling the answer, and following a sequence of several click this, then click this style to get what I needed.
Turns out it was actually easier to understand how to do what I needed using python matplotlib (not a CLI program granted).
Design, documentation and managing complexity are far more important to discoverability than GUI vs CLI.
That's the usability of common things in everything not major desktop/user OS, and always has been. OTOH, when I'm programming, I would NEVER give up the comfort of GNU stuff. It's just so convenient. Even the editors. Yes, VS Code is great, but oh man - in vim I have a persistent undo with branching, among many many other things.
It's actually amazing how, on the one hand, you have this advanced system for complicated stuff geared towards awesome usability and on the other hand it trips over itself on mundane things which keep it away from the year of Linux (GNU more like it) on desktop.
That said, sharing files across networks is a hell all its own. In particular if you want something to just automagically appear in some GUI across the office/world/whatever.
Only "reliable" ones are those that require the user at the other end to know what address to enter to get access.
You can actually see it if you cat a big file to the screen.
w3m can also display images using the framebuffer, with the rest of it still in text mode.
There's a solution to that though: running Firefox in the terminal with brow.sh [1]
I disagree. I find vim, mutt and pandoc superior to LO Writer and Thundrbird for text editing and emailing, but sc is just nowhere near LO Calc or even Gnumeric.
I really wish someone would make a text user interface for Gnumeric.
However, the sad state state of the world is that other people use Word and Excel to edit documents. I wish there was a program that would do to Excel spreadsheets what Pandoc does to Word documents: Letting you edit them in the terminal and allowing you to pass them off to other people in the formats they prefer.
Those other people would hate me if I sent them Emacs Org mode spreadsheets to work on.
[0]: http://orgmode.org/manual/The-spreadsheet.html#The-spreadshe...
https://www.youtube.com/watch?v=pfHpDDXJQVg (Four Fake File Systems)
Another problem was integrating Alpine with calendars (at least O365).
khal (with vdirsyncer) is a nice calendar app. I haven't got it working perfectly with Office635 yet though; I use a read-only url to the calendar, so I can at least see it, but cannot edit it. The Fastmail calendar works.
Maybe i'm not the target audience.
[0](https://kmandla.wordpress.com/2010/10/19/howto-switch-to-a-c...)
I would assume that the percentage of computer users who do significant work in a terminal (email, IRC, coding, etc.) is still decreasing steadily today. What I'm not sure about, how does this decline in penetration compare to the (still real) growth in the worldwide computer user base?
Seems that at least the Internet user base is still growing ~10% p.a. What does this mean for absolute terminal user numbers? I would guess they peaked already a decade ago, with people switching to / starting out with smartphones and tablets instead of notebooks/desktops.
I can also see a world in which a highly disruptive technology (e.g., brain-computer interfaces) would make the terminal redundant once and forever, assuming that the new technology was more efficient/productive than a terminal.
You're right, with more and more computer users added every day, as a percentage command line users have probably been shrinking for a long time. But I would also expect in raw numbers they're probably still growing.
What manner newfangled luxury is that in a terminal? When I was young, we had to pick lice out of our hair and arrange them in the form of letters for others to read.
vlc -V aa <youtube link>
vlc -v caca <youtube link>