Hacker News Reader

Comment by uticus | Hacker News Reader

> "Together with his invention of the BIOS (Basic Input Output System), Kildall's operating system allowed a microprocessor-based computer to communicate with a disk drive storage unit and provided an important foundation for the personal computer revolution." (IEEE milestone plaque cited in article)

The whole idea of an OS as an important thing is debatable. For example:

> The operating system is another concept that is curious. Operating systems are dauntingly complex and totally unnecessary. It’s a brilliant thing that Bill Gates has done in selling the world on the notion of operating systems. It’s probably the greatest con game the world has ever seen.

> An operating system does absolutely nothing for you. As long as you had something—a subroutine called disk driver, a subroutine called some kind of communication support, in the modern world, it doesn’t do anything else.

(Chuck Moore, interview in "Masterminds of Programming", 2009)

View on HN

Chuck Moore's alternative to the modern OS is Color Forth. The man is brilliant and he is also a crank in the way brilliant people can sometimes be. When he says "you" he's really referring to programmers (and he's still wrong about that). I don't think the category of "non-programmers who use computers" is a significant part of his analysis.

This works great as long as you have exactly one program running on your computer and fully trust its developers to not mess up your hardware or lose your data.

I think this is the biggest argument for an OS. The OS is a virtual Nanny or representative of yourself. It does what you would do if you could control the machine: provide security for data, keep code from running through fences, and ensure multiple simultaneous routines don't block each other.

If you're that concerned about it, go grab a raspberry pi and get cracking on your own compute environment. You don't actually need all the OS stuff as you keep arguing, so go make it so.

Of course you're ignoring the fact that linux is open source, so you can go make the OS do what you want it to - that's one path you could take.

Or you could just write code for the rpi and build up all that stuff yourself, no problem.

The only person stopping you from doing this is yourself.... go do it and show us the "no-os" way.

I think you read my previous comment as an argument against what I was replying to. I was actually agreeing with them and acknowledging they have a great point.

I did misread, thanks for the clarification.

This sort of protection is not a requirement for an operation system though. For instance AmigaOS had full pre-emptive multitasking, device drivers, a windowing UI, a filesystem and all sorts of user-facing features expected of a modern operating system.

But it had no memory protection, no "kernel mode" or filesystem access rights, the hardware was fully documented and accessible to all code running on the machine.

Each program could easily take over the entire machine and do literally anything (including destroying all your data).

Multi-user capability and the idea that a user only has limited access to the computer was really a mainframe thing that leaked into personal computing during the 90s.

I seem to recall someone, perhaps Alan Kay (or another person familiar with Smalltalk, Lisp, etc.), saying something like "operating systems are only necessary when your programming language/environment is deficient; ideally you shouldn't have one."

I'm unsurprised that Moore, who invented his own complete-machine programming environment, would concur.

"An operating system is a collection of things that don't fit into a language. There shouldn't be one." -- Dan Ingalls

Yes! The brilliant Dan Ingalls - an inspiration to us all. Thanks for finding the exact quote.

I think he also said something like "I never really wanted to program in a language/environment that wasn't (as good as?) Smalltalk." So he (and his colleague(s)) ported Smalltalk into web browsers, used it for system programming, etc.

Which brings me to this web site, curated by the man himself:

https://smalltalkzoo.thechm.org

Interesting. Remember when, in order to run a DOS application, you had to edit a config file to tell it which graphics card, sound card, serial port, and printer you had? Also, tweak the jumper on the hardware to select which IRQ they used to avoid conflicts?

That was because your application booted the OS out and ran on naked hardware. It was as simple as IRQ 1-2-3, plus Hercules, SoundBlaster, ExpressCard and extended or expanded RAM. And maybe typing ATDT to get the modem's attention.

I think you're confusing what an OS provides with the concept of configuration maintenance, esp "plug and play." Or to make my point more clearly, all the configuration you listed still must be done for an OS by something outside the OS - ie the bootloader (GRUB, etc) or device manager or the like. An OS doesn't magically make configuration for different hardware unnecessary; indeed it doesn't even handle such configuration.

> ... and ran on naked hardware.

Not quite, drivers are still involved. An OS may load drivers, expose a facade for drivers, or even abstract whole layers of driver subroutines. But it isn't like it's a choice of either OS or bitbang the hardware.

DOS had nothing to do with graphics and sound. All that was at the application level. DOS provided the command line (your shell), the filesystem, and a few basic abstractions. Generally speaking applications didn't boot the OS out since they still used it to access files etc.

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.

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.

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

[1] https://dfarq.homeip.net/commodore-64-operating-system/

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.

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.

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.

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

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

Reply on news.ycombinator.com