> 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.
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.
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.
And it's tragic when you consider that LisaOS had multitasking, process separation, and I believe a hardware MMU.
The Mac grabbed most of the good UI aspects of the Lisa, but stripped out all the decent OS concepts. It worked to sell the first Macintoshes, but didn't scale out later, and by that time they'd killed off the Lisa.
Yeah, and the Lisa cost $10,000 and the Mac 128k was $2500. You can debate the merits of the hw/sw tradeoffs that got to those price points, but it was pretty clear at the time that Apple wasn't going to take over the world with the Lisa.
> Or AS/400, which is more or less a SQL database.
People keep on saying that, but how really true is it? Many operating systems come with bundled relational databases–e.g. most Linux distributions come with more than one relational database implementation bundled. Does that make Linux "more or less a SQL database"? How deeply integrated is DB2/400 into the OS/400 kernel (or equivalent term, such as "System Licensed Internal Code")? There is a paucity of public information about the actual nature or depth of this integration.
I think an OS with a truly deeply integrated SQL database would expose things like a table/view of all files in the filesystem, a view of running OS processes, etc. As far as I am aware, OS/400 (or "IBM i" as they are calling it nowadays), doesn't have any such features.
Long time AS/400 programmer here. I think the confusion arises from mixing the terms "SQL database" and what IBM refers to as the "Single-level Store" [1]. The AS/400 has true orthogonal persistence, much like a database engine. But for a few specialized exceptions, there are no "files" anywhere on an AS/400 like on a typical operating system. Everything is an "object" (yes, extremely overloaded term) and there are specific ways to perform actions against objects.
To add to this confusion, IBM ported DB/2 to OS/400 atop the native OS/400 data object model. You can use SQL but that just gets compiled to native operations against what are known as "physical files" (confusing name, yes) and "logical files". Physical files are fixed-length record files with data in them. Logical files are indexes atop physical files. A PC analog to this would be FoxPro, Dbase, Paradox, Alpha, etc.
Many OS/400 programs access these files using the native model; not SQL. Tandem and HP Non-Stop work in very similar ways.
So, my impression, is many applications for AS/400 are written in RPG or COBOL, languages which in their AS/400 implementations treat "files" really no differently than they do on any other platform. Or, similarly, DB2/400 stores database tables as these single-level store objects underneath, but to a programmer writing SQL queries, it doesn't really make much difference – the experience is pretty similar to writing SQL queries for DB2 for z/OS, DB2 for LUW, or DB2 for VSE/VM (and what differences do exist are more due to the divergent code bases of the different products than due to the single-level store.)
I get the impression that S/38 and OS/400 have some really interesting concepts at the core of the OS, but it is questionable how well the higher levels layered on top leverage those concepts.
"Everything is an object" would be a lot more powerful if IBM let customers/ISVs define their own object types, when as far as I am aware they don't. Yet IBM will define dozens upon dozens of object types for all kinds of obscure requirements, many of which are no longer even relevant today [1][2].
If we are going to talk about NoSQL databases as an OS, we could also talk about early implementations of MUMPS and PICK, each of which was once upon a time delivered as a standalone operating system. (It's different now; at some point each were ported to run as packages on top of more mainstream operating systems such as Unix or VMS, and more recently Linux and Windows.)
I used to work with an AS/400, and never once thought of it as a database - sure, it had DB2 pre-installed, but I don't see how that makes the OS itself a database?
I only knew it only as the source of SQL-like data dumps. And people told me that it was more than an OS with DB2 as the default database. But maybe they were wrong.
Or AS/400, which is more or less a SQL database.