[childintime]

Strongly opinionated with a real message, I loved it.

Through the RISC story we pay a cultural debt we owe to RISC. It is story telling, about a time long gone, and the tale is mythical in nature. In opposition to the myth, as the article states, RISC by itself is no longer an ideal worth pursuing.

This is relevant to the other Big Myth of our tech times, the Unix Story, and by extension to Linux. UNIX is mythical, having birthed OS and file abstractions, as well as C. It was a big idea event. But its design is antithetical to what a common user today needs, owning many devices and installing software that can't be trusted, at all, yet needs to be cooperative.

When Unix was born, many users had to share the same machine, and resources were scarce to the point there was an urgent need to share them, between users. Unix created the system administrator concept and glorified him. But today Unix botches the ideals it was once born of, the ideals of software modularity and reusability. Package managers are a thing, yet people seem blind to the fact they actually bubble up from hell. Many PM's have come already and none will ever cure the disease.

Despite this the younger generations see Unix through rosy glasses, as the pinnacle of software design, kinda like a Statue of Liberty, instead of the destruction of creative forces it actually results in. I posit Linux's contribution to the world is actually negative now. We don't articulate the challenges ahead, we're just procrastinating on Linux. It's the only game in town. But the money is still flowing, servers are still a thing, and so the myth is still alive.

The Unix Myth has become a toxic lie, and as collateral Linus has become a playmate for the tech titans. I'm waiting for him to come out and do the right thing, for it is evil for the Myth to continue to govern today's reality.

[kragen]

Listen, if you write a software system that puts more power at my disposal than Unix does, I'm happy to try it. But I suspect the Unix design has more wisdom in it than you think, because when I've tried to do better, even with the benefit of hindsight, I've always fallen short.

[childintime]

Thanks for replying, others just treat me like a troll and downvote, beholden to the myth that Linux is the gold standard. That's exactly the willful blindness I am talking about.

You talk about network effects, as Linux is the only game in town, currently. Implicitly I talk about that too, that's why I mention Linus, I expect leadership. Why develop Linux? There's not much ROI, unless change is the keyword.

Indeed the challenge is to create a new operating system suited to the demands that exist today. Fuchsia is a step, the only thing I can point to right now, but it is hardly accessible.

Note that Android works to overcome the need for a system administrator. That's because Linux works against what it needs to be: an invisible OS. The most prolific use of Linux isn't really a success story.

Furthermore, you suggest "power". Perhaps you talk about piping and shell tools. These are indeed part of the myth, good ideas but, pardon me, terribly executed. They do not compose, they are not scalable. Again because of the time frame they were conceived in, this was impossible. But that is the refrain throughout. As a result everything is just messy, resulting in huge time sinks.

Indeed I hope to one day have the disposition to truly go back to basics, and make a runtime, a substrate if you will, that will run fully inspectable code, with an execution that can be visualized, questioned and reasoned about. That way users and tools can adjust any process, repeatedly, or just once. Incrementally so.

All machine details would be hidden, and that includes (obviously, for me) everything binaries: compilation, ABI's. Something current OSes (not counting the Web) don't do.

In the end the best OS is an invisible OS.

[kragen]

There are lots of exciting options to explore!

[kragen]

I missed the edit window on this but: I don't think you're going to get computers to not be messy and full of huge time sinks. That's just the nature of humanity being reflected in a silicon mirror.

I like the idea of focusing first and foremost on debuggability, on manipulating program execution histories as first-class objects. There are a huge number of interesting tradeoffs there with performance.

What I mean by "power" is that Unix makes it easy enough to do things like "interactive text chat in three lines of code" (untested, and quality at best "usable prototype" rather than "production ready")

    #!/bin/bash
    ch="${2?Usage: $0 /tmp/channelfile}"
    touch "$ch"; chmod 666 "$ch"; tail -f "$ch" &  # chat of the beast
    while read -e line; do echo "<$USER> $line"; done >> "$ch"

or "which other English words might be Greek neuters, plural and all, like automaton/automata"

    grep "on$" /usr/share/dict/words | sed 's/..$/a/' | sort |
      join - <(sort /usr/share/dict/words)

or "which directory is growing in my home directory and filling up the fucking disk"

    du -k ~ > tmp.du.1
    du -k ~ > tmp.du.2
    diff -u tmp.du.[12]

or "build the thumbnails for any images I haven't thumbnailed yet", at least as long as none of them have spaces in the names, using GNU make (untested, but adapted from real code):

    thumbnails: $(patsubst %.jpg,thumbs/%.jpg,$(wildcard *.jpg))
    thumbs/%.jpg: %.jpg
            convert -geometry 80x160 $< $@

or "incrementally update my web pages, making an incremental backup on my server with cryptographically strong checksums" (presupposing something like http://canonical.org/~kragen/sw/dev3.git/hooks/post-update)

    git push

or "incrementally back up this directory onto my USB pendrive with cryptographically strong checksums"

    git push usbkey

or "find out what executables get transitively invoked by compiling a program with this C compiler" (warning, doesn't work if one of your files is called ENOENT)

    strace -ff -e execve cc hello.c 2>&1 | grep execve | grep -v ENOENT

or "show me a treemap of my disk usage so I can see where I can free up some space"

    k4dirstat

or "bring the focus to the URL bar of Firefox"

    xdotool search "Mozilla Firefox" windowactivate --sync key --clearmodifiers ctrl+l

or "bring up the latest version of MongoDB on my fresh laptop"

    docker run mongodb

or "find out which day we were talking about the Spanish Succession"

    grep --color -i succession 2022-10-*

or "share my screen on this server with someone else for remote pair programming"

    tmux -S /tmp/pair attach -t shared

I agree that these tools are messily executed, their scalability needs a lot of work (though don't underestimate https://adamdrake.com/command-line-tools-can-be-235x-faster-...), and their composability is not that great. Also, their usability could be vastly improved. But they're still leaps and bounds ahead of anything available on Android, in the browser, or most other alternative systems.

Simple, hackable data formats and protocols are one thing that enable this kind of thing. But I think the Unix terminal and filesystem is actually the major integration point, not pipes. Too bad they both suck. It would be nice to see successor systems that do better instead of worse; this ought to be feasible but we keep failing at it.

What would a system look like which gave you that kind of power, but to implement Valgrind-style bounds checking or profiling or AFL-style fuzzing with backtracking, and have it run with reasonable efficiency? Valgrind itself, DTrace, LuaJIT, Smalltalk-80, Emacs's "advice", videos of Symbolics Genera, aspect-oriented programming, the CLOS metaobject protocol, Maru, and the Self papers (Ungar etc.) might be places to start looking for inspiration.

[thechao]

At this point, I think "Unix" maps cleanly onto a Chesterton's Gate.