It was, but it’s important to note that Quinnypig was reacting to the assertions made by extortionist claims made by Krebs. I think he’s acting in good faith here - if not somewhat melodramatically..
I use Slack as my bookmark manager ;) Have my own personal Slack workspace where I have various channels for certain types of bookmarks(coding/emacs/history,etc). On my Debian box at home I have weechat with the weeslack plugin where my weechat instance runs in a tmux session 24X7 and I log everything locally to disk. That way I can just open up the Slack log for a given channel to find a specific bookmark in Emacs via search/regex search. Have Slack clients at work, mobile, and home, so it seems to work pretty good for me.
This also demonstrates were CLI excels and where GUI's fall short. With the GUI your just stuck digging for the correct option and tab. With the CLI you can create aliases or shell scripts to make wrappers for complex CLI options. Not to mention building custom openssl.cnf configs.
Funny, when I looked at this my first impression was how much nicer the (hypothetical) GUI looked to use, with all of the functionality easily discoverable without digging through man pages and rewriting your intentions in terms of obscure flags.
To clarify, I'm not saying the GUI is actually better. But I wish we could bring some of those conveniences to the command line experience (way better autocomplete and command discovery).
Another second order factor is that precisely because the GUI just puts it all out there visually, it creates encouragement to start imagining what can be eliminated/automated, or at least shoved behind "advanced options (rarely needed)". What can be sane modern defaults vs reinventing the wheel each time. There are a ton of options in OpenSSL almost nobody should ever use in 2022 including some genuine footguns. Without discipline, CLIs are easy to just keep adding to, and scripting may well encourage that in the typical nature of creating a dependent ecosystem that discourages breakage. Not that there can't be really bad ginormous GUIs too but minimalism has a bit more human psychology behind it there.
Of course, for precisely that reason there are lots and lots of examples (particularly under "modern" "clean/flat" design tastes) that go to the opposite extreme and remove too much, get too information light and hide or eliminate stuff that's genuinely very important. But in the specific context of security software at least the current best practices thinking is that the fewer knobs and dials the better. A huge amount is purely legacy from when there were many more tradeoffs to be made in available compute power/memory vs security, but that fell away long ago in settings that would make use of complex CAs anyway vs something simpler. Not that simple CLI/text configs can't be easy too, look at WireGuard.
This topic strikes a little close to home right now too since I just went through an incredibly frustrating period of trying to put together some internal CAs with modern best practices (like name constraints) and it was quite the maze to get through. And having done it (or at least Good Enough) it definitely didn't need to be that hard. Ah well. Although then again, my experience also highlights to the perils of GUIs at the same time: I would have just used something like the built-in web gui CA generator on OPNsense, except it's so simple it lacks name constraints. Which then led me back into the red in tooth and claw world of openssl and ca config files. So there's the binary of both, an over simplistic GUI and an over complex CLI. Perhaps there are better tools bridging that gap but my searching failed :(.
It really comes down to "is this a one-time task you're trying to figure out" or do you want the options set once and never touch it again in a script.
With the CLI at least you can cut and paste the options from somewhere else.
Microsoft solved this for a lot of their server stuff by having a "show me the powershell command" at the end of most wizards. If you want to write a script, going through this process is usually a good idea.
"Cut and paste the options from somewhere" is a questionable practice even when it's not part of a security-critical workflow. And yet I'd venture to say that most people who use OpenSSL do so with commands copy-pasted verbatim from the internet, specifically because of its obtuse complexity.
Set-and-forget still requires you to know what to set.
I've got a visual memory. I'm going to remember some obscure sub-menu on a forgotten screen far better than a command I learn and expect to use exactly once when I inevitably need to find it a second time.
At first glance, it would be better with more separation of sections rather than cramming it all on one page. After a while it does become unruly, but it could be improved over time and after test case reports.
Some common functionality in tab ABC, and then opt-in for Headache Mode if necessary.
That makes me think... was your comment really necessary? Maybe it was my intention to let the reader draw their own conclusions. Maybe the expansion wasn't really necessary. I surely wouldn't have added another comment if there weren't the unnecessary downvotes.
The interpretation here is implying that this GUI exists to demonstrate good GUI design. It instead exists to demonstrate what it would look like if you directly mapped the APIs of OpenSSL into a GUI 1:1. This is not the ideal way to do that, of course, but I would argue that with really good APIs, if you did do something like that, it would wind up being quite passable.
How openssl is today is probably not so bad for what it is, though. The GUI design here might be doing it a disservice by intentionally not having as much hierarchy. But this is actually a really bad argument for why CLIs are better. That’d be like arguing that closets are better for organization than shelves because when you haphazardly throw everything from your shelves into your closet, your room looks cleaner when the closet door is shut.
This does not demonstrate that at all. This just demonstrates how bad a UI can be, if no thought goes into it at all.
Not everything has to be visible all the time, settings can be grouped, and the user can be guided through the settings piece-by-piece, instead of just putting every option next to each other.
This does not have a GUI because making a good GUI is alot of work + the target demographic are more technical people that are able to use the CLI, so why put in all the effort?
Many of the settings are unnecessary, for example, input file format switch: I would prefer a computer to figure out this for me. And there is no need for all those "display X" switches because you can display everything at once.
CLI is useful for something you know and want to automatically reproduce. But it sucks if the thing you want to do is one-shot or too rare. You read the docs, few tutorials, type the command, aaaand the task is done, the knowledge is gone. I’d just sit there with a black screen if every time I wanted to change a wallpaper I’d have to type out something like `sudo desktopctl -X --ignore-duplicates -f aspect -c 180 ~/path/to/image.jpeg`.
An actual GUI for openssl tasks could be hugely more user-friendly than the one depicted here. If anything, it demonstrates that a GUI interface could be superior (for non-scripting use, obviously), because the depicted version is meant to illustrate the CLI experience.
Maybe that's also why visual programming never took off. There's just a sense of "power and control" that comes with raw text that's unmatched in GUI apps.
I agree with your point about CLI. At the same time, I wish we had more GUI *inside* CLI. For example, an interactive and pretty MAN page that's not just text, but has clear borders, boxes, buttons (with keyboard shortcuts), and uses different colors for different sections (e.g., command description, arguments, examples, etc.)
I think there's a strong case for a lot of systems having both a GUI and a CLI, because there are purposes each excel at, and a user may want to be able to switch between them depending what they are doing.
https://www.marketwatch.com/story/delta-hires-law-firm-seeki...