5 ms·

> 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 recor

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

tasogare 7y ago
Or Windows with the registry. Wait...
- atoav 7y ago
  But is ”uses a database” really the same thing as “based on a database for everything” as outlined in the article’s vision?
- userbinator 7y ago
  The registry is basically a hierarchical filesystem with some tiny size limits.
skissane 7y ago
> 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.
- mirimir 7y ago
  People who used it characterized it that way.
  - skissane 7y ago
    I know they did/do. But when they characterise it that way, are they just repeating IBM marketing assertions without challenging them?
    - mirimir 7y ago
      That's a good point. And as you say, it's hard to know with closed-source stuff.
  - GordonS 7y ago
    I used it, and never characterised it that way - I simply saw it as an OS with DB2 installed!
- tyingq 7y ago
  TPF might be a better example. It's pretty much a distributed nosql database delivered as an OS.
  - skissane 7y ago
    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.)
- nybblesio 7y ago
  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. [1] https://en.wikipedia.org/wiki/Single-level_store https://en.wikipedia.org/wiki/Single-level_store
GordonS 7y ago
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?
- mirimir 7y ago
  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.
zvrba 7y ago
> If a database engine is implemented as a core system service, along with simple tools Windows has it, though user-level tools are lacking. https://docs.microsoft.com/en-us/windows/win32/extensible-storage-engine/extensible-storage-engine https://docs.microsoft.com/en-us/windows/win32/extensible-st...
Animats 7y ago
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.
- cmrdporcupine 7y ago
  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.
  - kjs3 7y ago
    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.
Animats 7y ago
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.
- deleted 7y ago
  [deleted]
adrianmonk 7y ago
Or the Object Data Manager (ODM) on IBM AIX. https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/generalprogramming/odm.html https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/ge...

tasogare 7y ago

Or Windows with the registry. Wait...

atoav 7y ago
But is ”uses a database” really the same thing as “based on a database for everything” as outlined in the article’s vision?
userbinator 7y ago
The registry is basically a hierarchical filesystem with some tiny size limits.

skissane 7y ago

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

mirimir 7y ago
People who used it characterized it that way.
- skissane 7y ago
  I know they did/do. But when they characterise it that way, are they just repeating IBM marketing assertions without challenging them?
  - mirimir 7y ago
    That's a good point. And as you say, it's hard to know with closed-source stuff.
- GordonS 7y ago
  I used it, and never characterised it that way - I simply saw it as an OS with DB2 installed!
tyingq 7y ago
TPF might be a better example. It's pretty much a distributed nosql database delivered as an OS.
- skissane 7y ago
  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.)
nybblesio 7y ago
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. [1] https://en.wikipedia.org/wiki/Single-level_store https://en.wikipedia.org/wiki/Single-level_store

GordonS 7y ago

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?

mirimir 7y ago
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.

zvrba 7y ago

> If a database engine is implemented as a core system service, along with simple tools Windows has it, though user-level tools are lacking. https://docs.microsoft.com/en-us/windows/win32/extensible-storage-engine/extensible-storage-engine https://docs.microsoft.com/en-us/windows/win32/extensible-st...

Animats 7y ago

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.

cmrdporcupine 7y ago
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.
- kjs3 7y ago
  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.

Animats 7y ago

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.

deleted 7y ago
[deleted]

adrianmonk 7y ago

Or the Object Data Manager (ODM) on IBM AIX. https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/generalprogramming/odm.html https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/ge...