Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

citeseerx.ist.psu.edu

Post reply on HN
Print view View original

21–30 of 208 posts

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

#21

Post by infogulch »

ModernMech wrote: post #6
p2t2p wrote: post #5

On one had - yes please, screw OSes, gimme something like Smalltalk environment (in it's Pharo incarnation preferably). On other hand - define OS. Isn't that Smalltalk environment an OS if it runs bare metal?

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.

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

#22

Post by pjmlp »

otabdeveloper4 wrote: post #18
pjmlp wrote: post #14

Earlier quoted context omitted.

Nah, Android, macOS and Windows are doing just fine, it is the classical UNIX desktop that cannot get their act together. The existing issues aren't technical, rather political, like the WinRT crusade that ended up bombing and now we have plenty of GUI toolkits to chose from on Windows. Swift, Java, Kotlin and the .NET languages are more than high level enough.

> the classical UNIX desktop CDE? That hasn't existed for decades.

Who cares about CDE, the classical UNIX desktop, as in the way that BSDs and GNU/Linux keep pushing for the old days with their fragmented stacks.

macOS, although a UNIX, follows the same ideolagy as NeXTSTEP, where UNIX compatibility was a means to bring software into the platform, and that was about it, GUI software was to be fully taken advantage of Objective-C Frameworks.

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

#23

Post by AnthonyMouse »

overgard wrote: post #13
mjevans wrote: post #11

Unix generally has the correct basis for the design. I agree that a filesystem as we know it in unix-like systems is a set of objects (directories) and files. Would it not be preferable to retain this simple interface and instead conceive of interaction between programs and threads not as a stream of distinct objects in memory, but rather as a data tree within each program's control which can be exposed as input or o…

I think the problem with the unix model is that there isn't a rich enough array of types -- everything is just a stream of bytes and the closest thing you have to lists and records are strings with spaces and newlines. It was revolutionary in the 70s but compared to what you can do with something like powershell (which has its own issues) it's just not a rich or easy to use model anymore.

"The fundamental problem of communication is that of reproducing at one point either exactly or approximately a message selected at another point. Frequently the messages have meaning; that is they refer to or are correlated according to some system with certain physical or conceptual entities. These semantic aspects of communication are irrelevant to the engineering problem."

- Claude Shannon, A Mathematical Theory of Communication

Everything is inherently a stream of bytes. You can use programs that interpret them as typed data or newline or null-delimited arrays all you like.

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

#24

Post by vbezhenar »

I would love more collaboration between operating systems. There should be more layers with standard interfaces.

For example BIOS used to be a driver layer back in the day, providing simple API to underlying OS. This concept should be expanded. I don't see no reason for every OS to rewrite those drivers again and again. There should be some standard for common device APIs, like disks, keyboards, mouses, GPU and so on. I should be able to buy an Nvidia GPU, download and install UEFI driver and it should provide Vulkan API for any underlying operating system, Windows, Linux, OpenBSD, ReactOS.

Another example is file systems. All major operating systems are very similar when it comes to file systems, at least from the user PoV. Yes, there are Windows ACLs, Linux permissions, but it should be possible to abstract those away enough. So Windows could install its latest Windows 11 NTFS driver into UEFI and Linux should be able to just use it to access NTFS safely, without any gigantic efforts to reverse-engineer and reimplement everything from scratch.

At one point I thought about virtualization being an answer to those demands. These days you can write completely virtualized operating system which needs to implement virtblk, virtfs, virtio-* drivers and run it on any host operating system with perfect driver support from manufacturer. GPU is not there, but I don't think that it's impossible to implement. Of course running a full-blown ad-ridden Windows 11 just as a hypervisor seems like not the most elegant solution.

Unification will not play nicely with new progressive features like BTRFS, though. That's something to think about as well.

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

#26

Post by vbezhenar »

mjevans wrote: post #20
overgard wrote: post #13

Earlier quoted context omitted.

I think the problem with the unix model is that there isn't a rich enough array of types -- everything is just a stream of bytes and the closest thing you have to lists and records are strings with spaces and newlines. It was revolutionary in the 70s but compared to what you can do with something like powershell (which has its own issues) it's just not a rich or easy to use model anymore.

Simplicity is a good baseline. In Unix systems, off the cuff scripting works really well for live human interaction. Complexity, particularly NOT-self-documenting complexity, becomes a nightmare. Imagine instead that each program controls a special area under /proc/(pid)/ which behave like tmpfs to that program: named interfaces are subdirectories, messages are files. Reflection of supported interfaces becomes easy.…

> Imagine instead that each program controls a special area under /proc/(pid)/ which behave like tmpfs to that program: named interfaces are subdirectories, messages are files.

That's API. Users will depend on it. So now you either have to freeze your code or break users flows.

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

#27

Post by AussieWog93 »

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…

>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 `framebuffer[0] = 0x00ff0000`.

For win32 or Cocoa, you need to create a window, alter its flags to ensure it's borderless, change its size and posistion to 1x1 and [0,0] (or [0, screen_height] on the Mac), strip away the drop shadow, respond to regular paint events and pray like hell that nothing else draws over the top of it.

>True low level control is kind of a pain

It depends on what you're trying to achieve. If you're trying to get something highly responsive that looks exactly like the UI spec, most libraries tend to make this job harder when the abstractions leak and you're forced to rely on bizarre hacks that make no sense and feel genuinely demoralising to implement.

Dear ImGui, which exposes far more of the low-level internals than any other API, is an absolute joy to build GUIs in and significantly easier than something which "holds your hand" at every step.

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

#28

Post by AussieWog93 »

EllieEffingMae wrote: post #19
pjmlp wrote: post #14

Earlier quoted context omitted.

Nah, Android, macOS and Windows are doing just fine, it is the classical UNIX desktop that cannot get their act together. The existing issues aren't technical, rather political, like the WinRT crusade that ended up bombing and now we have plenty of GUI toolkits to chose from on Windows. Swift, Java, Kotlin and the .NET languages are more than high level enough.

Could you expand on this more? I don't know a lot about GUI programming, but I'd be interested in learning what the current failings are within the desktop space.

Specifically for Linux, there is no ubiquitous standard with decent performance and a predictable look such as win32 or Cocoa.

Instead, developers rely on toolkits such as Qt or GTK to ensure compatibility, which are usually either bloated or ugly.

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

#29

Post by aitchnyu »

UnlockedSecrets wrote: post #3
Causality1 wrote: post #2

Title needs the [PDF] tag.

The PDF: Should there be one?

There is a HTML-bundle alternative to PDF in my utopia. User agents can render documents optimized for any screen instead of hardcoded two column A4 pages. Nouns and verbs are highlighted.

https://rewordify.com/index.php

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

#30

Post by rocqua »

AnthonyMouse wrote: post #23
overgard wrote: post #13

Earlier quoted context omitted.

I think the problem with the unix model is that there isn't a rich enough array of types -- everything is just a stream of bytes and the closest thing you have to lists and records are strings with spaces and newlines. It was revolutionary in the 70s but compared to what you can do with something like powershell (which has its own issues) it's just not a rich or easy to use model anymore.

"The fundamental problem of communication is that of reproducing at one point either exactly or approximately a message selected at another point. Frequently the messages have meaning ; that is they refer to or are correlated according to some system with certain physical or conceptual entities. These semantic aspects of communication are irrelevant to the engineering problem." - Claude Shannon, A Mathematical Theory…

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 fragmented world of low quality idioms. And hence gets judged poorly.

Post reply on HN