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?

@astrid for the latter phantom os is the closest i’ve seen to pause and restart even on power loss computing, many of these are interesting ideas with roots in other systems that unfortunately didn’t take off. one of the reasons i became interested in computing history is to see these very ideas

@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?

> no fread or fwrite, only mmap()
Multician spotted.

@niconiconi @astrid funny thing that I realized recently. Apparently fread() won't return partial reads, unlike read().

the mmap thing seems kinda painful though, I would rather use something like

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

@MisakaMikoto @niconiconi @astrid this is because C stdio exposes the same semantics everywhere over the raw syscall. on unix they're easily conflated because C stdio does little magic on unix, whereas it does on other platforms (newline conv on windows, text encoding on mainframes, etc.) except on unix, fread protects you from PC lusering

@libc @MisakaMikoto @astrid
> fread protects you from PC lusering
Ha! Best one-line summary ever.

@astrid at least 2 is feasible in plan9 and you can sorta mimic 3 depending on how you use it

1 and 4 are extremely interesting to me though. i wonder if oberon had something like #1. something like urbit does #3 and i feel like it should be able to do #4 but i'm not sure
@rats @astrid NLTSS satisfied #1 and to my recollection several other capability systems do as well
@rats @astrid As for Oberon, all the variants I know have a flat file system as opposed to representing it with directory trees or a directed graph

@rats @astrid Speaking of #4, on Linux, you can do process checkpoint and restore today. Although it's a complex extension, definitely not a primitive operation.

@rats @astrid
2 is feasible in wayland and reasonable to configure in #sway.

🥰 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

@mxmxyz @astrid also holy shit now I want a typed filesystem, things would be so much easier!

@stuebinm @astrid "A version control is a data structure" 💞💞💞💞

@stuebinm @astrid @mxmxyz I actually disagree with this last point--the distinction is "workspace for the software to do its thing" vs "object that the user cares about".

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 …)

@stuebinm @mxmxyz @astrid it depends a lot on the system, but yeah, you've essentially turned the filesystem into a key-document store, with the schema management that implies.

@stuebinm @astrid @mxmxyz > to annoy c programmers: make 0x0 a normal, usable address that can actually store data

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 @stuebinm @mxmxyz yep! i sometimes do embedded work and this is absolutely something you will get caught by unless you watch out for it in particular :) i've def seen platforms where NULL is something other than (void*)0

@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

@stuebinm @mxmxyz @k fwiw i have seen some codebases where an entire 4k page is reserved for "null-ish" pointers. this lets you return NULL and also staple an error code to it!

👉 All memory is immutable, and copy-on-write at the hardware level, with versioning as a primitive abstraction on top of that

@vy @astrid I keep waiting for Hardware Transactional Memory to show up on chips, and speed up all my existing STM code...

@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"

Sign in to participate in the conversation
Tiny Tilde Website

ttw is the unofficial Mastodon instance of We're only smol, but we're friendly. Please don't be a dick.