The OpenSSL command line is more or less a test driver / reference for the library. It's a little weird to criticize its UX. Also: it's pretty easy to make something look bananas if you surface every obscure option in its main screen!
I don't think it's a critique of the library; calling the x509 specification complex enough to be magic seems accurate.
Honestly I love the UI presented: concise, shows all the options, a fantastic summary of the CLI without having to scroll a massive man page or website.
I'd love this for all the super complex CLI tools I need to use, as a visual cheatsheet on where to search in the man page.
I wrote a personal tool to do this automatically by parsing '--help' after I couldn't remember the tar options for the millionth time. Turns out the programs that have complicated, undiscoverable interfaces also tend to omit useful options from automatically discoverable documentation, so it wasn't especially reliable.
I’ve always found it a shame that the UNIX philosophy seemed to stop at system/command line tools and no one ever took the further step to apply it to user interfaces.
UIs generated in systematic, composable ways emerging naturally from all the plumbing (pipes, option flags, etc) we already have in place.
Every few years I get the urge to dive into smalltalk/squeak/cuis/<insert smalltalk variant here> and while it suffers from being pretty heavily stuck in an era and a small community it always feels like a window into what could have been if operating systems in general and unix in particular didn’t stop at CLIs with a window manager tacked on top. In fact having recently revisited some old classic Mac things, it’s sort of interesting to note how despite how nice it is that osx has Unix underneath and windows has the WSL it also means we’re converging on a design with a lot of old baggage.
There was a time when I'd have agreed with you. But over time I've come to honestly disagree, perhaps unsurprisingly, since I detest the typical command line experience too.
Just like when books are adapted into movies, the good adaptations are the ones that are better than the sum of their parts (aren't a direct adaptation). Blind, generic composability is in direct contradiction with this. One could argue that it's the scale that determines whether a better integrated or a consistent but generic solution is better, but in this case I think the article very explicitly demonstrates that the latter approach is what loses out.
I have a very strong and persistent disdain towards the many shell incantations I had to come up with, have to keep around as notes, and have to have AI generated. Having to navigate the maze the article calls a GUI would result in much the same.
I feel like I'm taking crazy pills seeing people in this thread regarding this visual any good, especially given how even the article author clearly disagrees, hence "why" the article was created in the first place.
> The OpenSSL command line is more or less a test driver / reference for the library
hmmm, not sure about that. Its the main (only?) interface if an individual wants to mess with certificates or generate them. It is often reported ACME/LE took off because it is easier to configure an ACME client than the annual wrestling with openssl. But if openssl had been easy for common user tasks maybe LE would have taken longer to be adopted.
ffmpeg also has a notoriously difficult CLI interface. Today you can just ask a LLM to generate you a command, the consequences are low if it gets it slightly wrong. The consequences of getting openssl wrong could not be obvious immediately and result in a lot of debugging down the line.
LE took off because everyone was charging ridiculous amounts for certificates and few people needed the verification that comes with that. ISRG created ACME for LE.
One of my personal frustrations with SSL as implemented in most systems is the conflation between encrypted communication and verified communication. SSH sort of got this right with ToFU as a default behavior but I think a lot of the resistance and difficulty in adopting SSL for encrypted intranet communication comes from the need to do the CA and cert signing song and dance. If you could turn on encryption without needing to do ID validation by default it would make things easier for people
I know that encrypted communication without knowing that your talking to the right person is somewhat useless, but it works for SSH most of the time, there’s no reason it couldn’t work well for https and encrypted db connections etc.
I think you are right. On the other hand it’s the fact that a lot of tutorials / getting started guides etc include some ssl invocations to execute a specific command for key/cert creation. And a user wishing to adjust and maybe understand things gets thrown at a man page that is so overloaded.
Similar to git. But git’s cli at least has a clear setup with optional vs mandatory values. I always disliked commandline interfaces with mandatory option fields.
