1001
168

Developer appreciation time!

5mon 3d ago by discuss.tchncs.de/u/Natanox in linuxmemes from discuss.tchncs.de

You can't copy and paste into a GUI, and it's painful to help people to use them.

Or pipe GUI output into another GUI function.

Or >> log.txt

So you want newbies blindly entering scripts to there command line and not knowing what that are doing.

They're blindly doing it either way. I understand and want GUIs as well, but dumping commands into terminal is starting to seem easier than "go here click this, now click that"

Open "app" -> open menu -> select option -> change this /  push this button.

Just as easy to write as a command. But many people (me included) is so used to go the CLI route that the GUI way is only an afterthought.

Just as easy to write as a command.

No. First you, the helper, have to find the option in the gui. Then you have to look up every step in the path through the gui. At every step you have to find the english name for the button/menu (localization exists), and manually type it (because you can't select and copy the text of the gui (by default at least)). Also just referring to buttons by name sometimes won't work. It is so cumbersome.

I can't find this menu, where is it?

Now you have to go figure out what they're actually looking at and whether it's what you said to do or not. Command line copy-paste removes any uncertainty.

And where a typo can cause a catastrophic outcome

If it's "oh, you can open up [application X] and it's easy to figure it out, and there's videos out there to cover your use case", then ok.

But if it's to help a user with a very specific task and they want their hand held, well from a GUI perspective I'm either making a bunch of screenshots or maybe even a tutorial video or a screen share session.... Or I shoot them a relatively short CLI command that does it and move on to other things.

It is usually much shorter to tell someone the CLI to do something than it is to try to train them on a GUI for the same thing. If it's well-trodden subject matter, well they probably already found a youtube tutorial and didn't even have to ask.

Teach them to double check against the man page before pasting, would be my guess.

But then the CLI wouldn't be faster anymore and the whole argument most people keep bringing up falls apart.

Also those man pages aren't even remotely written to be understandable by Linux novices most of the time…

But then the CLI wouldn't be faster anymore and the whole argument most people keep bringing up falls apart.

It is much faster for the one giving the answer. Also, the looking up the man page is something you only do the first time. With the gui the user should also verify before blindly following instructions, but it is usually harder to find proper documentation of gui features than cli commands.

Also those man pages aren't even remotely written to be understandable by Linux novices most of the time…

That is a fair point. They are dense, technical and at times pretty hard to read. But when a novice asks for help they are always going to either trust blindly or verify. Verifying can be a difficult task for a novice no matter if gui or cli is suggested. I do think most novices would trust the gui way more and feel more in control of it, even if they are basically doing the same thing.

Have you read the btrfs or zfs man pages? They are very well written. You just have to want to understand it. If you don't, let it handle your tech-buddy or admin, or have them quickly look over the command that is about to be confirmed with pressing ENTER.

their* they/those*

Ideally piping directly from curl to bash, yes /s

basic_task_list = ['copy and paste', 'install package', 'type', 'keyboard', 'read and write' ]

for basic_task in basic_task_list:
    print(f"""
        Newbies can't {basic_task}.
        They never {basic_task} in windows.
        Windows  has replaced {basic_task} with copilot, this is what linux needs to do to compete.

        How will linux ever hope to attract windows user if it still maintains this ancient hacker 1337xor tools like  {basic_task}?

        Users just want to turn on computer and watch it do computance - how does linux not get this?
    """)

What's easier to support?

"Ok, open app commandX,
now click on the button labeled Y.. It's just there, just below your mouse cur... oh now you've moved your mouse... no, not there, it's more to the left, up a bit... down a bit, it's labeled Y. Third one from the top.
Yes, that's the one, now click it.
ok, in this pop up you type "super secret code thing',
no, capitalization doesn't matter.
Yes. I'll spell it "s u p e r {space} s e c r e t {space} c o" what do you mean, you don't have a T on your keyboard? "

Or. "Open up the terminal and type this code: commandX --CodeY This will do XYZ. After it's done, can you tell me the error it says on the screen?"

But yes, I agree, the GUI looks nicer.

Exactly. You can tell someone to type a command, and ask for the output. Otherwise you're spending 90% of your time asking someone to explain what they see, and searching for buttons that just move around from week to week.

I dgaf about support. (i'm naturally perky).

Back in dos there was a systemic encouragement to users to at least learn something about a computer. Nowadays windows apologists seem to relish how much it dumbs down computers, (or any over supported system).

They won't learn to ride the bike until someone removes the stabiliser brackets - and Gates is one of the cunts who figured out that he makes more cash by welding them on.

When I need to help someone with a GUI, I ask them to send a screenshot and then I put red circles on it for them lol, or number labels on the things they need to click on.

Yep, this is just one factor. It's difficult for people not to judge a book by its cover.

Correctly done, cli is superior for a lot of things.

I've been in a situation like this recently and all I can say is that the CLI is universal.

Yes, it is complex. Yes, it is challenging. But it gets things done.

Don't be afraid.

I know what you mean, just beware: in lots of cases it's not as universal (as in distro-independent) as some still think it is.

For people who want to get things done with their PC that isn't inherently IT-related (like, doing office work or music production or anything else) and just need to do the occasional light sysadmin thing like setting up new drives to be auto-mounted somewhere, pointing to GUI tools is just so much better. And in many cases it is also safer (making your system fail on boot with a small typo in the fstab is painfully easy).

I get where you're coming from. But as something of an enthusiast myself I don't always know GUI tools for all the tasks I can do in a terminal. Edit: typos

True.

As someone that started in Linux, for real, with Debian, and in a time that I had to mannually install my graphics card, I learned the way I did things on Debian was significantly different from things got done on other distro families. That, alone, kept faithful to the Debian tree.

Yeah, I'm with you. I fucked up my Deb install because I strayed from "doing things the debian way" and overtinkering with things I wasn't meant to do.

But compared to other distros, debian feels like a bomb bunker; once you set it up, it's going to stay set up.

Monolith is a word that fits Debian very well.

It's like a landmark. It just exists and reality itself seems to bend around it.

I ran a Debian machine, a laptop, until the hardware literally gave up. Eight years of solid service. Regular updates and one reinstall to move to the next version.

It kept working. It kept playing music, playing videos, managing my office needs, surfing the web and receiving my email. Flawlessly.

It outperformed newer machines in its last years and people could not wrap their heads around the notion.

Debian, as a Linux+FOSS combo is a winner combo

I know what you mean, just beware: in lots of cases it’s not as universal (as in distro-independent) as some still think it is.

This is especially true when we start talking about BSDs and other non-GNU platforms.

Also, GUI changes faster than CLI, CLI has ALWAYS more options, and you can save those commands to a file.

Also can get explanations for every command.

It's not even that complex, it just looks that way if you're not used to using it

It isn't, I admit. But the first impression is intimidating.

"I'm having an issue with Windows"

"Please open CMD.EXE and run sfc /scannow and DISM.exe /Online /Cleanup-image /Restorehealth
If that doesn't solve your issue, you need to reinstall Windows
Hope that helps!

I cant think of a time that sfc scannow or dsim cleanup has ever fixed a problem

It worked for me on an issue once. Which, tbh, is worse than it never working, because it gave me hope and a reason to keep trying it in the future.

Same.

I reinstall my windows partition every like year.

I have had DISM work a handful of times for work. SFC has never fixed anything.

It saved me like 5 times. Windows didn't and still doesn't like my computer windows 11 especially

If you actively edit/delete some system files non-essential for boot, but that would break some integrated features, sure. But random corruption of protected system files? If that happens, you're not fixing anything without changing your storage and/or the rest of the hardware anyway.

I think we should just add a button on the desktop that runs both of those.

We'll call it... "New All"?

You forgot to start with shutdown /g

Hope that helps.

no chkdsk?

Tbf cli help is copy paste, GUI help is something I didn't want to help with even when I was being paid for it

I find it’s the GUI tools that are usually cryptic, especially when you want to do more than the most basic operations.

A lot of devs don't put much work into planning the flow of their GUI from a user's perspective and it really shows.

IMHO a UI should offer everything a user can do in a given moment, readily available, nothing hidden behind more than a single menu. If something isn't currently possible, it shouldn't be available, and if the dev chooses to make the option visible but unavailable, it should be clearly and visibly marked as something that can be available (grayed out text for example).

I think devs tend to overestimate both the skill of the user, and the usefulness of their UI.

a UI should offer everything a user can do in a given moment, readily available, nothing hidden behind more than a single menu.

That would be a nightmare for any sufficiently complex software. Can you imagine how dense the UI would need to be for something like Blender or even Excel if literally every possible option of "things available to do right now" had to be at most two clicks away?

Bud theres obviously exceptions for massive suites like that. But I'm talking about apps with built in UIs that the dev clearly threw together as a last minute thought. Apps with every single thing you could possibly have to do either burried deep in 10k submenus, or hastily packed onto a window.

All I'm saying is there should be a clear and obvious workflow. Devs shouldn't be afraid to say "I know better than you, do it this way". Throwing every single tool on a toolbar like with Office suites or editing suites is awful IMO. Gimme menus, but gimme menus that make sense (looking at you Microsoft)

Anyway, you can disagree with me, and it won't ever effect you, that's the beautiful thing about the open software world. My opinions can be total shit, and you get to just ignore them 🥰

Sorry for rambling, I'm losing my mind a little bit more every day 🫡

I don't really disagree, at least in principle. You're absolutely correct that workflows should be clear and developers often do not make good UI/UX. You just didn't really qualify your original statement with any of that and made it an absolute, but you've clarified now and I'm pretty sure we agree.

For excel as an example isnt it already like that? One click to the ribbon/menu, one click to the option, and maybe a 3rd if that option had a nuance dropdown

That's when you go to alternativeto.net and get a different one. If you're running into that problem then you just are using the wrong tools.

We're talking about programs that are equally useful in both GUI and CLI, we're not talking about libre office which is necessarily complex or a video editing program with a thousand transitions. Those are always going to be cryptic and always going to be GUI.

The problem with CLI is it can't be made easier with a different interface.

The problem with CLI is it can't be made easier with a different interface.

That's what TUI (like ncurses) is for.

Nah

  • CLI is relatively consistent, UIs keep changing; documentation on how to do X will be outdated extremely quickly and unlike CLI those changes aren't documented nor searchable
  • GUIs are straight up not documented, you can't know an option exists unless you stumble on it
  • Even if the GUI is explicit enough to count as documentation, you can't search a GUI; the CLI documention can be searched for keywords
  • You can't automate GUIs if the need arises

I'm not against GUIs in general, but they should always be supplementary to CLI, otherwise you end up with windows

otherwise you end up with windows

Windows without the garbage? I'm okay with that.

No, Windows as in "this setting is hidden under this menu, that submenu, here click to open another sub-window...". This will happen any time a dev tries to arrange settings in logical way (instead of flat list of toggle and input boxes), because "logically belong together" and "actually often used together or one after another" are not the same, and also dev logic, internal system logic and user logic are also three different things. Result - mad maze

Which is why many tinkerers like CLI - at least one can run man something or something --help in most cases

I feel like a dinosaur at work because many times I have no idea how to use the different programs there, mostly because everything is so incoherent (to me).

And I don't mean a large living dinosaur cracking trees in two while chasing my dinner.

I mean a bunch of sad brown bones held up by sticks in a dusty museum everyone walks by.

Look honey , it's the HugeNerdosaurus

So? I want to see the T rex!

Yeah, man is clutch... I wonder if people would be so intimidated by CLI if everyone knew how easy it was to learn commands with man

A lot of people are afraid of text. Like, they see text on a screen and get visibly scared. Weirdest shit ever.

I get what you meant, I was just making a little joke, though I feel like there's a huge difference between shitty ui that can't be bypassed and reasonable ui that still can't be bypassed. The latter is usually managable and tolerable.

I personally prefer having both options but in general I go with a UI.

Oh. Sorry, I got too serious :)

To do this setting, you have to open up regedit, and....

That part of Windows isn't so pretty. A quick copy-paste of a CLI is so much better than opening up regedit. Powershell has improved this, but for a long time this was the approach for settings microsoft couldn't be bothered to make intuitive UI for.

This guy operates systems.

I'm a big fan of Mint specifically because they spent so much effort making just about everything accessible from a user friendly GUI. I totally agree with you, every time I see this kind of thing online I die a little.

Most people don't want to become an expert in the task they want to do. They just want to do it once. CLI tools demand expertise.

Unfortunately in Linux, UI tools often take away some of the transparency you get with the CLI tools they're made for.

I've recently tried setting up a VPN connection to my workplace using the EndeavourOS configuration UI. It basically just said "can't connect, haha, fuck you", so I had to dig deeper. Finding out how to use the CLI commands necessary to identify and fix the problem took some time and effort, but in the end, I managed to set it up successfully (turned out most Windows admins still think l2tp is hot shit while the Linux world considers it obsolete).

In this case, UI wasn't as user friendly as CLI, because it hid vital information that was necessary to solve the problem.

A better UI would probably have solved that problem quicker and easier. In an ideal world, you get intuitive GUI tools that cover all use cases and you still have the option to use the CLI if you want to dig deeper. So yeah, I agree with the point you're making - Mint trying to be as user friendly as possible by offering accessible UI tools is a good thing and one of the reasons why Mint is so popular. (It's also a reason why Windows sucks ass, because for most UI things the CLI equivalent is either non-existent or cryptic as hell...)

The point I'm making - GUI tools should always try and make using the CLI unnecessary. Taking away complexity without taking away functionality is the key, and as a consequence, those GUI tools will not be underappreciated for sure.

You should open a bug report saying that the GUI hid the error from you. That's a problem.

It definitely is, and yes, you're right, I should open a bug report.

But then again, you could make the argument that a user-friendly OS shouldn't require developer level expertise that's necessary for opening bug reports in the first place. After all, bug reports require a certain quality level that's not obvious to newbies (like how to reproduce et cetera).

I've noticed this problem as well, as a Linux novice. I stick mostly to GUIs, but a few times I've had to figure out the command line equivalent for whatever I'm trying to do because the gui program would just close and provide no further feedback. Then I get to the same step in the command line and it gives me a whole paragraph of explanation about why it failed and how I can fix it. This info should've been available in the gui version, maybe like a popup error message in windows

I'm glad we're in agreement.

It all comes down to how complete and good the tool is, both for CLI and for GUI. I've seen GUI tools that give more information than the equivalent CLI, and of course I've also seen the opposite as you have.

What grinds my gears the most though is when there's no tool at all, you need to edit some config file, and the instructions given are nano /path/file.conf (or, god forbid, vim). It's a text editor, why not use a normal one?! There are no guardrails either way to ensure the format is correct!

Obviously in that scenario someone should make an interface to edit the config safely, be it GUI or CLI, but that's another matter.

Speaking of which, the latest Mint released ~yesterday added a GUI to make common edits to the grub bootloader. See: https://www.linuxmint.com/rel_zena_whatsnew.php“System Administration”. I am not aware of any CLI that can do this, I think before this you had to edit a text file and hope you got it right. At least as far as common recommendations go.

I agree on CLI text editors. I get why they exist, but for most users they should be a last resort, not the primary instruction.

Instead of telling people to use Nano, just tell people to edit the .conf in a text editor and let them choose!

Many users won't understand that what they're being told to do with Nano is literally just edit a text document with a funky file extension, and that they don't actually have to that it in CLI (in-fact it might even be easier not to if you're not familiar with them).

Exception for helping someone who sshed into something and doesn't understand what they are doing.

It happens that someone without knowledge has no idea how to interactively edit a file on a system they can only ssh into. 'run nano' is easier than 'ok, now I'll show you how to WinSCP the file down edit it, and put it back, but make sure you don't screw up the CRLF or permissions in the process...'

Then the problem is the GUI not showing the full error text.

The problem I have is that the GUI tools are very specific to distros, dms, and releases. It's a problem that arises from having so many choices.

CLI tools work long after they're deprecated and very often cross distros.

Something as simple as getting your IP address can be in diferent areas, the settings->network panel isn't even a safe bet. A lot of distros are now putting a network or wifi icon in your tray, but it doesn't always look the same, can be hidden, isn't in the same place.

Ifconfig and ip work on everything and can be installed on almost, if not every, platform.

If you do a web search for how to find your local network address in linux using the GUI, you're given a choice of a bunch of different places to look and the reccomendations don't line up word-for-word with what the current menus in KDE->settings look like. What's more interesting is when I go into kde-settings and do manages to find Wi-Fi and internet instead of network connections, it doesn't give me my ip, it's all just blank.

And a lot of desktop distros know how to suggest installation so if I type ip addr it might say do you want to "apt install iproute2"? or dnf or whatever I need to make it work regardless of distro.

But if I'm trying to use a GUI it's harder to figure out how to make a GUI tool appear. What's it's package name on this distro? Should I be using Flatpak and if so where's that? Etc. And this lack of assistance isn't (just) bad design because I don't know how you'd design a GUI where I can go "I want the NetworkInspector tool" and it just does the right thing.

My favorite part of Linux troubleshooting is you get to enter all these command line commands that barely make sense and in the end nothing works because they're meant for glibktw-6.32ajqx_rc4.1 but in the three weeks since that obscure forum post was made, every distro moved to glibktw-6.32ajqx_mgtk+2 and nothing works anymore.

“Join our Discord server!”

From the comments I fail to understand why it has to be one thing or the other.

I want both. Not only that, I would love GUI tools that show the CLI commands for doing the same thing in real time, so I would learn them with examples of things I actually want to do.

I've been saying this for a while now. A good gui doubles as documentation.

It doesn't have to be one or the other. It's just a rhetoric that was jokingly pushed on back when communication wasn't worldwide, immediate, and lacking context. It has now been repeated ad-nauseam by people that have no idea of why it was said in the first place.

Some GUI tools are efficient. Some CLI tools are efficient. Sometimes, both are efficient. It depends on the tool AND the task at hand. Unless you're taking internet memes at heart, then use whatever.

Well, to be honest, I do sometimes mock (in a friendly manner) some coworker that are using GUI almost exclusively. The only reason I do that is because the exact same task could be accomplished in a fraction of the time with minimal CLI knowledge. But even then, it gets the job done.

Unfortunately for newbies and GUI tool developers, I rarely use GUI tools and thus don't know of many. I do agree that GUI tools have better accessibility and discoverability, but they also have worse performance and are just generally more work to make and thus many developers of enthusiast tools skip the GUI.

Yes. I do tell my newbie friends about any graphical options I am aware of.

Then they ask, "Thank you. Does it work well?".

And I admit, "I have no idea. I just use the command line."

Then they paste command I shared into the terminal and watch it finish successfully before the graphical tool has finished downloading.

It's unlikely I will use your "accessible" GUI tools, but I applaud you for making them, even if they're shit. It's like art, the more art there is, the better the world is, even if I personally can't appreciate some of it, I acknowledge the greatness of it's existence.

I blame absolutely nobody for wanting a GUI tool for things. But the idea others are at fault for being hesitant or unfamiliar with the tool is also disingenuous, especially when the GUI just adds another layer of abstraction to the tool while removing some of the functionality (as GUI tools often do).

It's like you're learning to ride a bicycle. I get that you like the training wheels and they are extremely useful for you, and more experienced cyclists SHOULD be understanding and accommodating, but they can also see the ways they're holding you back, and it's natural for them to want you to take them off as soon as possible.

Also, CLI is consistent across any distro... GUI tools, however, vary depending on your desktop environment, distro, version...

Also, CLI is consistent across any distro...

This falsehood crashed so many devices and left so many beginners with error messages it isn't even funny anymore.

Okay, it isn't 100%, but it's certainly MORE consistent than GUI, and since GUI is generally just a front-end for CLI anyway, if the CLI is inconsistent, so is the GUI, so it's not as if GUI avoids this problem.

It is much easier to convey CLI instructions over the internet.

ffmpeg is great, and doing simple things is pretty straightforward, but if you work with a lot of media and do different kinds of operations, give Shutter Encoder a shot, it's an amazing FOSS GUI tool for ffmpeg, yt-dlp, and more!

ffmpeg ❌

ffmpreg ✔️

Interesting. Their website would make me run away fearing it's from a cheap fake download button scam from ten years ago, but the software itself looks pretty legit.

LOL I found the github page before the website when I discovered it. So many folks mention Handbrake, but after canceling my Adobe subscription, using this was the first time I wasn't missing Adobe Media Encoder.

You can copy-paste commands tho. Writing a concuse GUI tutorial is more work. Whether I want to do that depends a lot on who that work is for

"accessible GUI tools" be like

That's just dishonest.

Honestly, Windows MMC tools are one of the oldest and most dependable ways to:

Manage printers

View logs

Manage devices and drivers

Manage group policy

Manage MDT

The interface is almost 30 years old and it is prone to crash. Microsoft cannot seem to rewrite tools that replace the snap-ins.

There are some alternatives, such as diskpart to replace diskmanagement, but nobody is talking about replacing devmgmt with PowerShell or regedit with PowerShell for reg commands for the one off or the lay user.

Also, attempting to duplicate printmanagement with devices and printers has resulted in a loss of functionality for managing printer ports and drivers. Attempting to manage printers through just PowerShell is pure madness as you can't properly parse the vendor options.

If you have made it this far, thank you for hearing me out. I'm not sure I actually made a point, but I do feel better.

There are already PowerShell commands for reading searching and updating registry entries. I don't think anyone is replacing one with the other, though.

Devices and Printers in Windows can go to hell where it belongs.

I guess I wasn't clear. The average Windows user isn't aware of PowerShell and would hardly be able to use reg itself. I agree that it is a great tool for managing registry in an environment, but I have seen professional technicians darn near cry over using cd to traverse directories.

Hey, and PowerShell commands aren't GUI, bringing us back to the point of this post...

Yes, and I've ran in to several guides that have used the powershell regedit commands instead of the GUI. Not only do the commands already exist, but they're absolutely something some prefer over the GUI, even on Windows.

It's relevant. From about 1995 to 2006, Microsoft was pretty much hard set on 'cli is dumb, do nothing cli wise, cmd is a concession, but a crappy one'. As an artifact of that, you got regedit, a godawful 'GUI' that took a messy datastore model and just kept it ugly, in a way that would have been pretty much better as a CLI interface.

Microsoft started getting the idea again, but in true Microsoft fashion, had to reinvent the wheel and did PowerShell to try to create a CLI ecosystem from scratch rather than trying to build anything vaguely familiar. To their credit, for first party stuff they did a fine job enabling it, though third party applications remain a mess to this day. It does highlight that even Microsoft figured out that CLI actually does make sense a lot of the time.

Windows registry is an absolute horror show even without the GUI lmao.

At least on linux you will usually be greeted by a nice integrated GTK or Qt layout.

Windows is 40% archaic stuff from the 90s, 40% tirefire PWA/electron apps, and 20% of normal design that keeps them barely ahead of OSX.

20% of normal design that keeps them barely ahead of OSX.

Where does one find this 20%?

The window snapping introduced in vista/7 and the old start menu from vista/7.

Actually I might need to reduce that percentage lmao

The issue I have with GUI and wrapper tools on Linux is that I don't know how they have implemented the standards, I know several tools that only deals with the basic stuff and leave you high and dry for the advanced stuff.

Which I feel is missing the point, if you have a gui it should support advanced stuff as well as the basic stuff, else you will train your self wrong, and have to unlearn a lot of crap

Vastly faster for something users do once a year at best...

I just don't know about the GUI tools and wouldn't know how to help people with them. Of course I'm not really enthusiast grade anymore and don't offer Linux help but yeah.

Shout out to Vorta Backup, Borg Warehouse, and TrueNAS for allowing me to back my PC up without typing a single line of CLI.

GUI tools can be great, I live using then but I hate writing documentation for them.

Documenting CLI is much easier to do and maintain than documenting GUI. A few lines of text that I can adjust if needed vs a pile of screenshots.

For a one off issue it's easier to send a cli command they can copy paste than to detail steps in the gui.

In the long run it more often than not is better to show them how to help themselves though. Let's say they use Mint and want to install something they saw from ElementaryOS, so a new Flatpak repo: Of course in this moment I'd be done faster with their request for help sending them two commands to just paste, but showing them where they can add the new repo themselves and how this will make all the new apps pop up in their Software Store doesn't just make them more independent and reassure them in trying things themselves, but will make it less likely for them to constantly ask you for help again.

And it makes more people stick with Linux, that's always good.

yeah true, I've been annoyed in a similar way when using blender where people always answer how to do things with the keyboard shortcut rather than the name of the command but the keyboard shortcut they say won't work for me because I'm using the Maya keyboard layout...

There was a whole team of "engineers" that once told me, "using infrastructure as Code obfuscates things, using the GUI allows us to see exactly what is happening!"

They did not appreciate it when I told them to "git gud, or GTFO".

Subsequently the company hired 5 more automation engineers like me and the two dozen of ClickOps "engineers" were let go. Our productivity is even higher with the 6 of us compared to more than two dozen of them.

GUI is nice for hobbyists and mainstream consumers.

I mean, there are definitely use cases where gui makes more sense. For example, utilities like GParted or KDE Partition Manager make messing with partitions much easier since they're easier to deal with visually (imo)

GUI enables high level view and inspection of large data sets. I ain't reading Mona Lisa byte by byte.

Don't know what using infrastructure as code is supposed to mean.

Don't know what using infrastructure as code is supposed to mean.

It's not "supposed" to mean anything. It's a well defined and commonly used term you can easily find on a search engine.

Config file setups. Makes sense. Didn't know that term for that very simple thing. Could have been less rude.

We both know the "supposed to mean" comment was the rude thing to say here. And no, your summary isn't nearly as accurate as "infrastructure as code".

I finally got Docker Desktop to work over the weekend, after months of not being able to sign in - from a browser or CLI.

Some GUIs are nice. I prefer GUIs to CLI. But some GUIs aren't as usable as CLI

You are not alone. It also took me months to sign in.

I like using Podman Desktop to keep an eye on containers and glance at logs, but more often than not I'm doing most operations on the CLI.

It's pretty easy to explain why people prefer CLI over GUI programs. You have to learn a new interface for every single GUI program, whereas you learn one interface for every CLI program.

CLI requires remembering commands though, or developing patience with your up arrow key.

And if you want help, is it “/h” or “/?” or “-h” or “—help” or “—h” or just “help”

I can’t remember that I need to pee, let alone what commands do what, save for my up arrow.

Don’t get me wrong, I’m in the terminal constantly, but I’ll pick a GUI over CLI every time if it’s an option.

That's just wrong, the correct commands are always different. E.g. for journalctl to keep following the newest entries you need -f, while in dmesg you need -w for the very same feature. That's not any more "the same" than it is the "same" to move your mouse around a differently organized GUI.

Writing in the CLI is comparable with moving the mouse, and remembering the appropriate commands of the specific tool comparable to know where to click on. However a proper GUI is immediately visible to be interacted with (and not abstract like most CLI arguments) and will convey function through form, while the function in the CLI is hidden behind help texts and man pages.

I do like working with the CLI a lot, but what you said was simply wrong.

I don't need someone else to make a gui to enter commands for me.

Please learn how to use the shell, everyone wins. Learning how to use the shell will enable you to do all kinds of things. Learning how to use some Gui will help you in that one instance, until that dev decides that it needs to be made better and prettier and you start looking for shit again

So... I'm definitely cheering up for the lady in red.

Why? Am I an elitist asshole doing his best to sound smart?

Well yes, definitely BUT I also appreciate the power of the command line. The CLI isn't "cool" because of the cryptic command, no the CLI is cool because :

  • ls (list files)
  • ls *.txt (list all files ending with the .txt extension)
  • ls *.txt | wc -l (count how of them are)
  • etc

and the "etc" is the FUNDAMENTAL part! Namely that no matter how smart the GUI developer is, they can't predict how it is going to be used when done with OTHER tools. That's the true power of the CLI. So yes if you stick to a single command, the CLI is unnecessarily cryptic but as soon as you start to combine commands, nothing comes close to it.

Simple things can work well in GUI.

Now, working on a GUI that tries to expose every little features? No thank you. I would not want to develop it, and I would not want to have to use it.

It's ok to go install a software through discover instead of using the CLI.

It's always fun when there's a GUI tool for something (in my case, trying to set up wireguard with gnome) that just doesn't work, and all the posts online about it just say "yeah that's literally never worked, here's the cli command"

Or colour profiles for your monitor in Wayland, you can change them in the gui but nothing will ever apply.

I find myself having trust issues with Linux GUI tools as actually functioning seems to be optional. But the switches sure look pretty...

The only thing enthusiasts love more than obscure CLI commands is random github links. The next time someone sends me a github link without explicit instructions on how to turn the contents of that link into a program on my computer, I'm hiring some witches from Etsy to hex them

Shoutout to qpwgraph devs

Nobara driver installer and disk auto mount GUI <3

Does it really have it's own thing for auto mounting drives? Cause you can use Gnome Disks or KDE Partition Manger for that, which both offer a nice GUI for that.

Yep, it's simple and just a list of drives, some troubleshooting instructions, and check boxes, but that's all it needs to get the job done. Brainlessly check the boxes and problem solved. It fixed my ssd not mounting on boot without me screwing up fstab again.

Whats the setting called in KDE partition manager? I don't think found that one yet.

I'd say the ideal situation is that tools are developed library first, then cli or gui as preferred allowing others to pick up the slack and make the other tool (or tools) using the functions in the library.

One of the reasons automation is so much easier on linux than windows is because there are many more cli tools to do things. On windows many tools are gui first and cannot easily be automated.

Step 1: Try several tools until you find one that works.

And how would I pipe the output from your GUI tool into another GUI tool?

Not to be facious, but in simply asking this question you're already beyond the scope of the people most GUI tools are designed for (I.e. novices who either don't need this tool often enough to learn the CLI, or don't need the advanced features you'd get from doing so).

By using a file?

Tbh I use CLI tools on my M4 Mac too because it saves time and it's more efficient.

yesterday I had to use the dd command dd - - help didn't help much

install tldr and then you have easier commands

> tldr dd

  dd

  Convert and copy a file.
  See also: `caligula`.
  More information: https://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.html.

  - Make a bootable USB drive from an isohybrid file (such as archlinux-xxx.iso) and show the progress:
    sudo dd if=path/to/file.iso of=/dev/usb_drive status=progress

  - Clone a drive to another drive with 4 MiB block size and flush writes before the command terminates:
    sudo dd bs=4M conv=fsync if=/dev/source_drive of=/dev/dest_drive

  - Generate a file with a specific number of random bytes by using kernel random driver:
    dd bs=100 count=1 if=/dev/urandom of=path/to/random_file

  - Benchmark the write performance of a disk:
    dd bs=1M count=1024 if=/dev/zero of=path/to/file_1GB

  - Create a system backup, save it into an IMG file (can be restored later by swapping if and of), and show the progress:
    sudo dd if=/dev/drive_device of=path/to/file.img status=progress

  - Check the progress of an ongoing dd operation (run this command from another shell):
    progress

Why not just read the man page?

I feel like it's a nice intermediate step when learning the commands. man is great when you already know you have the right tool and you just need to check a flag. A newbie who just left Windows is gonna be so overwhelmed by a lot of manpages, but this does a nice job of easing them in using examples to give the user an idea of what that tool is capable of.

Try:

man dd

I'm sorry but I am the man and man code stipulates I never request the help of another man

Valid

It's situational.

Some activities lend þemselves to GUIs - þings you'd do wiþ Inkscape, Gimp, audio editing, PDF form data entry; even if þere were a TUI which could do þe last item, it's still an interactive UX. Þe pointer is a more natural interface for some workflows.

Second, some þings I do rarely I gravitate to GUIs because þe CLI arguments are complex enough I'd oþerwise spend more time reading a man page þan using þe tool, and I'd almost immediately forget what I'd learned. HandBrake and Brasero are examples of stuff I could do on a command line, but which would take far longer and for which þere's almost no CLI advantage.

Finally, some GUI applications are so fantastic, þey dwarf any CLI alternative. Calibre and KeePassXC are examples. Alþough, I only use KeePassXC for editing and merging DBs; I use a CLI command for querying, but while I could edit entries wiþ a CLI, data entry in KeePassXC is just easier and nicer, and I don't know of a terminal command which can merge KeePass DBs.

GUIs have þeir place. Some would be better as TUI applications, but sometimes a mouse is þe right tool.

I just had a stroke reading this.

ɪt kæn ˈɔːlweɪz biː wɜːs

Interesting ðat you don't distinguish ðe sound in "ðe" and ðe sound in "þing".

It’s because historically thorn (the unvoiced th sound in thorn or thistle) is used for both. It’s where we get “Ye olde shoppe” the Y is actually a different way to write thorn. Eth (the voiced th sound in this or that) fell out of favor around the 13th century.

Even earlier: 1066! Þere's a specific year for þe deaþ of eth because thorn had replaced eth completely by þe Middle English period, which officially starts at þe Norman Conquest of England. Þe evolution you describe is because wynn had fallen out of use by þe 13þ century, and thorn was evolving into wynn.

And þen movable type killed all þe rest of þe Nordic runes, and þe Normans conquerors did a number on English spelling, trying to make spelled like French. Poor, abused English!

Þat fact about "Ye Old" is one of my favorite bits of trivia. You're fantastic!

bemselves and bings.

Look, you can't bring thorn back like this. You only annoy your readers.

If there is a cli variant, why do you feel the need to do the same in a gui, its slower, most of the time far uglier... All in all just not as good as the cli tool

Because using a gui is easier for novices

To the extent that is true, then the novice doesn't end up asking for help. The goal is that the capability is discoverable. Or if it's really a bit harder, there are hopefully tutorial youtube videos that cover the use case.

But when a user asks for specific help on a task they couldn't figure out for themselves, or are asking for help with a 'something went wrong' dialog box, well helping with CLI is much more feasible than the involved mess of trying to basically make video tutorials ad-hoc, or screen share, or try to help them find the obscure log file an application wrote somewhere with the real error.

Thank you!! Great point

Spot on.

I think the problem lies in the usage of commands from the internet, if you take a look at the commands, they get very straight forward and easy to use. Also i never said that the commands where hard, or you need to use them. If a newcomer uses a gui its fine, but for the most power, and least resources, the cli is, ans will always be, the best.

I see your point there, but it is just far easier to give an answer in command form, than telling people where to click on a GUI.

But i do understand what you are saying, and i cant argue with it. GUI tools are good for early users, and those who dont want to use the CLI. CLI is better for those who want/need that extra power.

I dont help them at all, i am here just trying to understand the people who help others. Also, do you want people to help or not? Do you help ppl? I think you should appreciate any help you can get. Even if it is the evil CLI help.

Two-day suspension.

Mimimi, you are soooooo cute, trying to get me to stop saying the truth on the internet. My friend, if you want to stop me, then ban me. Please!

Truth, my ass. I've read your recent comments. You're just being a self-righteous dickhead with a false sense of superiority. You derive your self-worth from being a contrarian.

Thanks for giving me a reason to report you :3

Rule 2: be civil

I apologize for the misbehavior of one of our users. The person was warned for misbehavior on other instances and was unrepentant. He even had the audacity to act arrogantly and curse me out per DMs. Upon discussion with other admins, we decided to permanently remove the user and warn the user shall he see this that any alt account of his we become aware of, will be permanently banned from Feddit.

Hä?

Watching my team member trouble shoot yesterday. Stops every 20 seconds to look up kubctl commands. After watching painfully for 15 minutes I show them freelens, a kube ide. They said they like command line because nobody using guis know shit. Again, they said this while having to keep the man page open.

I know kube, I wrote small contributions. I just don't memorize or need every fucking describe out to json command. I have a giant fucking image with green yellow red dots and right click to shell in. I can see every fucking configmanp, namespace, etc on my screen.

Tldr, these folks are morons not good at their job.

Edit: Good Lord, look at the comments 🤣. Thank you fedverse for driving that nail home so perfectly. 2026, year of the Linux desktop.

Same thing with git.

There is no shortage of git beginners that refuse to use a GUI.

They ask for help for something, I haven't used git CLI in years, so I tell them "go to this place and click those button", then they open the vscode terminal and ask "but can I do it from CLI?" Okay then I go to search the command. Meanwhile I tell them to checkout a branch or something as basic as that and watch them struggle for way longer than it took me to find the command I was looking for.

I get that thousands of elitists have convinced you that using git from a GUI is a sin. But it's fine, I won't tell no one. I use a GUI myself.

I'm a creature of habit with git 🤣. I really only use 3 commands that are muscle memory though. But you bet your ass i merge on the GUI.

The main issue with the Linux CLI specifically is that all the tools have antiquated APIs. Inputs and outputs are all strings.

A modern CLI would be designed to take structured input and emit structured output. This would also provide better discoverability and reduce the chances of typos.