3 ms·
I'm wondering a lot how things would look if we would stop emulating 100 year old tech and build a CLI environment from scratch today. Do some projects in this
by still_grokking 4y ago
I'm wondering a lot how things would look if we would stop emulating 100 year old tech and build a CLI environment from scratch today.
Do some projects in this direction even exist? Or are we going to stick around with abstractions of things even most people's grant great parents haven't ever seen because this tech was already long obsolete at their time?
- tekknolagi 4y agoSee https://arcan-fe.com/ https://arcan-fe.com/, in particular Lash: https://arcan-fe.com/2022/10/15/whipping-up-a-new-shell-lashcat9/ https://arcan-fe.com/2022/10/15/whipping-up-a-new-shell-lash...
- still_grokking 4y agoStill reading, but this looks on first glance very much like something in the right direction. Thanks for the links!
- thanato0s 4y agoLooks super interesting. Thanks!
- still_grokking 4y agoWOW! The architecture is perfect! This looks like the future. It does everything 100% correctly. (Now "only" the rusty Unix commands need to get evolved into some proper interactive language and this would be the perfect CLI.) I'm impressed heavily. Going to install this ASAP to play around with it.
- 0x008 4y agoI wonder what computers would be capable off if we would develop a new stack from the ground up (bits and bytes) with the silicon in mind which we have available today…
- still_grokking 4y agoHey, that's my idea! We should get rid of all the historic accidents. Really. Imho it's completely crazy how computers "work" today. Modern computers still need to emulate "a PDP-7" because that's the only kind of machine C runs on fast. But the sequential command stream machine (which is the abstract machine of C) is extremely inefficient. It's a mayor pain to extract parallelism from an inherently sequential command stream! We built crazy shit like "hardware JIT compilers", that are embedded nowadays in all CPUs, only so the CPU can maintain the PDP-7 illusion to the outside world (which is, in the end, still C, and nothing else) even it's a proper data-flow machine internally. But because all the SW world is build in C (or languages that work the same) nobody invests in alternative architectures. Because C would not run fast on such machines, and they would fail in the market if you would need to rebuild the whole SW world first to get any advantage. C (and, tragicomicaly its portability) was a trap! And we will die a painful death even before anybody would start to think to finally remove the von Neumann bottleneck (which is inherent to sequential command stream machines with RAM). I for my part would love if someone would invest in something like a modern take on the Connection Machine, but build form the ground up with a HW-SW co-design approach. (Of course this would be some work; you would need to build the hardware, which is comparably easy, but also some adequate programming language and ecosystem, up to a completely new designed operating system, and convince people to "rewrite the world" for your new system — which is the hard part). > from the ground up (bits and bytes) In this context it should read "(trits and 'trytes')" (only that we would maybe need a new world as trytes are historically six trits, but would be better 9 trits; so we could directly use a septemvigesimal system, which maps excellently to the English alphabet + "point"), and it should be of course balanced. Time to finally switch to the most efficient information encoding, when we're at it! (Binary was also just an historic accident, chosen because it was most easy implemented on the ancient integrated circuits).
- shadowofneptune 4y agoEnough with this 'emulating a PDP-11' cliche (never seen it quoted as the PDP-7 before). Explicit instruction-level parallelism has its own issues that make it difficult to use effectively, precisely because it must do statically what out-of-order processors do dynamically. The use of C as a scapegoat is odd. What alternatives would have led to a different world of processors? Pascal? PL/I? Experiments in parallelism at the time like Erlang are about process-level parallelism, not the kind of instruction-level parallelism this line of argument calls for. You absolutely can have simpler systems than we use today, but let's not fool ourselves about how we got here.
- lelanthran 4y agoThe Enlightenment terminal had some nice ideas (specifically, displaying image files and videos in the terminal itself). Too bad it was so unstable I stopped using it. Should maybe give Enlightenment another try in the coming year.
- still_grokking 4y agoFor images and videos you want SIXEL support. Quite some terminal emulators support this nowadays. https://saitoha.github.io/libsixel/ https://saitoha.github.io/libsixel/ But that's just another "layer of craziness", imho. (Even it's quite cool). I think the whole terminal should be replaced. Not even with something funky. Just a proper RPC + streaming protocol based on some sane modern tech. (No, no HTTP! Simple and lightweight. Tailor made for the task. So it works also in an embedded setting; and lasts for the next 50 years :-)). Of course it should also have separate control and data channels. (That's a mayor flaw of the "classical" terminal tech. The in-band transport of control is a big PITA, and can be even an security risk).
- csdvrx 4y ago> For images and videos you want SIXEL support. Quite some terminal emulators support this nowadays. And if they don't, https://github.com/csdvrx/sixel-tmux https://github.com/csdvrx/sixel-tmux will give you the best rendering it can do
- cyberge99 4y agoiTerm on macos has this if you install the iterm shel integration. “imgcat filename.jpg” for example will display the image in your shell/terminal.