Satire or not, it’s still correct lol. Terminals and terminal emulation need to be destroyed. Modern systems with graphics and windowing systems are not VT100s and that’s a good thing.
Sorry, I should have been more clear. I agree with you. I’m not talking about text-based interfaces and commands. I just mean the way Unix/POSIX handles “terminals” (devices that accept streams of characters according to a protocol established in the 70s) is an antiquated way of handling simple plain text streams. It made sense back then when there was a need to send commands to dumb terminals in-band with the plaintext but this doesn’t really make sense these days when your “terminal” is actually just a program pretending to be a dumb terminal running inside a window. When was the last time you used job control instead of opening another window?
I’m probably the wrong person to ask if they’re using Unix-style features because I do use them. Hell, most of my RaspberryPI (and other SBC systems) I only ever use over the serial console and SSH. It’s the most natural way to interact with a computer.
Job control is something I do use. I regularly background processes, run other tools, and the foreground the prior ones. I’ll also launch GUI tools from the command line often. I launch ArduinoIDE, vscode, freecad, gimp, many others from the terminal. A common one is to be doing terminal file management, or git repo management, and then launch nemo with “nemo . &” to bring up a file explorer in the current directory.
I also use screen (never moved to tmux like I should have). I’ll ssh into servers and run screen to manage projects, edit code, and do long running processes in the test phases before deployment.
I’ll also suspend vim to drop to a command line. It’s faster than moving back to the mouse and waiting for another terminal. When I’m done, I foreground vim and get back to work.
I send OS signals with kill and such. Yeah, I leverage there terminal, process controls, and OS level signals. Should and average suer do this? Unlikely. My kids don’t (mostly GUI only work for them), but over time they have been inching forward on gaining more control over their Linux machines, so they’ll be doing process control soon enough. Especially for things like Minecraft and Terraria servers that they’re now starting to host for friend groups.
If not a character stream parsing based terminal input output system, what would you propose instead? The current computing models are merely the accepted approach, and if a better one comes along I’m all ears.
Ummm… Do people not realize this is satire? 😅
It’s very poorly done
“satire”
“Humor”
Edit:. Btw who are you asking about? I see one other top-level comment besides yours and no replies to it.
It was just a general comment because of all the downvotes. 😅
Weird, I see no downvotes either. Just 5 upvotes.
Satire or not, it’s still correct lol. Terminals and terminal emulation need to be destroyed. Modern systems with graphics and windowing systems are not VT100s and that’s a good thing.
Ummm… Nope. You’ll pry my terminal from my cold, dead hands. There’s no faster way to get many system tasks done than the command line.
I use GUIs all day, but there’s almost always at least one terminal open on screen because that’s where the real work gets done.
Sorry, I should have been more clear. I agree with you. I’m not talking about text-based interfaces and commands. I just mean the way Unix/POSIX handles “terminals” (devices that accept streams of characters according to a protocol established in the 70s) is an antiquated way of handling simple plain text streams. It made sense back then when there was a need to send commands to dumb terminals in-band with the plaintext but this doesn’t really make sense these days when your “terminal” is actually just a program pretending to be a dumb terminal running inside a window. When was the last time you used job control instead of opening another window?
I’m probably the wrong person to ask if they’re using Unix-style features because I do use them. Hell, most of my RaspberryPI (and other SBC systems) I only ever use over the serial console and SSH. It’s the most natural way to interact with a computer.
Job control is something I do use. I regularly background processes, run other tools, and the foreground the prior ones. I’ll also launch GUI tools from the command line often. I launch ArduinoIDE, vscode, freecad, gimp, many others from the terminal. A common one is to be doing terminal file management, or git repo management, and then launch nemo with “nemo . &” to bring up a file explorer in the current directory.
I also use screen (never moved to tmux like I should have). I’ll ssh into servers and run screen to manage projects, edit code, and do long running processes in the test phases before deployment.
I’ll also suspend vim to drop to a command line. It’s faster than moving back to the mouse and waiting for another terminal. When I’m done, I foreground vim and get back to work.
I send OS signals with kill and such. Yeah, I leverage there terminal, process controls, and OS level signals. Should and average suer do this? Unlikely. My kids don’t (mostly GUI only work for them), but over time they have been inching forward on gaining more control over their Linux machines, so they’ll be doing process control soon enough. Especially for things like Minecraft and Terraria servers that they’re now starting to host for friend groups.
If not a character stream parsing based terminal input output system, what would you propose instead? The current computing models are merely the accepted approach, and if a better one comes along I’m all ears.
Or maybe terminal emulation needs to be brought up to speed with modern computing. New terminal specs and all that.
Nothing is better for remote computing and administration than a terminal. It’s far too data data dense for anything to be competitive.
Nothing is better for quick and easy iteration of programming ideas than a quick text output in a terminal.
It doesn’t need to be destroyed, it needs some iteration. It’s an old technology with a lot of cruft.
Yeah, I agree. I should have been more clear lol. See my other comment.