Is it time to look at database-first operating systems again? There have been a few. Tandem's Guardian was very well regarded in its day. Unfortunately, Tandem was acquired by DEC/Compaq, which tried to move it to the Alpha around 1997. Then, after HP acquired what was left of Compaq, HP tried to move it to Itanium. (There was a MIPS version in there somewhere.) After all those bad decisions, in 2014 it was finally ported to x86, by which time few cared. There's still an HP offering.[1]
In Guardian, the database system owned the raw disks. There were no "files". If you wanted something that looked like a file, it was just a blob in a database entry. Everything was transaction-oriented, like SQL. That was the whole point. Everything was a redundant, recoverable transaction.
The OS was cluster oriented. Adding or replacing servers was normally done without shutdown. Databases were replicated, and you could add new disks, wait for them to come into sync, and remove the old ones.
All this in the 1970s. They were way ahead of their time.
- Direct disk access bypassing kernel fs, check.
- POSIX-like API standard, check. (ANSI SQL)
- Structured data storage with ACLs, check.
- Volume management, clustering, replication, RAID. Check.
- "Everything is a $FOO" philosophy, check. Where POSIX has files, RDBMS has tables.
- CLI/shell, check.
- Installable apps, check. (you can create stored procs by INSERTing java/javascript/etc into system tables).
Probably more parallels that don't occur right now. Lots of companies use the DB as their primary OS with the underlying kernel relegated to starting up the DB and configuring the hardware.