A gui is helpful sometimes, but there’s a lot of cases where there’s no feasible way to make a good gui that does what the terminal can do.
Right tools for the right job.
For example, a gui to move a file from one folder to another is nice - drag and drop.
A gui that finds all files in a directory with a max depth of 2 but excludes logs and runs grep and on matching files extracts the second field of every line in the file? Please just let me write a one liner in bash
Not much of a picture guy personally but I see your point.
Edit: I have spent a decent amount of time organizing books and comic books and that was a pretty even split between GUI and Terminal. GUI to get them in a state that I could bulk rename/move into appropriate directory with the Terminal. I assume it would be similar with pictures.
I see a lot of people saying they have to use a GUI tool for partition management, and I’ve never understood why.
Text based tools like parted are fairly easy to use, at least compared to other terminal tools the same people are able to use for other tasks.
What is it about partitioning that needs a GUI when other tasks don’t? Is it the visual representation of the partition layout? A general fear of borking a disk?
Is it the visual representation of the partition layout? A general fear of borking a disk?
Yes
Being able to see it helps a lot. I can and have done it via parted. My media server doesn’t have a desktop environment installed. I just really would rather have a GUI when it’s available as an added safeguard.
Problem nowadays is that changing partition tables is so rare that parted changes their commands between uses, and I never remember if fdisk nowadays has all the GPT related issues that made me try parted in the first place ironed out. Plus I can’t remeber the new GPT commands and partition IDs.
I still mostly just read the help text every time because nothing else is installed - but from the speed I might be a bit faster with a well designed GUI nowadays if it is about modifying GPT disks. MBR disks I still can do with fdisk in my sleep.
That’s just not true. Not without lots of hand waving.
In my terminal I can, and pretty much hourly do, combine many programs in chains of input and output to perform specific tasks and get information I need. And that’s how these programs are designed to be used. The programmer builds it to do specific things and then the user can combine the program with others in novel and nearly endless ways.
With a GUI, sometimes that’s possible between two programs if you can copy/paste between them but it’s much less reusable and a lot more tedious. But usually it’s just not possible because they’re designed for specific user personas and not as general purpose tools that may be part of a script.
Generally I would agree that anything can be made with a GUI with enough investment. But the point where diminishing returns don’t give enough return on GUI investment are reached much sooner than a scriptable shell environment where a power user can extend it in ways that would only make sense for that power user or a very small number of users.
To play the opposite team a bit here, I like the idea Android uses of Intents for something like this. I think it falls apart a bit in reality because app companies kinda want you in their garden and so don’t often do the work to keep things interoperable. That and the use cases from users on phones don’t frequently involve cross app functionality. But the ability is powerful for apps to say “my app needs a user photo” or one of my faves “my app needs a pgp provider (for the password store app)” and then let the other app do that piece of functionality as determined by the OS, which tracks a lot of those providers and lets the user decide which to use.
Put those two statements together and the logical conclusion is that Linux users simply want everybody to be tech-savvy (although I’d use a different term: computer-literate). What’s wrong with that?
Not everyone has the same interests. All car people would love everyone to be car people. All bikers would like everyone to ride bikes. The difference is that you pretty much need to be interested in computers to run Linux.
Nobody capable of defining an algorithm in a visual flowchart like that isn’t also capable of doing it in a CLI (or at least, in text in general – writing a script). It’s thinking through what you want to happen that’s the hard part; expressing it in the UI is trivial in comparison.
Things like that have been around for a long time. It was like two decades ago that I saw this shader scheme in softimage|xsi.
For implementing something like that, each node in that graph would have an array of inputs and outputs. Each of those would have a type like vector, scalar, colour, string. Then you only allow connections if the inputs and outputs match types (though you can also have conversion nodes or selectors that say pick the red channel of a colour to turn it into a scalar). Each input can be set to a constant value instead of connecting something else to it. Outputs don’t need to be connected, which is mostly useful if a node has multiple outputs. Then each node has an evaluation function that takes all input parameters and maybe internal configuration parameters (though you might as well make everything an input param since there’s no real functional difference) and uses them to calculate the outputs, which it then sends on to anything connected to those.
I’m not much of a UI guy but displaying it for the GUI would just involve drawing boxes or some shape for the node, then spaces for each of the inputs on the left side and outputs on the right side maybe colour code them by type, and lines running along the connections. Then just add the name and/or other visual information you want to display and positional information to let users move it around their work area.
'Course, there’s a reason those things basically never catch on, which is that they don’t actually reduce the inherent difficulty of figuring out the algorithm, and for anything non-trivial messing with a whole bunch of drop-down lists and shit is more cumbersome than just typing the damn thing.
This right here, you can gui a single program, but with pipes we can chain nearly infinite programs. No way can you make a gui that is that flexible, I refuse to believe until I see it
You can have your GUI do anything a terminal can I guess, but you’d need a few million buttons on that gui where the programmer has anticipated each and every combination of CLI command that you are going to use, encoded that to a button or menu, included text entry boxes for each variable and have bundled every program, application and dependency that has ever existed. Totally possible.
A gui is helpful sometimes, but there’s a lot of cases where there’s no feasible way to make a good gui that does what the terminal can do.
Right tools for the right job.
For example, a gui to move a file from one folder to another is nice - drag and drop.
A gui that finds all files in a directory with a max depth of 2 but excludes logs and runs grep and on matching files extracts the second field of every line in the file? Please just let me write a one liner in bash
A GUI makes simple things simple.
A shell makes hard things possible.
Me fucking with hard drives/partitions : GUI please
Me doing pretty much anything else - Terminal
I always install gparted in the live environment 😂… cuz… yeah, I can fuck things up and end up without my data 😂.
Really you never organoze gigs of photos? That a gui task
Not much of a picture guy personally but I see your point.
Edit: I have spent a decent amount of time organizing books and comic books and that was a pretty even split between GUI and Terminal. GUI to get them in a state that I could bulk rename/move into appropriate directory with the Terminal. I assume it would be similar with pictures.
I have a GUI file manager that I never use but I got it because I know at some point I’m going to want to be able to see thumbnails of images.
deleted by creator
I see a lot of people saying they have to use a GUI tool for partition management, and I’ve never understood why.
Text based tools like parted are fairly easy to use, at least compared to other terminal tools the same people are able to use for other tasks.
What is it about partitioning that needs a GUI when other tasks don’t? Is it the visual representation of the partition layout? A general fear of borking a disk?
Yes
Being able to see it helps a lot. I can and have done it via parted. My media server doesn’t have a desktop environment installed. I just really would rather have a GUI when it’s available as an added safeguard.
Problem nowadays is that changing partition tables is so rare that parted changes their commands between uses, and I never remember if fdisk nowadays has all the GPT related issues that made me try parted in the first place ironed out. Plus I can’t remeber the new GPT commands and partition IDs.
I still mostly just read the help text every time because nothing else is installed - but from the speed I might be a bit faster with a well designed GUI nowadays if it is about modifying GPT disks. MBR disks I still can do with fdisk in my sleep.
A CLI makes simple things easy to implement.
deleted by creator
That’s just not true. Not without lots of hand waving.
In my terminal I can, and pretty much hourly do, combine many programs in chains of input and output to perform specific tasks and get information I need. And that’s how these programs are designed to be used. The programmer builds it to do specific things and then the user can combine the program with others in novel and nearly endless ways.
With a GUI, sometimes that’s possible between two programs if you can copy/paste between them but it’s much less reusable and a lot more tedious. But usually it’s just not possible because they’re designed for specific user personas and not as general purpose tools that may be part of a script.
deleted by creator
Generally I would agree that anything can be made with a GUI with enough investment. But the point where diminishing returns don’t give enough return on GUI investment are reached much sooner than a scriptable shell environment where a power user can extend it in ways that would only make sense for that power user or a very small number of users.
deleted by creator
How would you implement piping in GUI?
Could you show us an example program with a GUI you created for this?
To play the opposite team a bit here, I like the idea Android uses of Intents for something like this. I think it falls apart a bit in reality because app companies kinda want you in their garden and so don’t often do the work to keep things interoperable. That and the use cases from users on phones don’t frequently involve cross app functionality. But the ability is powerful for apps to say “my app needs a user photo” or one of my faves “my app needs a pgp provider (for the password store app)” and then let the other app do that piece of functionality as determined by the OS, which tracks a lot of those providers and lets the user decide which to use.
deleted by creator
Yeah, and doing this would take significantly longer to use every time than typing up a chain of commands in a terminal.
deleted by creator
Linux users: Non tech savvy people? Yuck
Also Linux users: Everyone should be running Linux instead of Windows!
Put those two statements together and the logical conclusion is that Linux users simply want everybody to be tech-savvy (although I’d use a different term: computer-literate). What’s wrong with that?
Not everyone has the same interests. All car people would love everyone to be car people. All bikers would like everyone to ride bikes. The difference is that you pretty much need to be interested in computers to run Linux.
Nobody capable of defining an algorithm in a visual flowchart like that isn’t also capable of doing it in a CLI (or at least, in text in general – writing a script). It’s thinking through what you want to happen that’s the hard part; expressing it in the UI is trivial in comparison.
deleted by creator
I’ve probably spent more time looking up how to access specific functions in a GUI than for CLI.
Wow, you created this program for creating shaders visually? That’s impressive! You mind sharing the source code?
Things like that have been around for a long time. It was like two decades ago that I saw this shader scheme in softimage|xsi.
For implementing something like that, each node in that graph would have an array of inputs and outputs. Each of those would have a type like vector, scalar, colour, string. Then you only allow connections if the inputs and outputs match types (though you can also have conversion nodes or selectors that say pick the red channel of a colour to turn it into a scalar). Each input can be set to a constant value instead of connecting something else to it. Outputs don’t need to be connected, which is mostly useful if a node has multiple outputs. Then each node has an evaluation function that takes all input parameters and maybe internal configuration parameters (though you might as well make everything an input param since there’s no real functional difference) and uses them to calculate the outputs, which it then sends on to anything connected to those.
I’m not much of a UI guy but displaying it for the GUI would just involve drawing boxes or some shape for the node, then spaces for each of the inputs on the left side and outputs on the right side maybe colour code them by type, and lines running along the connections. Then just add the name and/or other visual information you want to display and positional information to let users move it around their work area.
https://en.wikipedia.org/wiki/Automator_(macOS), or in general, https://en.wikipedia.org/wiki/Visual_programming_language
'Course, there’s a reason those things basically never catch on, which is that they don’t actually reduce the inherent difficulty of figuring out the algorithm, and for anything non-trivial messing with a whole bunch of drop-down lists and shit is more cumbersome than just typing the damn thing.
This right here, you can gui a single program, but with pipes we can chain nearly infinite programs. No way can you make a gui that is that flexible, I refuse to believe until I see it
They tried to replace programming languages with drag-and-drop toolkits too. It can be done, but sometimes there’s a reason we don’t do it.
deleted by creator
Most programmers are bad at UX but not nearly as bad as GUI designers are at understanding abstraction.
deleted by creator
Most programmers are bad at both lol.
So true!!!
You can have your GUI do anything a terminal can I guess, but you’d need a few million buttons on that gui where the programmer has anticipated each and every combination of CLI command that you are going to use, encoded that to a button or menu, included text entry boxes for each variable and have bundled every program, application and dependency that has ever existed. Totally possible.
Agreed 👍.
I don’t think I’ve ever used grep outside of a CLI.
Surely you’ve used something roughly equivalent like searching a text, be it web page or other document, for a word or filtering a spreadsheet?
How would one use grep for a webpage in a browser? Does the page need to be accessed outside the browser?
You should be able to use curl to get the HTML and then pipe it to grep.
Emacs grep lets you run grep, and formats the results in a buffer from where you can then easily visit the files at the match location.