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.
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.
