@astrid
🥰 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

Follow

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

Sign in to participate in the conversation
Cybrespace

cybrespace: the social hub of the information superhighway jack in to the mastodon fediverse today and surf the dataflow through our cybrepunk, slightly glitchy web portal support us on patreon or liberapay!