challenge the axioms of your computing
🤔 filesystem as Directed Graph instead of Tree. no root directory?
🤔 people sharing a single display. several pointers & keyboards with different authorship?
🤔 coalesce the memory heirarchy: no fread or fwrite, only mmap(). internet as numa cluster?
🤔 snapshots + rollback as a primitive operation, applied to running programs. power failure tolerance?
what else seems fundamental but is merely conventional?
@libc @astrid that reminds me, i have yet to read the original paper which Joe Armstrong based his fan fiction (PhD) on: Why Do Computers Stop and What Can Be Done About It?
@MisakaMikoto @astrid The mmap thing from Multics is an interesting idea nevertheless. If Unix is "everything is a file", then Multics is "everything (files, data, code) is a memory segment". Shared objects and dynamic linking naturally arises from such a design, baked into the heart of the architecture. Unlike Unix, which feels more like an optimization. https://www.multicians.org/multics-vm.html
🥰 filesystem as a relational database, heavy use of extended attributes
🥰 data types at the OS level, files are not just streams of bytes anymore. you can pipe commands into one another without having to parse numbers, tables..
@mxmxyz @astrid 🤔 all operations are reversible; you can give a program its output and it’ll return possible inputs that would’ve given the output 🤔 lisp machines with modern hardware? 🤔 why should every process see the same directory structure? manage it like memory instead, with each process having its own “virtual address space” 🤔 to annoy c programmers: make 0x0 a normal, usable address that can actually store data 🤔 remove the distinction between file system and memory entirely. just consider one a fast cache layer for the other. No more fgets & friends; if you open a file you get a pointer, and if you read from it data may be “cached” on a faster bit of memory. A version control is a data structure
And like all saved data, it has a schema. Moving to a functional, pure computer doesn't change that.
Oh, and preferably it's a schema that multiple applications understand.
@astraluma @astrid @mxmxyz hm, I’m not sure — the distinction I meant is that from a program’s perspective, file system and memory are things that are dealt with in very different ways (one involving things like malloc and the stack and possibly a garbage collection etc., the other involving file descriptors and syscalls and a filesystem underneath it all that abstracts the actual block-device away).
Of course, there’s the somewhat aligned but separate distinction of “user-things” vs. “software-internal things” — but that’s not the same thing, we have e.g. lots of cache files and similar things that are definitely files, but aren’t meant for the user at all (and sometimes not even for long-term storage, e.g. meshroom essentially uses the filesystem as memory since it’s a 3d photogrammetry app and its reconstructions are usually just way to large most actual memory).
I think we could live without the first distinction, but I’m less sure about the second 🤔
@stuebinm @mxmxyz @astrid I mean, mmap being the primary way to interact with a file is an approach. (But is potentially contrary to ideas like "files aren't byte blobs, they're managed data structures/miniature databases". Which IMHO is a far more interesting alternative.)
Totally agreed on caches and buffer files. Not sure those are even necessary in the age of 64-bit.
@astraluma @mxmxyz @astrid i think most times the only real benefit of cache files is probably that they’re persistent between reboots — so I guess if we had an easy way to mark some memory as “should be saved & reloaded on next start” it may already go a long way.
As for files-as-managed-data-structures, I guess we’d need some form of dynamic typing built into the memory / operating system? (which raises the possibility of python-like tracebacks when accessing memory — well I guess at least it’s not worse than what we already have? At least I can’t really see a way to statically guarantee that we won’t have type errors …)
I have been told by an embedded dev this is already the case! They said part of the reason dereferencing 0x0 is undefined behavior is because there are architectures where it is completely valid memory.
Of course, its use as an idiom for invalid memory does make things slightly problematic, but they were doing embedded stuff so they had their own alternatives to most null-returning allocating functions.
@k @astrid @mxmxyz I know, that’s why I put it in there! I had my mind blown a while back when I found out that actually this is not some built-in thing that got specified when c (or some other language) was invented and is really just a convention / artifact of the architecture we’re on that we’ve all gotten very used to
👉 All memory is immutable, and copy-on-write at the hardware level, with versioning as a primitive abstraction on top of that
@astrid Slightly more on the social side of things:
Software upgrades don't get versions by their authors. Instead they get versions from their users _after_ upgrading.
"Thank you for upgrading emacs_spacebar! Please take this survey. This upgrade was a:
* Patch level bump
* Minor version bump
* Major version bump"
The interpreter/compiler is the kernel.
Motivating example: https://scheme.fail/manual/loko.html#Future-directions-for-drivers