71–80 of 188 posts
The important hardware in this age is the 'collection of datacentres'. Things like Kubernetes and whatever Amazon calls their thing these days are the proto 'operating systems' for this hardware. What we currently think of as Operating Systems are more like threads.
But let’s say we sit down and write a new OS: should the API for sockets be the same as for local files? Should we be able to write and read from processes by catting to and from some synthetic process file on disk? Should I be able to mount the internet on a directory and interact with sites be ls’ing their directory? Maybe I should be able to mount remote cpus and pin tasks to them? We can even take this further: registers as files, memory addresses as files, pixels and windows as files, etc etc.
All of these things sound super nice, and in many ways, they are. The everything is a file concept can be taken further than even Plan9. And fundamentally, this is what the post is arguing for. Except instead of everything is a file on a file system, everything is a table on a database.
The advantages of this approach are pretty obvious, we provide a simple and consistent interface: read/write for files, or select/insert/delete for tables. This allows a development surface that appears very simple and straightforward.
The problem is that this simplicity is an illusion and just a black box abstraction over what’s really going on. In many ways, it actually makes things more complicated as read/write become incredibly polymorphic. Maybe the API stays the same (syntax) for everything but the actual semantics still remain complex, maybe even more complicated than distinct API’s.
Even when the complexity of the semantics between the two approaches are similar, there are other problems. There’s arguments to made the heterogeneous resources should not all be provided by a homogeneous interface. For example a call to a data structure that has O(n) probably shouldn’t have the same interface as O(n^2). It makes it very easy for a developer to write incredibly inefficient code.
At its core, this dichotomy is best epitomized by Richard Gabriel’s “Worse is Better.” In the essay he talks about the difference between the New Jersey school and the MIT School. One of the differences is how the two schools think about APIs. The MIT approach is to design opaque and complete interfaces that solve the problem correctly at the expense of underlying complexity. The New Jersey or Unix approach is to value simplicity of the system at the expense of a more complicated API.
You can see an example of this in the read() system call. read() in Unix is hard to use and annoying as hell. There’s many bugs that stem from it’s misuse. The system call can (and does!) return less information that asked for even if it didn’t hit an EOF. Making read() always fill the buffer except for an EOF is a very hard problem and would have created a lot of extra complexity in the system. The MIT approach would be to implement this complexity as a simple interface is more important.
As you can probably imagine, there’s pros and cons to both approaches. Maybe the MIT way is better because many more people are going to be using read() than actually hacking on the OS. Or maybe the Unix way is better because the underlying simplicity of a system allows developers to attain a mental model of what’s going on.
If someone is interested, look at the OpenGenera source code (MIT school) vs say Plan9. OpenGenera is undoubtably a sublime and beautiful system but the code required to do it is just absurd. Plan9 is maybe less sublime, but the code itself is dead simple. Also you could compare the GNU userland vs the OpenBSD one.
tl;dr: There are costs to homogenous APIs for heterogeneous things: complexity, hard to form a mental model, easy for a programmer to misuse unintentionally. There are benefits to: consistency, beauty, easy programming.
Personally I like to take a balanced approach and decide on a case by case basis on how to trade off simplicity and correctness. Being a dogmatic programmer isn’t a good thing and it certainly doesn’t help your employers.
Just a general question: Do you think there is a market for a new operating system? The cost of building something better or equal to mainstream systems seem too high to even consider challenging the status quo.
An operating environment means you don't have to worry about stuff like device drivers. It can run inside a Docker container. (At most companies, try suggesting "let's run a brand-new OS that nobody has heard of", and you'll get an emphatic "no"... say "here's this app we want to run, it is packaged as a Docker container", and often nobody will even ask what is inside that Docker container, even if it contains your operating environment with the app running on top.)
You can start out using facilities of the host OS like the filesystem and networking stack. Later, if you want to, you can implement your own filesystem (create a 100GB file on the host filesystem, pretend that is a block device and your custom filesystem exists within it). Or your own networking stack (which can run in user space using facilities like Linux tun/tap drivers.)
An operating environment can always evolve into a standalone operating system at a later date.
Earlier quoted context omitted.
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 o…
You're describing the fact that OS apis are typed, and check state for validity. That's already the case and OS system calls already incur those costs. In a database, preparing a query compiles the access plan (ie all the above) on the server side. There's no reason it would be any less efficient than an OS call today. Could in fact be more efficient, since you would probably be able to leverage set-based operations…
'On the server side' isn't magic. You don't get server side operations for free and these 'server side' operations would be occurring on the same computer.
My dream is simple OS that works kinda like DOS: * Micro OS - Boot base from floppy drive if need be * Let me edit a text file to left put in the pieces I wants instead of a hundred pieces I don't * Includes BASIC language that build build a binary * Includes text based GUI for a text editor * Allow me to pick the drivers I want I like concept of some Linux OS'es but the ecosystem has got some huge it takes an expert…
But if you want something simple, try out the base OpenBSD install. No magic, no complexity, just simplicity and elegance.
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.
Ever heard of Oracle Database Filesystem (DBFS)?
https://docs.oracle.com/en/database/oracle/oracle-database/1...
My ultimate OS is Linux, but it's rock stable, supports all hardware and runs OSX and Windows software natively. Heh
You can already run a substential amount of Windows software natively on Linux with Wine, there is also Darling working on bringing MacOS to linux. With that being said, my ultimate distro is Linux with a Desktop Environment that is less braindead than Gnome. https://www.winehq.org/ https://www.darlinghq.org/
Oh, it's the every OS sucks story again. It's all about the user experience. System should be friend and still enable the user to increasingly get more out of the computer. It also needs to be extremely responsive. AmigaOS got a lot right back in the 80s. BeOS (and now Haiku as spiritual successor) took a lot from that (system kits vs amiga's default set of shared libraries, and the concept of datatypes) and added so…
Ignoring drivers for the moment, your typical desktop application does not have a need for a bounded response time. Desktop applications typically do not fail due to a dialog box being popped up a few milliseconds late.
The underlying drivers, on the other hand, do tend to need bounded-response time, but this is typically performed by the use of the interrupt handling subsystem, whether directly handled or split into upper/lower.
Even non-RTOSs should be able to provide real-time response to drivers in this way and the trade-offs taken by an RTOS scheduler are not always appropriate or optimal for a desktop, user-facing system.
My ultimate OS is Linux, but it's rock stable, supports all hardware and runs OSX and Windows software natively. Heh
You can already run a substential amount of Windows software natively on Linux with Wine, there is also Darling working on bringing MacOS to linux. With that being said, my ultimate distro is Linux with a Desktop Environment that is less braindead than Gnome. https://www.winehq.org/ https://www.darlinghq.org/
Nah man, sadly most of the really useful software is quite unstable under wine, if it even runs :(