*Update on the Mu computer's memory-safe language*
I wrote about it last week at http://akkartik.name/post/mu-2019-2, but already that post is growing out of date. Here's an initial sketch: http://akkartik.github.io/mu/html/apps/mu.subx.html
So far all that works is function definitions with no arguments or body. They emit just the prologue and epilogue code sequences.
But I have a sketch of the next few steps of the design in there.
Starting to wrestle with the problem of safe, efficient array initialization.
Lots of interesting discussion and feedback about http://akkartik.name/post/mu-2019-1 over the last few days. Now that it's starting to settle down I'm starting to work on my "level 2" language: type-safe, memory-safe, manually register-allocated, maps mostly 1:1 to machine code.
Since I'm building it out of machine code, memory management is a perennial concern. My parsing in level 1 has mostly used static arrays. But now I think I'm going to switch to dynamic linked lists and trees. Leak some memory.
#introductions Researching new ways to write software that make it easier for newcomers to understand rather than for insiders to maintain. Systems that build easy, reward curiosity, encourage lots of forks, encourage deleting unused features, make society more anti-fragile. http://akkartik.name/about
Current project: Mu, a hobbyist computer that rewards curiosity. Starts from x86, getting to a HLL with as little code as possible. http://akkartik.name/post/mu-2019-1
(Previous intro: https://mastodon.social/@akkartik/101276175243395515)
How to Read “Gilgamesh”
> The heart of the world’s oldest long poem is found in its gaps and mysteries.
"the computer has almost since its beginning been basically a solution looking for a problem."
*Update on the Mu computer*
I just wrote up a summary of state of Mu, in two parts.
Part 1 summarizes the past year as a sequence of major design decisions:
Part 2 is a sketch of what I plan to build next, again structured as a sequence of design decisions:
(The flow from design constraints to decisions is inspired by Christopher Alexander: https://en.wikipedia.org/wiki/Notes_on_the_Synthesis_of_Form)
Any and all feedback appreciated. I'd like it to be clear to any programmer.
That sudo vulnerability, overblown, caps
The vulnerability requires that you've given a user the ability to run commands as any user except root. Literally. It requires you to specify "ALL" as part of the user specification. Yes, it allows one to override (ALL, !root), but that just feels to me like they were able to step over a speed bump.
So of course the coverage is all "THE WORLD IS ENDING!!!"
Also necessary reminder that https://repo.or.cz still exists if you just want public git repo hosting
necessary because it doesn't self-promote 30 times a minute on link aggregators
Metadata is a new idea here; I use it extensively in my https://github.com/akkartik/mu#readme project. In this context, one possible use for it is extensions. Rewriting the above example:
Swapping the usual meanings of '/' and '.' in Unix seems maximally confusing. I'm choosing here to preserve the meaning of '.' in source code. But that may be the wrong choice.
Anyways, back to metadata. It permits multiple extensions. Say for a MS Word doc:
I'm thinking about https://zge.us.to/dirconf.html
What if `cat`ing a directory rendered its contents as a structured file?
First reaction: get rid of directories altogether. But it seems useful to firewall off different kinds of content from each other.
Still, the file system could support treating files as dirs.
It seems useful to have consistent lexical conventions spanning paths and code: '#' for comments; '.' for lookup; '/' for metadata. E.g. to look up gitconfig:
On the language side I've been thrashing a fair bit:
* Between the OS side vs the language side.
* Between building an interpreted, dynamically-typed language in machine code vs a compiled, statically-typed memory-safe language that I can build the interpreted language out of.
* Between building a Lisp interpreter vs a better shell (in the spirit of http://www.oilshell.org).
* Between making local vars in the compiled language function-scoped vs block-scoped.
This guarantees the in-order, reliable byte pipe service that 9P depends so heavily upon without the massive overhead of a complete TCP/IP stack.
Mass storage devices (at least for now) are specified to expose two files: ctl and medium. ctl exists at all times, and is the control channel for the device. medium exists only when there's a physical medium inserted into the drive unit.
Switches expose their interface via a list of numbered subdirectories. 0/ is port 0, etc.
I'm poking at https://github.com/ozkl/soso trying to figure out where it first switches from Ring 0 to Ring 3. I want to rip out all of that protection stuff and just run everything in Ring 0. Just as an exercise for starters, but also eventually because I have.. notions.
After various attempts to grep, the current plan: I'm going to just try to write to some protected address at various points in the kernel, and binary-search my way to the solution. Let's see how this goes.
*Update on the Mu computer*
We now have structured control flow (with goto statements 😂 )
Compare this screenshot with the ones in the previous message of this thread.
At this point I think I've climbed as far up the ladder of abstractions as I can with just syntax sugar. The next step up will be a new language. It'll still look the same: registers, curly braces, one operation to a line. But operations won't be x86 opcodes anymore. Registers and operands will have types.
*Update on the Mu computer*
A few days ago I found out about a hobbyist OS called Soso: https://github.com/ozkl/soso
Today I've gotten Mu running on it well enough to make it a first-class supported platform alongside Linux.
LoC of C I depend on thus goes down from 12M to 33k.
It's not a complete replacement, though. I still plan to work with Linux, particularly for its networking support. But it's *so* cool to have a minimal stack supporting graphics!
I've mentioned this a few times but never publicly announced it, so consider this the announcement.
I've also ported Owl, my Cocoa Wayland compositor, from OS X to the Hurd using GNUstep.
Here's a screenshot of weston-terminal and weston-flower, running on Owl on GNUstep on Hurd, with X forwarded from a QEMU VM via SSH.