Yes, there is a very blurry line between operating systems, programming languages, and we can include databases as well. Some operating systems as you point out are PLs. Some PLs are implemented as databases. They’re all just really complex accounting systems by nature. Look at the implementation of a lot of OSes, PLs and DBs they are really just made up of tables keeping track of relationships all the way down.
I would be soooo happy if OSes were just absorbed by databases. The file system is just a heirarchal key value store: genius! Let's make it untyped so you have to parse everything manually just to interpret it: not so great.
Yes I'm saying the Unix file system is a worse mongodb. Please at least give me a postgres or something.
Do apps add their own types in that system? Otherwise, I have a hard time imagining a set of base data types that could usefully represent things like OpenOffice documents, geo-referenced geometrical feature databases, and the thousands of other field-specific binary formats that are in use. Storing all these things as data blobs just puts us back in the "untyped filesystem" situation.
Maybe I've completely misunderstood your proposition, though.
If a file emitted by some third party program is intended to conform to some type, yes it would be great if that type was expressed in the filesystem. Maybe that would look like a reference to a 'schema description' file that has a specific format that is bundled with the app.
Now, that doesn't stop MyProprietaryApp from declaring that the type MyProprietaryFile consists of a big bucket of bytes which it then interprets how it likes, but that's inevitable and not worth worrying about.
The point is to enable defining directory and file schemas for my OS and applications that I can control so that interaction and discovery within these systems isn't so baroque.
It's not about relations, it's about schemas and types. My complaint is that none of the schemas and types are communicated by the OS in an explicit, uniform, programmatic way.
Everything in 'special' mounted filesystems like procfs, sys, cgroupsv2, etc as a start. These all use implicit schemas of particularly named files with particular contents that you have to learn about out-of-band to just to do anything.
Requirement 1: Everything has an inspectable schema.
All the configuration files with their own home-grown format that you can only validate by restarting the program that relies on it and hoping that it doesn't crash your system is for the birds.
Requirement 2: Files that must have a particular format must also have a well-defined Type that can be validated to be correct in a uniform way outside the program that uses it.
> Let's make it untyped so you have to parse everything manually just to interpret it
Isn't that exactly how traditional FS work anyway? Even using MIME types only gives you an optional, non-binding hint. In the end you need to parse and interpret the content "manually" (well, usually using libraries).
None that immediately spring to my mind. There are operating systems that incorporate programming languages as their default user interface (like UNIX that drops into a Borne shell and LISP machines) and there are computers that have programming languages baked into their firmware (like the 70s and 80s micro computers did with BASIC). But in neither instance is the language itself the operating system.
The micro computer instance is definitely nuanced though. Some do argue that Microsoft BASIC et al were an operating system. Some don't. I'm in the latter category because I think "BIOS" more closely describes the function of the software on those old micro computers.
For a Lisp Machine the operating system was written in the language itself, this included a network stack and the filesystem interface for local disks.
