Comment by H4ZB7 | Hacker News Reader

Comment by H4ZB7 | Hacker News Reader

Parent Full thread

terminal is useless garbage. i literally have PTSD from using the mouse scroll wheel while reading a man page because for the longest time there was some obscure misconfiguration or bug in my terminal or something above it: you would scroll and some random pieces of text here and there would not render. whenever i read a man page on that system, i would realize i missed an important part later on because the bug where that piece of text doesn't render was present. this isn't because graphics programming is hard, it's because the terminal is obscure error prone crap that nobody not even the most die hard hackers want to learn to configure properly (the most die hard only learn enough terminal stuff to look smarter than their peers, and stop at that)

the idea of your program not doing graphics, but instead invoking and interacting with a simulated model of a teletype (a device nobody born after 1990 even knows what is) so then the graphics stack can render its behavior to screen is completely asinine, like on the "anyone who uses this in their work should be fired" level.

i could never decide what's stupider, this or the C language. both were obsolete 30 years ago. yet diehard patriotic nostalgia tripping nerds who have no idea how software engineering works but just want to learn complicated things to look cool fought tooth and nail to keep this crap alive for decades. whenever someone says "the UN*X way", they really are saying, "I designed something modularily, you could have never thought of that", but what it really means are all these insane nonsense ideas that don't even begin to make sense, like:

  -a filesystem centric security model that doesn't even begin to address real world use cases
  -C
  -ad hoc encodings that never mattered like octal, everything being a int<my machine word size>
  -*sh
  -perl, tcl
  -terminal emulators
  -DNS
  -all these shitty little tools that compose horribly, like sed, where you have to pass --sandbox to make up for the fact that it indeed composes horribly
  -web and email, which are thoroughly embedded in UN\*X influence, and ergo, suck big time
  -X.509

this is why open source sucks and is barely a competitor to proprietary garbage running in your IoT device. in fact, every single vulnerability in them springs from these bad ideas.

i have

> this is why open source sucks

It's not about "open source", it's about compatibility. Changing the terminal text protocol is akin to changing a public API and would break programs. Actually, it's worse than changing a public API as you get no error and either nothing happens or the wrong thing happens and there is no good way to signal versioning (you can do some communication in "raw mode", but in the default buffered/cooked mode you can't really).

Almost all your gripes are about compatibility, really.

i said open source sucks because the community is on UN*X mentality.

why does the console (it should be called console, as terminal refers to a setup that was obsolete 30 years ago) not have a proper input line? why does pasting a newline make it run? i should be able to type a command and edit it in a line that is a separate UI element from the text output. there is no compatibility argument here. only 0.001% of programs actually need to do anything other than be run and output text (and just text, not escape characters that do funny stuff). there's no dilemma that you love to imagine where changing it to work this way would cause massive incompatibility problems. we could even just make a new console called dumbtextconsole that works this way

viewing some logs from the shell is annoying as hell because the input goes into the program and once the program exits the shell runs whatever you typed. this is obviously a bad UI design. you will always have this stupid invisible buffer that you have to keep track of in your head the number of times you accidentally typed a letter there. if you ssh or tmux in, then you are more likely to enter bogus characters by accident when mistyping a command to ssh/tmux. the argument that its needed for compatibility is still moot if you only want a console for running commands. you dont need those interactive commands either. those are the most bogus hacky scripts that serve no purpose. i dont need a terminal to edit files either, that can be done with a proper GUI that runs outside the console.

it's also a security vulnerability the way shell input works. since you might paste something with a newline on the end and it will automatically execute. the idea that you should be responsible for what's in your clipboard is just bogus. you are resorting to some ad-hoc philosophy to argue this. if there was simple a proper input line where you pressed enter to run it, this wouldn't be a concern.

that one python shell.. Dreampy does this, no problem. the insane user who thinks it's a thing for some function to hijack random parts of the terminal[1] has his program break, and the rest of stuff just continues to work

this post also answers the "there are no alternatives" hackjobs in this comment chain. clearly there are alternatives, i just stated some, and once you follow this line of thought it actually leads to an entirely different OS (duh, why did i even have to state this, oh yeah, because you're disingenuous hackjobs). the fact that these people have the audacity to claim that UN*X, which is a absolutely highly specific way of designing things, that would never happen in isolation, is the only way to design an OS, proves how big of an issue this is in the software industry.

1. the insanity here being obviously that once you change random attributes about the global shared state, you have to assume other programs don't get the same idea as you and do stuff in conflicting ways

Pasting doesn't run the command in zsh though, with the default settings. I think you can configure bash to do the same, but not 100% sure.

Yea, the default in Bash changed at some point too, but in either case your terminal emulator has to support bracketed paste mode. (Basically it puts an escape sequence before and after the pasted content.)

Ah, the classical problem in the OS which actually lies between the chair and the keyboard.

BTW, those terminal emulators, Perl and the tools allow you to easily debug your IoT device over serial.

The terminal issue it's about configuration; some of them allow mouse actions, such as XTerm.

wait, you're arguing that devices should emulate a typewriter that hasn't existed for 30 years because it somehow makes them easier to debug, while this thread is about how they cause obscure problems that require you to understand escape codes to fix for things as basic as key mapping? perl does not make anything easier to debug... everytime i read perl i have to learn the subset this particular user is using, and everything in perl is a backdoor like 10x worse than bash

If you say that you never debugged bash with bash -x or never read 'perldoc perlintro', because perl it's like an improved awk, sh and bash made into a very simplified C-like language.

Listing alternatives or ideas that don’t suck would help.

Pretty much anything that isn't UNIX?

Unfortunately, the IT industry seems to have at some point decided that UNIX and C are somehow fundamental to computing, and the only way forward is to build more and more layers of abstraction on top of it.

The most depressing thing is that even "indie" OSes buy into this garbage (Serenity, Redox, ...). Yes, you get tons of (crappy) portable software that now runs on your platform for free, but at the cost of being stuck with a lowest-common-denominator API.

Do you mean macOS, Windows or something else? I’m also not sure if ggp’s concern is a terminal per se (as in a rectangular box of monospace text) or its mechanics, so which software or behavior are we talking about?

It’s a sincere question, because I also believe that user interfaces could be better and there is a room for discussion, but ggp only enumerated observable downsides without explaining how to transform them without losing functionality. Maybe I’m thinking in-the-box, but how could I e.g. control process groups if a terminal was just a canvas and some app wouldn’t support C-z? Or if a process group is also “UNIX”, then what’s the alternative to, well, a group of processes? The initial comment brings many questions without mentioning anything that could at least direct the line of thought.

Unix and core utilities are easy to implement and run everywhere. NetBSD runs on a toaster. A Z-Machine interpreter runs text games under 2MB under Musl based OpenWRT, a C compiler like TinyCC and DFrotz. A tiny Perl edition with that, under 16MB. I ran Linux (yes, OpenWRT) under an AMRV5 machine with 32MB of RAM, 48 with the compressed ZRAM. I could script things local and remotely in these constrained specs.

For tiny games (and applications) in these machines, SDL ran everywhere, so most 320x240 and 640x480 ran on these embedded machines. Uberportable, fasts an dedicated UIs existed such as the GP2X menu. Thank libre software and Unix like OS and libraries for that. SDL and framebuffer based software exists, such as PDF readers and video players. Thus, you could design an electronic billboard for ads in the streets/subway with very little and a ridiculous power cost, being the big screen the most costly component here.

Back in the day, for SCUMMVM (Lucas Arts adventure games) they used tons of Unix utilities to generate the engine and data handling, they saved lots of hours on engineering. The same happens today. These small tools, with little preparation (The AWK programming language, man ksh, "perldoc perlintro"...) can do in days what for the programmers of non-Unix OSs took weeks of clumsy Python hacking.

>performance performance

UN*X does not have anything that makes it inherently performant in contrast to a sanely designed OS with one language instead of 10 that all do the same thing, a terminal emulator which is by design non performant, and a bunch of text formats that are also non performant and have bad semantics

> These small tools, with little preparation (The AWK programming language, man ksh, "perldoc perlintro"...) can do in days what for the programmers of non-Unix OSs took weeks of clumsy Python hacking.

no, it really can't. if you are string flinging on such a high level, your code is broken to hell. the reason perl awk bash sed suck so much is that they are intrinsically insecure the moment any input anywhere can be controlled by an adversary (and just wonky and gets in the user's way without even talking about security). working around that requires extreme levels of discipline that go far beyond programming in a real general purpose programming language (java, C#, ML, Pascla, Ada, etc). the moment you are able to write a secure *sh program, you are spending 3x as much time per line of code than in a real language.

Unix is designed with C. C it's the Unix API, among some additions, like Posix. Advanced Programming in the Unix environment is your guide.

>Perl/awk/sed suck so much...

Perl replaces awk, sed and sh and it's far better than python for system scripting. Python with whitespaces it's a clusterfuck.

>Secure sh program.

Perl has pledge(4) and unveil(4) support under OpenBSD from base. Far better than Java and C#. And I consider OpenBSD the correct BSD descendant following the best philosophies from Unix, even if I use Hyperbola GNU/Linux as a daily basis because of the freedom of sharing. And OFC a good bunch of OpenBSD tools are installed here, such as Oksh and sndio, doing proper audio mixing in userspace (and loopback monitoring, cool for WebSDR's and radio tools). Easy peasy. Try that with Windows.

Reply on news.ycombinator.com