Live data from Hacker News

A dream of an ultimate OS (1995)

okmij.org

41–50 of 188 posts

Re: A dream of an ultimate OS (1995)

#41
post #8

> But it does not have to be this way. If a database engine is implemented as a core system service, along with simple tools to browse and modify database records, the gordian knot of system configuration files disappears. MacOS comes very close to this ideal, with ResEdit as this universal database editor. Or AS/400, which is more or less a SQL database.

ResEdit was an interesting idea. It suffered from a major problem - terrible data integrity. The original version had to work on floppies, with very slow seeks and writes. So it didn't reach an consistent state until you were all done and closed the resource fork of the file.

Attempts were made to use it as a database, but stuff was always getting corrupted.

The original MacOS suffered badly from being a cram job into 128KB with no hard drive or MMU. No CPU dispatcher, no memory protection, brittle ResEdit and TextEdit. The trouble was, that architecture persisted for 17 years, long after the hardware improved.

Re: A dream of an ultimate OS (1995)

#42
post #17

I can sorta agree; a database with tables and folders would be a much more useful basis for an operating system. After all, most programs will read and parse small configuration files. With a database it becomes necessary. Windows sorta does that with the Registry but A) the registry isn't the filesystem, B) the registry is a filesystem on top of NTFS and C) the registry sucks. If the Registry had the power of,say, P…

The Registry could have been a lot better. It has no schema. Imagine if it had some sort of schema, declaring what sub-keys and values are allowed under each key. Imagine if the schema was self-documenting, with each key/value declaration in the schema had an associated description explaining what it was for. Imagine if it had richer data types. For example, a "link" type, in which a value actually has the name of an…

I think it could, it just required a little more imagination. NewtonOS was released in 1993 so around the same timeframe, lower memory requirements than 1mb and could do this stuff:

http://preserve.mactech.com/articles/mactech/Vol.09/09.11/Ne...

Re: A dream of an ultimate OS (1995)

#43
post #8

> But it does not have to be this way. If a database engine is implemented as a core system service, along with simple tools to browse and modify database records, the gordian knot of system configuration files disappears. MacOS comes very close to this ideal, with ResEdit as this universal database editor. Or AS/400, which is more or less a SQL database.

Tandem had a real database OS. They didn't have files. Just blobs in the database. Their distributed, redundant database system had proper ACID properties. It owned the disks; there was no file level below the database.

This made a lot of sense for a system intended for high reliability transaction servers and nothing else. Banks loved Tandems.

Re: A dream of an ultimate OS (1995)

#44

Earlier quoted context omitted.

Probably because it was a dumb idea. There's no sense storing videos, baby photos and "quarterly report new (2) backup newest 08.2019_john.xlsx" in a database.

If the filesystem itself was modeled after a database (which it can be argued it is, somewhat), it's not much of a stretch for WinFS to have been a thing. I was looking forward to seeing it in action based on reports of what it was.

File systems are databases in a small way. They use b-trees and such, but they don't enforce a rigorous global type system, don't enforce a table structure because everything has to have a schema, don't have the overhead of a query language to interpret every file access command, didn't ensure that all file accesses be ACID compliant, etc.

WinFS imposed all of those things and the associated overheads and much, much more every time you accessed anything.

Re: A dream of an ultimate OS (1995)

#47
post #33

Can someone describe the NEGATIVE aspects of having a database-OS?

First enumerate all of the constraints and guarantees your database provides. All the basic minimum services it provides for every access. Look at the memory it takes to provide those, and the processor utilisation overhead to perform all those checks, and services such as to guarantee ACID compliance, guarantee referential integrity, enforce a global type system, etc, etc.

Every single access of every single piece of data, for anything, will incur all of those overheads every time. There is no way to opt out or choose a different balance of guarantees or trade-offs without implementing them on top of the OS provided ones.

Re: A dream of an ultimate OS (1995)

#48
post #39
post #7

Earlier quoted context omitted.

Does anyone have the story on why this project was actually halted? It reportedly sounded like it would have been a giant leap at the time, had it actually landed.

It was very slow and resource hungry, and also very time consuming to develop things on. Imagine if you were only allowed to write or run applications that ran on top of Oracle. Even if you try to write a program that works on text files, those text files are stored as blobs in an Oracle database.

Isn't that the sort of problem you solve once, though? If you want a "this is just a stream of characters I can do POSIXy things to" interface, that's a library with fread(3) et al in the front, and a query for a single field in the database at the back.
Post reply on HN