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

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

#161

Post by ModernMech » Tue, Sep 07, 2021, 5:06 PM UTC

hnlmorg wrote: post #71

ModernMech wrote: post #6

Earlier quoted context omitted.

Yes, there is a very blurry line between operating systems, programming languages, and we can include databases as well. Some operating systems as you point out are PLs. Some PLs are implemented as databases. They’re all just really complex accounting systems by nature. Look at the implementation of a lot of OSes, PLs and DBs they are really just made up of tables keeping track of relationships all the way down.

> Some operating systems as you point out are PLs None that immediately spring to my mind. There are operating systems that incorporate programming languages as their default user interface (like UNIX that drops into a Borne shell and LISP machines) and there are computers that have programming languages baked into their firmware (like the 70s and 80s micro computers did with BASIC). But in neither instance is the la…

Others in this thread have mentioned some good ones: Smalltalk, Lisp Machines, and the JVM. Some others I would add:

- Pilot was an OS that was essentially bare metal Mesa. It was written in Mesa, only runs Mesa programs, and used Mesa language features for OS capabilities like safety: https://courses.cs.washington.edu/courses/cse550/20au/papers...

- Cedar was both a PL and an OS: https://www.ics.uci.edu/~andre/ics228s2006/swinehartzellwege...

- The Oberon OS and Oberon PL are highly coupled https://people.inf.ethz.ch/wirth/ProjectOberon1992.pdf

- Here's a Scheme OS called MrEd: https://www2.ccs.neu.edu/racket/pubs/icfp99-ffkf.pdf

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

#162

Post by lavabiopsy » Tue, Sep 07, 2021, 5:14 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…

The thing is those are likely to be simple GUIs. Those are a great use case for immediate mode. But try it with something that has a lot of:

- Wrapping text labels

- Widgets that are similar to CSS flexbox where the size of elements depends on other elements

- List/tree widgets or text editor widgets with large datasets in them

And then you will notice performance tanks. Think of trying to build a text editor that way, if you opened a 5MB text file, you would have to rescan the whole 5MB and compute reflow for it every time.

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

#163

Post by lavabiopsy » Tue, Sep 07, 2021, 5:35 PM UTC

AussieWog93 wrote: post #86

lavabiopsy wrote: post #74

Earlier quoted context omitted.

Maybe you want to help this person who is trying to integrate harfbuzz: https://github.com/ocornut/imgui/issues/4227 The other major thing missing in relation to that is input method support. The problem with those type of APIs and accessibility is that implementing screen reader support basically means making it retained mode in some capacity, because accessibility APIs expect you to export a tree of objects and pus…

>Maybe you want to help this person who is trying to integrate harfbuzz: https://github.com/ocornut/imgui/issues/4227 Looks like theirs is far more advanced than mine (mine would just generate a texture per string and cache it, the main problem it solved was being able to display non-ASCII filenames). I don't think there's much I could contribute to them at all. >accessibility APIs expect you to export a tree of obje…

This is the way these platform APIs are designed, you could theoretically make a screen reader that doesn't need that and just asks the app to recompute its state every time, but they don't currently work that way.

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

#164

Post by jacquesm » Tue, Sep 07, 2021, 5:36 PM UTC

psyc wrote: post #145

jacquesm wrote: post #51

Let's start off with defining what an Operating System really is because depending on where you draw that line the outcome will be substantially different. Ignoring mainframes and other large installations for the moment, strictly from a 'personal computer' point of view: If you see the operating system as the task-schedular + IPC clearinghouse then the system is simple, well defined and it can be expected to perform…

Where do you rate the part of the OS that makes 100,000 types, brands, and models of devices all look about the same to our apps? I always saw hardware compatibility and abstraction as the greatest value proposition, not only for the user but for the PC industry as a whole.

Hardware abstraction layer. Can be done in userspace, with the exception of a timer. You may need to add some interrupt arbitration logic.

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

#165

Post by joconde » Tue, Sep 07, 2021, 6:32 PM UTC

infogulch wrote: post #21

ModernMech wrote: post #6

Earlier quoted context omitted.

Yes, there is a very blurry line between operating systems, programming languages, and we can include databases as well. Some operating systems as you point out are PLs. Some PLs are implemented as databases. They’re all just really complex accounting systems by nature. Look at the implementation of a lot of OSes, PLs and DBs they are really just made up of tables keeping track of relationships all the way down.

I would be soooo happy if OSes were just absorbed by databases. The file system is just a heirarchal key value store: genius! Let's make it untyped so you have to parse everything manually just to interpret it: not so great. Yes I'm saying the Unix file system is a worse mongodb. Please at least give me a postgres or something.

Do apps add their own types in that system? Otherwise, I have a hard time imagining a set of base data types that could usefully represent things like OpenOffice documents, geo-referenced geometrical feature databases, and the thousands of other field-specific binary formats that are in use. Storing all these things as data blobs just puts us back in the "untyped filesystem" situation.

Maybe I've completely misunderstood your proposition, though.

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

#166

Post by kaba0 » Tue, Sep 07, 2021, 7:42 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…

And would you want your laptop taking as much power writing a word document as it takes to run a AAA game?

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

#167

Post by AnthonyMouse » Tue, Sep 07, 2021, 8:13 PM UTC

TheOtherHobbes wrote: post #65

AnthonyMouse wrote: post #33

Earlier quoted context omitted.

Except that there are standard ways of doing arrays. Newline terminated is the most common, null-terminated is used for data that could have unusual characters in it, and most of the standard utilities support both. The problem with not doing this is that the operating system is imposing some arbitrary standard on data that may not have even come from the same system. If the data you get is JSON, there are utilities…

Standard formats like JSON, XML, and PDF are arbitrary encoding defaults, but on a slightly higher level. If I send your system something obscure like an SDIF audio file you're not going to have the tools to do anything with it unless you can find and install an SDIF library. What if the OS could do this automatically because a typed schema and standard API was built into the SDIF (or any) standard and installable in…

> If I send your system something obscure like an SDIF audio file you're not going to have the tools to do anything with it unless you can find and install an SDIF library.

Which is the point. So then you find and install an SDIF library. The OS can't reasonably predict and support every possible file format that anyone will ever come up with in the past or future, so the answer is to be flexible and use different utilities for different formats.

> What if the OS could do this automatically because a typed schema and standard API was built into the SDIF (or any) standard and installable in the same way code dependencies are?

The problem with this is that what you can do with a file depends on the format. You can split a PDF into pages; you can't split an SDIF into pages. An SDIF might have channels; a PDF doesn't have channels. You could call each frame in a video a "page" and try to compare them with a PDF, but the video "page" is going to be a pure individual image whereas a PDF page might have text or multiple individual embedded images.

Everything is so specific to the format that you're going to want format-specific utilities to operate on it that take into account the characteristics of the format.

At best you'll sometimes have multiple formats that are largely "the same" interface-wise like PNG and JPEG and then you would want to use the same interfaces to access both, but that's what already happens. You use e.g. ImageMagick when dealing with both PNGs and JPEGs because it supports both. But it doesn't support SDIF because you need a completely different interface when dealing with audio.

And file formats already have magic strings in them that identify what kind of file they are, which is about the extent of the information the OS could provide you about the file without assuming anything about what's inside it. The schema is already implied by the header magic.

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

#168

Post by overgard » Tue, Sep 07, 2021, 10:14 PM UTC

AnthonyMouse wrote: post #33

rocqua wrote: post #30

Earlier quoted context omitted.

Thing is, without a build in (good) way to do e.g. array types, every program will roll their own. That is lots of duplicate work, and makes having programs interact a manual process of integrating 2 unspecified ad-hoc standards. Programming languages create idioms and standard ways to do things. We judge those for their clarity and quality. On that front UNIXs "you get a stream if bytes, do what you want" leads to a…

Except that there are standard ways of doing arrays. Newline terminated is the most common, null-terminated is used for data that could have unusual characters in it, and most of the standard utilities support both. The problem with not doing this is that the operating system is imposing some arbitrary standard on data that may not have even come from the same system. If the data you get is JSON, there are utilities…

Well, in light of the topic of the original article, I'd just compare working with byte streams to working with a smalltalk style object, and see which one is more pleasant. (You could still do a byte stream in smalltalk land, you'd just have to be explicit, it wouldn't be the default)

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

#169

Post by infogulch » Tue, Sep 07, 2021, 10:16 PM UTC

joconde wrote: post #165

infogulch wrote: post #21

Earlier quoted context omitted.

I would be soooo happy if OSes were just absorbed by databases. The file system is just a heirarchal key value store: genius! Let's make it untyped so you have to parse everything manually just to interpret it: not so great. Yes I'm saying the Unix file system is a worse mongodb. Please at least give me a postgres or something.

Do apps add their own types in that system? Otherwise, I have a hard time imagining a set of base data types that could usefully represent things like OpenOffice documents, geo-referenced geometrical feature databases, and the thousands of other field-specific binary formats that are in use. Storing all these things as data blobs just puts us back in the "untyped filesystem" situation. Maybe I've completely misunders…

If a file emitted by some third party program is intended to conform to some type, yes it would be great if that type was expressed in the filesystem. Maybe that would look like a reference to a 'schema description' file that has a specific format that is bundled with the app.

Now, that doesn't stop MyProprietaryApp from declaring that the type MyProprietaryFile consists of a big bucket of bytes which it then interprets how it likes, but that's inevitable and not worth worrying about.

The point is to enable defining directory and file schemas for my OS and applications that I can control so that interaction and discovery within these systems isn't so baroque.

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

#170

Post by overgard » Tue, Sep 07, 2021, 10:21 PM UTC

cmrdporcupine wrote: post #155

AussieWog93 wrote: post #27

Earlier quoted context omitted.

>I think modern OS stacks are in a similar boat, at least Windows and macOS. I come from a background as a EEE mainly writing embedded code before somehow stumbling into frontend code (in win32, Cocoa and Qt) at my old job. From my experience, OS-Level APIs definitely have more in common with Electron or Qt than they do "bare metal". To make the top left pixel red on a bare metal system or RTOS, you simply write `fra…

Arguably win32 GUI or Cocoa are not "OS level" APIs; yes some aspects of them are invoked through syscall type interfaces (esp win32) but not consistently and the operating system itself is entirely usable without them. Especially Cocoa. You can boot a Mac into a BSD shell without ever running Finder and the GUI. Writing into a framebuffer is arguably as much of an abstraction these days as many of these toolkits. In…

Well, that's kind of what I'm driving at with things like the win32 api being a bit too high level and still kind of sucking. An example would be the GDI (the way you draw simple graphics). Like, it's in the worst of both worlds in that it's both slow and annoying to use. Or you can use DirectX and draw things fast, but you need to know a lot more. I think my point is mainly that OS's might be better off just giving you things like DirectX (and mmap and ioctl, etc.) and leaving off things like the GDI.

I know right now Microsoft keeps making like 50000 new UI frameworks and part of me is like, just knock it the fuck off, give me some style guidelines and some super-efficient very low level no-frills API's and let me just build apps off a library like Qt that abstracts it.