Hacker News Reader

Comment by lisper | Hacker News Reader

This is cool, but I think it's misleading to call it an operating system. It's Tetris that runs without an operating system, which is to say, on bare metal, old school. Writing programs that run on bare metal is a cool and worthwhile thing to do, but calling any such program an "operating system" is confusing.

This probably sounds like I'm picking a nit, but I think it matters for the sake of newbies just starting to climb the learning curve and trying to understand what an "operating system" actually is. IMHO, the defining characteristic of an operating system is that it provides an environment in which to run other programs, ones that are not part of the operating system, and which may not even exist at the time that the operating system starts to run.

View on HN

Alternatively, it's Tetris with bits of a minimal OS mixed in, just enough to support it, which is not unlike what a lot of OSs in embedded systems are like.

A lot of software was written in this format several decades ago, including many games:

https://en.wikipedia.org/wiki/Self-booting_disk

https://en.wikipedia.org/wiki/List_of_PC_booter_games

I think the boundaries are quite fuzzy; while something like the mask-ROM firmware in a 4-function calculator or microwave would probably not be called an OS by the majority of people, how about a router running Linux, or the RTOS used in a car's ECU? Moving up from there, DOS is clearly in the realm of an actual OS, then we have the locked-down mobile devices, and at the far end are the general-purpose PCs running Windows, Linux, macOS, and such.

Even at the "small end", a microcontroller running a firmware containing a single infinite loop that does stuff with the peripherals seems unlikely to classify as an OS; but what if you start adding dynamic memory allocation, coroutines/cooperative multithreads, filesystem code, etc.?

It's a Tetris unikernel

Yes, props to the developer for what they've done, but I am perversely disappointed that this isn't actually a complete OS - process scheduler, file system, TCP/IP stack, multiple user support, all the rest - that only runs Tetris.

I used a few operating systems that were considered "complete," in their time, without a TCP/IP stack or multiple user support. Come to think of it, I don't think they had process schedulers either

Well, if you are into exokernels, they wouldn't have a TCP/IP stack either.

(You'd have them in userland. Whether you count that as part of the OS or not, is a different question.)

The software in your washing machine begs to differ.

I don't think it is essential that there be a clear boundary between an OS and programs.

For example, you can have a Smalltalk-based OS, written in Smalltalk. The OS components are simply Smalltalk classes and methods. Your programs/utilities/applications would also be Smalltalk classes and methods. There needn't be any clear boundary between the classes/methods that belong to the OS and those that belong to programs/applications/utilities.

If you look at library operating systems, the operating system is just a library which you link into your application. Such an operating system can only run one program, and you have to rebuild the operating system whenever you want to change the single program it runs. Still, I think library operating systems count as operating systems. This Tetris implementation isn't using a library operating system, but you could refactor the code into two parts – the Tetris game, and generic OS services, and the later would constitute a library operating system. If you look at its source files, only about seven of them (main.c, music.[ch], sound.[ch], speaker.[ch]) actually implement the game. The other 23 source files are generic OS services. So I'd say that, even if this isn't an operating system as a whole, it contains an OS within itself.

I like to define an OS as something that can execute arbitrary binaries. So if your hypothetical Smalltalk OS has a defined executable format that non-Smalltalk programs can compile to, I’d call it an OS.

Note that this also makes for example the uppermost part of the JVM an OS by my definition. I’d argue it’s not a completely incorrect characterization.

I think that definition is a bit too broad and too narrow to be useful.

For too narrow: you might have a security focused OS that includes everything like a TCP/IP stack etc, but perhaps doesn't allow arbitrary binaries by construction. (Eg it might only allow binaries that come with a proof of innocence, or some other restriction that's harsh enough to lose the 'arbitrary' rating.)

For too broad: https://en.wikipedia.org/wiki/Weird_machine would make almost any software that was written sloppily enough into an OS.

Obviously, "capable of running arbitrary binaries, but with a check inside exec() to allow only specific binaries run" counts as "capable of running arbitrary binaries".

Yes, perhaps a more specific example would be better.

Imagine some embedded application, eg in car, that has a network stack, graphics drivers etc, but can only run built-in functionality.

You've presented a conscientious criterion for what can be classified as an operating system. I think it's clever, I'm not sure I agree though. It's very broad: By this same definition any processor is an operating system, since it will execute arbitrary binary data. Your example of the JVM being an operating system calls to mind the above: It is a virtual machine, it is designed to execute arbitrary bytecode in a similar manner to a processor.

You may have found a loophole in my specification :) I’d like to amend it to specify that an OS refers to software “that can run...”. (And this is why we do design reviews!).

In your example, a real or virtual machine’s load/setregs interface is an operating system. One that can only run a single program at a time in the case of the physical processor’s bootstrap, but you’d be surprised how similar that is to early DOS.

A more hand-waving version is “the lowest level interface over the machine that can run...”. So a processor and a ROM grid can run arbitrary programs, but the lowest common denominator entry point is the ROM flashing spec! A very slow scheduler indeed.

What do you mean by "arbitrary binary"? Surely, you don't mean that absolutely any binary blob should be a meaningful executable. Because that would mean that my computer doesn't have an operating system because it's only capable of running binaries built for Ubuntu on amd64 -- if your binaries targeting BSD on ARM can be viewed as "arbitrary," then surely they shouldn't be expected to run on my pseudo-operating system.

No, every operating system that I know of makes some assumptions about the language that programs are written in. On my amd64/Ubuntu system, the language is largely specified by the processor (and, yes, has a binary format) and the programs are allowed to assume the presence of various devices, formats of various system calls, etc. Other languages are supported through a complicated system of compilers, interpreters and assemblers.

Or, coming at a different tack: does the existence of a C->Smalltalk transpiler turn the Smalltalk-based pseudo-OS into a real OS? What if the pseudo-OS doesn't ship the transpiler, and you need to run that yourself in user-space?

I don't agree that something has to be capable of running "arbitrary binaries" to count as an operating system. If I have a Smalltalk-based OS which is capable of running arbitrary Smalltalk code, but doesn't have any support for running non-Smalltalk binaries (native code or programs written in languages other than Smalltalk), I'd still consider it to be an operating system.

The “arbitrary” part is a force of how rather than what programs are run. Is your Smalltalk code running by compiling it into the OS? Is it loaded as a library? Can I write a C backend to output an indistinguishable library? In the latter cases, it is still capable of running arbitrary code - you may just be choosing not to.

You can still write code in a different language like C that will compile into Smalltalk VM bytecode. You will never be able to run any arbitrary code, just the one compiled for your machine. And in this case, the machine is virtual (but does not need to be). Symbolics Lisp machines were able to run Pascal as well, for example.

I somewhat agree with the sentiment, but I think the line is fuzzy. UNIX, as the stories go, originated as essentially an abstraction layer for a single video game, all written in assembly, and eventually expanded to have process isolation and a shell. So I'm inclined to think that this could be an OS, as it has to provide subroutines and code to drive hardware and provide an environment for the game to run, an "operating system" if you will.

But if you accept that, everything becomes fuzzy. Is the firmware an "operating system" then? The CPU microcode? On systems like the XEROX Alto, the microcode was developed like a sort of OS kernel. I think it's interesting to explore the "lesser meanings" of terms like "operating system" :-)

IDK. Plenty of "operating systems" are linked as a single binary with the application, in the embedded world and historically. This takes it a bit further but I doubt you think the dividing line is "OS and application are maintained as a separate project" which is about the only distinction.

I do see where you're coming from, though. Personally I would've described it as "bootable Tetris".

Even in embedded systems, there's still usually a distinct boundary between the OS kernel and the "application", and a well-defined API between the two.

Compare https://en.wikipedia.org/wiki/Unikernel

There's an OS alright, it's just not a -general purpose- OS but a very small, statically embedded, specialised one.

It's no more misleading than saying it runs on bare metal. If I flash the correct motherboard ROM chip with the necessary bits to play Tetris in the UEFI (or completely replace it), would I be running closer or farther from "bare metal" than this is? Am I still on bare metal if I choose to use GRUB for loading up the game? Do I become an OS if I use GRUB instead of embedding that logic within my binary?

We call things BIOS and Boot-loader and Operating System by virtue of history, not necessity. It could even be confusing to a newcomer looking into development closer to the hardware and being told that all these programs are fundamentally different, instead of just being instructions and data getting shoved through a bunch of tubes in the processor and PCB.

That might be what OS'es currently _are_, but I disagree that it is what an OS _is_. I think fundamentally an OS is as the OP uses it, a set of code that interfaces with all your hardware to make the computer function.

Heres a good talk I came across in a HN comment a little while back [1] about how games used to be developed vs how they are today.

[1] - https://www.youtube.com/watch?v=kZRE7HIO3vk

It's not even running on bare metal.

I agree, but "operating system" is very poorly defined. Name a feature of an operating system and you can find one that doesn't support it. Just about the only definition that seems to hold is that it runs without an operating system.

That's a catchy hook but terribly misleading!

So if you could write programs with the tetris blocks, it'd be an OS? Sign me up!

You mean Minecraft?

If Apple and Google can release operating systems that can only run software which has been built for those platforms, approved by Apple/Google, and released through official delivery channels, this could be an operating system too, which only allows you to run program which have been pre-approved, possibly only to deliver blocks. Perhaps the keys are shortcuts to launch additional programs which change the wallpaper in various ways.

Reply on news.ycombinator.com