4 ms·

That sounds like nonsense. The idea that a stable API provides no value is contrary to all the evidence. Look at graphics APIs like DirectX and look at what ha

That sounds like nonsense. The idea that a stable API provides no value is contrary to all the evidence. Look at graphics APIs like DirectX and look at what happened when jQuery was released for more evidence that having a stable API that covers disparate collections of hardware (or browser) APIs, provides vast amount of value. The idea that an operating system providing a stable API over different computers is something that doesn't provide value is hogwash.

AnimalMuppet 3y ago
It's more than just a stable API across different computers, though that's a huge deal. It's also code that I don't have to write. I don't have to write the disk drivers. I don't have to write the keyboard driver. I don't have to write the mouse driver. I don't have to write the screen driver. I can build what I'm trying to build on top of that, without worrying about all of that detail.
- uticus 3y ago
  Not disagreeing (completely) with you, but worth pointing out the very next question in the interview I quoted above looks like this: > What about device support? > Chuck: You have a subroutine for each device. That’s a library, not an operating system. Call the ones you need or load the ones you need. ...for sure it's a departure from the common way of doing things, at least. And it's almost impossible to imagine, today's generation would have to look at retro-computing to see something akin to the idea [0] [1]. [0] https://en.wikipedia.org/wiki/Commodore_64#BASIC https://en.wikipedia.org/wiki/Commodore_64#BASIC [1] https://dfarq.homeip.net/commodore-64-operating-system/ https://dfarq.homeip.net/commodore-64-operating-system/
  - AnimalMuppet 3y ago
    No, I can imagine it. I worked on an embedded device that I think worked this way (vxWorks), though I didn't get into the device driver side of things very much. But it's still a bad approach for general computers, for two reasons. 1. With the current setup, we need an OS that detects the hardware and loads the right code. With Chuck's proposal, that responsibility - and the code to do it - moves to every application. Since there are far more applications than OSes, this is highly inefficient. 2. Let's say I buy an application, and then some time later I buy a new computer. If the new computer has a compatible OS, I can just run the existing program on the new computer. But under Chuck's approach, I need a new version of the program as well - one that knows how to detect the new hardware, and what drivers to load in response. So (virtually) nobody is going to do it that way. It might have made sense when you were fighting for every byte of memory, but that isn't the world we live in any more, and it hasn't been for decades.
  - skydhash 3y ago
    I think the linux kernel is close to that. And if you go with a minimal distro like alpine, then you're not that far away from what is described. Compare it to MacOS where just launching a program is a whole shenanigan. I have a small digital audio player running linux and the interface is a single program. I like OS for their flexibility, but when I look at my computing needs (as a user), I'd be fine with just a small list of software. Anything else is nice, but not "essential". I think that's why iPad has been successful, it's the graphic DOS. You launch an app and for all purposes, it may be the only one running on the hardware.
toast0 3y ago
An operating system provides those things, but it's not the only way they could be provided. Disk drivers could be provided by BIOS/UEFI (and they are) or through some library, or through standard hardware interfaces (AHCI and similar). Same deal for graphics. Does that need to be bundled with a kernel and a bunch of other stuff? Not strictly. All that other stuff is valuable too, most of the time. Otoh, if you're using the whole computer for one thing, the OS can get in the way, and often isn't providing much you couldn't get as libraries.
- babypuncher 3y ago
  > Disk drivers could be provided by BIOS/UEFI They can, but I don't want direct access to a disk driver. I don't want to care about the hardware, or even what file system is in use. I want to write a log file to this folder on this disk. Once the BIOS/UEFI starts providing that level of abstraction, how is it different than an operating system? Having an operating system means there is a lot less code I have to write, because all the nitty gritty details of networking, talking to hardware, and all that other stuff is already taken care of for me. Someone else already invented the wheel so I don't have to.
uticus 3y ago
> The idea that a stable API provides no value is contrary to all the evidence. ...agreed > Look at graphics APIs like DirectX and look at what happened when jQuery was released for more evidence that having a stable API...provides vast amount of value. I wonder if more correct to say the concept of virtual machine provides a vast amount of value - like Java saying "run everywhere." But your examples (DirectX, jQuery) could also prove a different point: high levels of abstraction layers lead to maintenance and efficiency nightmares. For example, jQuery sits on JavaScript, sits on browser's engine, sits on OS, sits on microcode. A jQuery-focused dev would still spend a significant amount of time setting up, debugging, accommodating, and troubleshooting things on all the other layers compared to just getting things done in their (somewhat) stable jQuery ABI. The layers are helpful sometimes, and hurtful sometimes, and the net gain is not always as great as expected.

AnimalMuppet 3y ago

It's more than just a stable API across different computers, though that's a huge deal. It's also code that I don't have to write. I don't have to write the disk drivers. I don't have to write the keyboard driver. I don't have to write the mouse driver. I don't have to write the screen driver. I can build what I'm trying to build on top of that, without worrying about all of that detail.

uticus 3y ago
Not disagreeing (completely) with you, but worth pointing out the very next question in the interview I quoted above looks like this: > What about device support? > Chuck: You have a subroutine for each device. That’s a library, not an operating system. Call the ones you need or load the ones you need. ...for sure it's a departure from the common way of doing things, at least. And it's almost impossible to imagine, today's generation would have to look at retro-computing to see something akin to the idea [0] [1]. [0] https://en.wikipedia.org/wiki/Commodore_64#BASIC https://en.wikipedia.org/wiki/Commodore_64#BASIC [1] https://dfarq.homeip.net/commodore-64-operating-system/ https://dfarq.homeip.net/commodore-64-operating-system/
- AnimalMuppet 3y ago
  No, I can imagine it. I worked on an embedded device that I think worked this way (vxWorks), though I didn't get into the device driver side of things very much. But it's still a bad approach for general computers, for two reasons. 1. With the current setup, we need an OS that detects the hardware and loads the right code. With Chuck's proposal, that responsibility - and the code to do it - moves to every application. Since there are far more applications than OSes, this is highly inefficient. 2. Let's say I buy an application, and then some time later I buy a new computer. If the new computer has a compatible OS, I can just run the existing program on the new computer. But under Chuck's approach, I need a new version of the program as well - one that knows how to detect the new hardware, and what drivers to load in response. So (virtually) nobody is going to do it that way. It might have made sense when you were fighting for every byte of memory, but that isn't the world we live in any more, and it hasn't been for decades.
- skydhash 3y ago
  I think the linux kernel is close to that. And if you go with a minimal distro like alpine, then you're not that far away from what is described. Compare it to MacOS where just launching a program is a whole shenanigan. I have a small digital audio player running linux and the interface is a single program. I like OS for their flexibility, but when I look at my computing needs (as a user), I'd be fine with just a small list of software. Anything else is nice, but not "essential". I think that's why iPad has been successful, it's the graphic DOS. You launch an app and for all purposes, it may be the only one running on the hardware.

toast0 3y ago

An operating system provides those things, but it's not the only way they could be provided. Disk drivers could be provided by BIOS/UEFI (and they are) or through some library, or through standard hardware interfaces (AHCI and similar). Same deal for graphics. Does that need to be bundled with a kernel and a bunch of other stuff? Not strictly. All that other stuff is valuable too, most of the time. Otoh, if you're using the whole computer for one thing, the OS can get in the way, and often isn't providing much you couldn't get as libraries.

babypuncher 3y ago
> Disk drivers could be provided by BIOS/UEFI They can, but I don't want direct access to a disk driver. I don't want to care about the hardware, or even what file system is in use. I want to write a log file to this folder on this disk. Once the BIOS/UEFI starts providing that level of abstraction, how is it different than an operating system? Having an operating system means there is a lot less code I have to write, because all the nitty gritty details of networking, talking to hardware, and all that other stuff is already taken care of for me. Someone else already invented the wheel so I don't have to.

uticus 3y ago

> The idea that a stable API provides no value is contrary to all the evidence. ...agreed > Look at graphics APIs like DirectX and look at what happened when jQuery was released for more evidence that having a stable API...provides vast amount of value. I wonder if more correct to say the concept of virtual machine provides a vast amount of value - like Java saying "run everywhere." But your examples (DirectX, jQuery) could also prove a different point: high levels of abstraction layers lead to maintenance and efficiency nightmares. For example, jQuery sits on JavaScript, sits on browser's engine, sits on OS, sits on microcode. A jQuery-focused dev would still spend a significant amount of time setting up, debugging, accommodating, and troubleshooting things on all the other layers compared to just getting things done in their (somewhat) stable jQuery ABI. The layers are helpful sometimes, and hurtful sometimes, and the net gain is not always as great as expected.