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

91–100 of 208 posts

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

#91

Post by qayxc »

amelius wrote: post #67

Related question: do we need device drivers?

That's a definite yes.

I do NOT want to go back to the times when we had to write and ship individual drivers for each graphics card, sound card and peripheral we wanted to support in our software.

Could you imagine having to select the physical port, IRQ and DMA channel of your sound device for each app that wants to output sound? Because that's what had to be done in DOS and screens like this https://flaterco.com/kb/audio/PCI/DS-XG_IRQ_error.png

were commonplace. Good enough if you had well-defined devices like SoundBlaster(Pro) or GUS that you could auto-detect without crashing the PC, but a living nightmare with clones that didn't quite behave the same way.

So unless you only plan to support a single set of well-defined hardware, device drivers are a must.

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

#92

Post by ilaksh »

OSes do have shared abstractions such as file systems and process input and output. I think the trick is to make the common abstractions richer in a way that enough people agree on and are willing to adopt. Most of the shared OS features are basically grandfathered in. So a big part of this is that this stuff is not really a rational choice usually. It's just the way it's always been.

So upgrading the capabilities and creating new common abstractions in an OS is not that hard. But almost impossible to get the majority to go along with it.

Browsers demonstrate an additive way of getting a lot of that. In that we now have essentially two highly compatible widely deployed VMs -- Firefox and Chrome. Which can be programmed in a number of languages that compile to JavaScript or web assembly and share a rich API.

Web assembly modules seem relevant.

https://github.com/WebAssembly/proposal-type-imports/blob/ma...

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

#93

Post by mkup »

vbezhenar wrote: post #24

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…

Oh no, I prefer BIOS/UEFI firmware to be as lean as possible, like, "boot my OS and get out of the way as quickly as possible" (because all software has bugs, larger software has more bugs, and fixing/updating firmware is a gross PITA, I mean inability to roll back and risk of bricking the hardware e.g. due to power loss). At least in Linux I can apply kernel patches individually, and in Windows I can replace a file here and there, but firmware is a monolith, so it is a "hit or miss" kind of thing. More complexity in firmware rapidly shifts this wholistic thing to "permanent miss" state.

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

#94

Post by gatestone »

“Programs = data structures + algorithms”

If you have more than one program, they need shared data and access procedures, like the “user” and “the hardware”. Who manages them: The OS?

Maybe you want to share a bit more like some common higher level functionality. That becomes part of the OS, de jure (resident kernel) or at least de facto (loadable kernel modules).

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

#96

Post by account42 »

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.

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.

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

#97

Post by Ygg2 »

pjmlp wrote: post #78
5e92cb50239222b wrote: post #46

Earlier quoted context omitted.

How do you find time for work? I see your comments shitting on everything that's not Windows pretty much everywhere.

https://xkcd.com/303/ You missed my praises for Apple and Google platforms.

What language do you use C++ or Rust?

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

#98

Post by chriswarbo »

vbezhenar wrote: post #24

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…

Sounds like you'd enjoy OpenFirmware https://en.wikipedia.org/wiki/Open_Firmware

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

#99

Post by dgb23 »

wsc981 wrote: post #79
qPM9l3XJrF wrote: post #77

"an operating system is a collection of things that don’t fit inside a language; there shouldn’t be one" I've wondered the same thing about databases. Just like an OS, a database has to manage data on disk and figure out when to cache it. The files & folders metaphor is arguably a relic of pre-computer times--instead of searching through folders, it is easier to search and sort based on particular attributes, somethi…

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…

> humans generally like to organise things hierarchically

People like doing that until they have sufficiently essential complexity that it breaks down, then they hate it with passion.

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

#100

Post by dgb23 »

pjmlp wrote: post #84
qPM9l3XJrF wrote: post #77

"an operating system is a collection of things that don’t fit inside a language; there shouldn’t be one" I've wondered the same thing about databases. Just like an OS, a database has to manage data on disk and figure out when to cache it. The files & folders metaphor is arguably a relic of pre-computer times--instead of searching through folders, it is easier to search and sort based on particular attributes, somethi…

Oracle does that, https://docs.oracle.com/en/database/oracle/oracle-database/2... Then use APEX for Web applications, that make use of stored procedures, https://apex.oracle.com/en/ Other enterprise RDMS have similar offerings.

getting a 404 on the first link
Post reply on HN