[drpixie]

It is - until you want to do something interesting, then it's all ioctl(), recv(), and the various gather calls!

I'd like to see an OS that drops the concept of files. Files are very low level (generally a stream of bytes) - the app has to interpret it as config, or data, etc "manually". An OS should be providing higher-level data management, and insisting that is what is used.

(And please not SQL. It's only a little higher level that raw data, and has serious interface problems that permit prompt injection ... the db equivalent of buffer overflows.)

[sillywalk]

The IBM System/38 and its descendants (AS/400 which was renamed to iSeries, then i5, now just the horribly unsearchable IBM i) sort of did/does this, except 'newer things' ported over like modern web stuff generally use the Unix portability layer, so it's not enforced. Also, it has a SQL database built-in at the OS level..

The original/legacy OS is quite interesting and high level. It's Object Based. You can only use the objects built-in methods e.g. you can't WRITE arbitrary bytes to an Application object, or a User Object. They are accessed as a giant Single address space, and whether they are on disk or in RAM is transparent to higher layers, i.e. if an object isn't in ram it will page it in..

The designer of System/38 etc. Frank Soltis wrote a couple of interesting books on it - Inside The AS/400 and its 2nd edition Fortress Rochester: Inside the iSeries. They're out of print and expensive unfortunately, I wish I hadn't gave my copy away.

[pjmlp]

IBM Redbooks are an alternative source of information for that.

[mjl-]

> It is - until you want to do something interesting, then it's all ioctl(), recv(), and the various gather calls!

Indeed, Plan9 and inferno don't have ioctls. For special operations ("control"), there is often a file named "ctl" to which you can write commands. So you open the file, write some text, see if the write succeeds, and close the file. E.g. to make a tcp connection, to flush a write buffer to disk, etc. The commands are typically just plain ascii. That's easy for scripting and there is no need to import C struct types into that new programming language you are using/developing. Of course, the commands have to be parsed (for kernel devices, this happens in the kernel), typically done with some simple tokenization functions. When the commands become complicated, you could still choose to write binary data, or even straight C structs...

[MobiusHorizons]

The purpose of a good primitive is that it can be cleanly composed. Both files and streams of bytes have these properties, because the primitive allows code written by different people / teams / orgs to interact due to the common primitives. The higher level your primitives, the larger your api surface, and the less likely they are to be composable. Do you really want that? I certainly don’t.

[Technotroll]

> An OS should be providing higher-level data management, and insisting that is what is used.

This assertion seems normative. Could you please expand upon how higher-level data management improve the overall performance and efficiency of the system? Or could you point me in the direction of some good sources? Also what are the benefits of an OS providing higher-level data management instead of relying on lower-level data management solutions? Doesn't abstraction lead to less fine control? That is to say, how does insisting on using higher-level data management provided by an OS affect the development and maintenance of applications? I've seen some object-centric systems adopt this approach and find it very interesting.

[sparkie]

I think the OS should begin with a lower level abstraction - object capabilities, and build out from there.

Rather than a loss of control, capabilities enable fine-grained control over authorization, because a capability is both designates a resource and provides authority to use it.

But pathnames are not useful as capabilities, because they can be easily forged. So at best a pathname could serve to discover resources for which you could then request a capability to access.

[ElectricalUnion]

Isn't Windows built this way?

Everything in Windows is an object, on a centralized resource broker Ob.

Windows uses capabilities based access to enable fine-grained control. It is EAL4 - Methodically Designed, Tested and Reviewed.

This by itself doesn't prevent Windows from having security issues.

[sparkie]

Windows does not have the kind of capabilities I'm referring to.

With proper capabilities, the capability itself provides the authority. There's no need to have separate access control lists or some kind of central resource broker. Each process manages its own capabilities, can create new capabilities and can delegate them to others. And importantly, capabilities can always be revoked, at any time.

See: http://www.erights.org/elib/capability/overview.html, https://en.wikipedia.org/wiki/Capability-based_security

Also see seL4 for an example of this done right.

[drpixie]

You seem to be answering your own questions :)

Of course, "abstraction lead[s] to less fine control" - at the the lowest (assembly) level, you can do almost anything - and make all the mistakes imaginable. Sometimes you want to genuinely maximise performance, or do things otherwise difficult - fine, use assembly and hit the hardware. But most of the time, software is made to be read, to be trouble free, to build on other's work, and to be written easily - that's when abstraction is valuable.