[ModernMech]

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.

[infogulch]

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.

[joconde]

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.

[infogulch]

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.

[LAC-Tech]

I enjoyed this post, but I'm struggling to wrap my head around what relations you'd have in this OS. Sym links become foreign keys?

[infogulch]

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.

[p2t2p]

Just a record pointing to another ID? I mean no need to enforce FK constraint for symlink. For hard links - yes, an FK like concept?

[qayxc]

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

[infogulch]

Maybe I could have organized my comment to be more clear. You missed the important part in your quote:

> parse everything manually just to interpret it: not so great.

Except the first sentence, the first paragraph describes current filesystem design.

[pjmlp]

Mainframes like IBM i (actually a micro if being pedantic) use a database instead of filesystem.

[discreteevent]

Bill Gates was keen on that idea too (a postgres or something as a filesystem): https://en.wikipedia.org/wiki/WinFS

[smackeyacky]

I think you would like Pick. https://en.wikipedia.org/wiki/Pick_operating_system

[hnlmorg]

> Some operating systems as you point out are PLs

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.

[ModernMech]

Others in this thread have mentioned some good ones: Smalltalk, Lisp Machines, and the JVM. Some others I would add:

- Pilot was an OS that was essentially bare metal Mesa. It was written in Mesa, only runs Mesa programs, and used Mesa language features for OS capabilities like safety: https://courses.cs.washington.edu/courses/cse550/20au/papers...

- Cedar was both a PL and an OS: https://www.ics.uci.edu/~andre/ics228s2006/swinehartzellwege...

- The Oberon OS and Oberon PL are highly coupled https://people.inf.ethz.ch/wirth/ProjectOberon1992.pdf

- Here's a Scheme OS called MrEd: https://www2.ccs.neu.edu/racket/pubs/icfp99-ffkf.pdf

[rjsw]

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.

[lispm]

The filesystem(s) and the disk driver(s) were written in Lisp, too.

[yjftsjthsd-h]

Also VMs; the JVM is targeted by multiple languages as if it were an OS