The operating system: should there be one? (2013) [pdf] • Hacker News Board

Re: The operating system: should there be one? (2013) [pdf]

#171

Post by PaulDavisThe1st » Tue, Sep 07, 2021, 11:16 PM UTC

AussieWog93 wrote: post #83

lavabiopsy wrote: post #70

Earlier quoted context omitted.

This affects all GUIs, if you have a lot of elements then you have to be careful not to propagate complex updates through the whole tree because it kills your performance. There are various tools to deal with this, one of them is making it retained mode, but I would say basically all of those tools come with more footguns in that the GUI can easily end up in an inconsistent state. That's what you trade for performanc…

I've heard that argument before, yet for almost all apps I've used in real life the opposite is true. Game UIs are (from what I understand) written almost exclusively ImGui-style, with every single widget being fed updated state data every single frame as part of the game loop. Yet, for whatever reason, even crazy-complex UIs like SupCom's seem to have no issue rendering in realtime with an entire 3D game running in…

Game UIs do not generally involve user interaction based on the position of a pointer within the 2D screen geometry. They generally have a very limited event/input system that only takes effect via an overlay. Objects do not come and go from the "model" as a matter of course. They certainly do a LOT of drawing, and they do it very fast, but the challenges of UI design (particularly toolkit design) don't really reside in "how do we draw this stuff really fast".

I do often reflect on how fast game UIs draw, and compare that to the headaches we have in the UI of a digital audio workstation. It generally seems almost inconceivable how we could be so slow in comparison. But then I think about all the ways the user has to interact with the actual UI (not the backend data model), and it starts to seem like a different sort of programming model entirely.

Re: The operating system: should there be one? (2013) [pdf]

#172

Post by PaulDavisThe1st » Tue, Sep 07, 2021, 11:18 PM UTC

bsdubernerd wrote: post #157

account42 wrote: post #96

Earlier quoted context omitted.

> Consider audio instead. OSS always provided pretty much all the hardware features, but allow no resource sharing. Every single evolution on that front has been an increase in complexity to allow for resource sharing. None of the API changes were required for resource sharing though so that complexity could (and should) have been contained to the implementation and those applications that actually need new features.

Which is actually the case. In fact, audio is the best examples where everything can plug into almost everything. padsp (if I'm not mistaken - not at the prompt right now) does just that.

That's completely incorrect. PulseAudio provides no inter-application audio routing at all (neither did OSS and neither does ALSA).

Re: The operating system: should there be one? (2013) [pdf]

#173

Post by PaulDavisThe1st » Tue, Sep 07, 2021, 11:27 PM UTC

bsdubernerd wrote: post #80

overgard wrote: post #9

I can't help but think about what happened with graphics APIs - the older ones (DX9, OpenGL) held your hand more, and the new ones are super bare metal and not written for the faint of heart. I think most would agree this is better though; for an application developer you can simply use a much higher level library built on top, and for the library/engine developer you have a lot more power and control. The old APIs w…

The OS is all about resource sharing and allow a minimum common level of interoperability. Smalltalk can provide a storage abstraction, but to interoperate with other things it needs to be able to save data in a way that can be loaded back into your Java program. OSes can provide you with the desired abstraction level. You could stop at the block layer, which many DBs can take advantage of, but that won't help your J…

> Consider audio instead. OSS always provided pretty much all the hardware features, but allow no resource sharing. Every single evolution on that front has been an increase in complexity to allow for resource sharing.

This is not true. Early evolution of ALSA included lots of work on handling high channel count, memory-mapped devices (and their opposite, a few devices around in about 2000 that require active CPU involvement in data transfer). At some point, more evolution was required to deal with asynchronous interfaces like the USB ones that are now ubiquitous. The Intel HDA "specification" created a huge amount of work to model the topologically indistinct hardware mixers that it allowed. It remains the case that ALSA provides no facilities for resource sharing that are used by more than a handful of obstinate folk, so there has been essentially no evolution within ALSA itself toward that goal (see next para).

> And it's interesting because the effort went in and out of the kernel a couple of times.

Once OSS was dropped, the only resource sharing left on the kernel side in ALSA was the dmix layer. That continues to exist today, but has never worked reliably, which is part of the reason why PulseAudio came into existence.

> Describing the evolution of OSS/ALSA in linux/freebsd would be too long, however we now have very fat daemons sitting in front of the HW just for resource sharing.

I object to JACK being called "a very fat daemon". It's lean and mean and fairly clean (even the version I didn't write). Perhaps you mean PulseAudio, but that does much, much more than just "resource sharing".

As a side-note, Apple did move resource sharing out of the kernel. At some point that was all kernel-side, and at some point, coreaudiod showed up as a user-space daemon that was eventually clearly doing the same thing.

Re: The operating system: should there be one? (2013) [pdf]

#174

Post by PaulDavisThe1st » Tue, Sep 07, 2021, 11:30 PM UTC

AussieWog93 wrote: post #73

jcelerier wrote: post #48

Earlier quoted context omitted.

If you think that Qt is more bloated than Cocoa I don't know what to say. That objc runtime is so heavy and slow, good luck making it run on microcontrollers

I don't understand the technical reasons behind it, but for whatever reason doing something like resizing a Window for any non-trivial GUI seems to cause the repaints to drop down to 15-20Hz in Qt and spike the CPU usage massively. The same issue doesn't occur with Win32 or Cocoa.

I do understand the technical reasons behind it, and it has nothing to do with bloat. It mostly has to do with mapping a cross-platform (i.e. generic) window abstraction onto a specific OS-provided drawing/event/windowing API.

Re: The operating system: should there be one? (2013) [pdf]

#175

Post by PaulDavisThe1st » Tue, Sep 07, 2021, 11:39 PM UTC

AnIdiotOnTheNet wrote: post #122

wsc981 wrote: post #79

Earlier quoted context omitted.

But humans generally like to organise things hierarchically and I would think database are not well suited for this purpose. That is, unless there exists some kind of tree structured database that I don't know about ... Many years ago Microsoft tried to implement some kind of database oriented file system (it was a big dream of Bill Gates IIRC and probably meant for Longhorn), but this project never became part of an…

> That is, unless there exists some kind of tree structured database that I don't know about ... Believe it or not, hierarchical databases were actually quite popular once upon a time, mostly in IBM mainframe land as I understand it. Today the Windows registry is a hierarchical database in common use.

Rather more common that the Windows registry: any kind of filesystem.

Re: The operating system: should there be one? (2013) [pdf]

#176

Post by AussieWog93 » Wed, Sep 08, 2021, 12:19 AM UTC

PaulDavisThe1st wrote: post #174

AussieWog93 wrote: post #73

Earlier quoted context omitted.

I don't understand the technical reasons behind it, but for whatever reason doing something like resizing a Window for any non-trivial GUI seems to cause the repaints to drop down to 15-20Hz in Qt and spike the CPU usage massively. The same issue doesn't occur with Win32 or Cocoa.

I do understand the technical reasons behind it, and it has nothing to do with bloat. It mostly has to do with mapping a cross-platform (i.e. generic) window abstraction onto a specific OS-provided drawing/event/windowing API.

I built my own cross-platform windowing/event API from scratch at my last job, based on top of win32 on Windows, Cocoa on Mac and Qt on Linux. The only platform where there was any noticeable performance drops at all was Linux, because it relied on Qt.

When I said "I don't understand the technical reasons behind it", I didn't mean "I don't understand how to abstract OS-native APIs". I meant "I don't understand how a team of intelligent people managed to fuck things up this badly".

Re: The operating system: should there be one? (2013) [pdf]

#177

Post by [deleted] » Wed, Sep 08, 2021, 12:48 AM UTC

AussieWog93 wrote: post #176

PaulDavisThe1st wrote: post #174

Earlier quoted context omitted.

I do understand the technical reasons behind it, and it has nothing to do with bloat. It mostly has to do with mapping a cross-platform (i.e. generic) window abstraction onto a specific OS-provided drawing/event/windowing API.

I built my own cross-platform windowing/event API from scratch at my last job, based on top of win32 on Windows, Cocoa on Mac and Qt on Linux. The only platform where there was any noticeable performance drops at all was Linux, because it relied on Qt. When I said "I don't understand the technical reasons behind it", I didn't mean "I don't understand how to abstract OS-native APIs". I meant "I don't understand how a…

[deleted]

Re: The operating system: should there be one? (2013) [pdf]

#178

Post by mikewarot » Wed, Sep 08, 2021, 12:50 AM UTC

PaulHoule wrote: post #125

IBM never had a plan for a mainframe operating system that made sense -- given the idea that the "360" was supposed to encompass the whole circle of applications. What happened was some academics figured out it was possible to make virtual machines on the 370 and that you could run a few different operating systems at the same time. If you were doing software dev on the 370, for instance, you would start up a VM runn…

The reason it worked out was that each virtual machine was given a set of capabilities, and the hypervisor restricted access for that machine to only those resources.

Eventually, this lesson will spread. I think about 5 more years of chaos until people finally catch on.

Re: The operating system: should there be one? (2013) [pdf]

#179

Post by paulddraper » Wed, Sep 08, 2021, 1:40 AM UTC

overgard wrote: post #9

I can't help but think about what happened with graphics APIs - the older ones (DX9, OpenGL) held your hand more, and the new ones are super bare metal and not written for the faint of heart. I think most would agree this is better though; for an application developer you can simply use a much higher level library built on top, and for the library/engine developer you have a lot more power and control. The old APIs w…

> So largely things like Electron or Qt are acting as the defacto OS anyway to varying degrees of success

That's the natural (and arguable optimal) state of things: lower levels and higher levels.

High-level developers use high-level things, low-level developers use low-level things.

Every once in awhile someone gets the bright idea to combine all the layers into one, but finds out that in the real world that just isn't practical.

But we get developers pulling apart and adding layers over and over, driven by a love for "simplicity." Moving forward, or in circles? Hard to say, but probably forward.

Re: The operating system: should there be one? (2013) [pdf]

#180

Post by kazinator » Wed, Sep 08, 2021, 1:46 AM UTC

As soon as two or more separate applications share some common body of code that helps them deal with The Computer, you have an operating system. It doesn't matter whether that common body is a table of software traps that dispatch machine language routines, or whether it is Smalltalk objects.

Some game on a MS-DOS floppy disk that boots itself from the boot sector and uses BIOS calls has an operating system.

The set of requirements which describe the host environment (the "virtual machine" in the classic sense) that forms the backdrop against with an application is developed is the operating system.

The only way you don't have an operating system is when the application itself does everything it needs with regard to the outside world by itself poking at I/O registers, and handling every interrupt and so on. Anything independently organized for that purpose, given something resembling an API, is an operating system.

There is, or used to be, a sensible version of "there should not be an operating system" I first heard some decades ago. Namely this: "there should not have be an operating system with a hardware-protected user/kernel boundary". The idea is that there doesn't have to be kernel which the hardware conceals using privilege levels and fences. The idea is supported by the notion that all security can be handled at the software level. The system, as such, is somehow verified to be correct. The only way to execute code is via compiling it via the system's trusted compiler, which generates only safe instruction sequences. Those sequences can call functions in the system, and those functions sandbox what can be done. All notion of trust and privilege is software-level without any privileged instructions having to fall down a trap into a privileged kernel which meticulously validates arguments.

(All that rhetoric needs to be somehow adjusted for 2021, which finds us jaded by knowledge of side channel attacks, cache attacks and whatnot.)