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

141–150 of 208 posts

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

#141

Post by marcus_holmes »

perbu wrote: post #128
OrvalWintermute wrote: post #119

Earlier quoted context omitted.

I've been expecting the unikernel approach to catch on more too - although not the "no OS" it can be pretty stripped down compared to a regular OS. Now that unikernels are starting to gain more traction in the DOD I expect this will continue.

I've worked with Unikernels for a couple of years. They are great, but they are very, very pure and this can be limiting. Say I have an web API written in Go. For some reason I need to do some openssl stuff before I start up my main program. In a container I can just wrap my program in a little shell script which generates/signs a cert before starting the API. Such a simple task. It is gonna be a lot harder with a Go…

I get that, but I rarely need to do stuff like this - I generally use the awesome ACME library to handle certs. But yes, if I did need to do that then a Unikernel wouldn't be useful.

But the reduction in attack surface of not having all those Swiss Army blades hanging about - and not having to configure them just right so I don't accidentally damage stuff - is a real benefit.

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

#142

Post by raxxorrax »

AussieWog93 wrote: post #27
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 `fra…

Just start to implement the ~300-400 functions listed here and the underlying systems supporting them. How long could that take, a whole weekend?

https://github.com/torvalds/linux/blob/master/arch/x86/entry...

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

#143

Post by burnte »

raxxorrax wrote: post #37
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.

MS .NET burned me hard with WPF. After finally looking into it, it more or less was cancelled for greener pastures. I don't think the newer Windows UI-Frameworks are loved that much and UWP is not really convincing for desktop applications. Just too much hassle for too little gain and the threat of vendor lock-in.

Years and years ago I was offered a job as an MS tech evangelist for the purpose of pushing Mozilla to use "new" MS technologies coming in what would eventually be Vista. I had a decent repuation in the Mozilla community, and I've always been a good communicator. The problem was some of the things they wanted me to push I knew would never get out the door.

There were three big issues although I can only remember two, which were WPF and WinFS. I said flat out WinFS isn't going to make the cut, the third feature wouldn't, and even if WPF did make it into the final build, Mozilla doesn't have the resources or desire to move Mozilla to WPF, especially since mozilla is a cross platform app. "Yes, we know, but utilizing WPF will make it easier to develop on Windows!" I pointed out while that's good for MS, it provides no benefit to Mozilla's non-windows users, and Mozilla would never do it. And WinFS isn't working at all, so why would they spend even a moment trying to figure out how the new FS would benefit an application?

I think the third leg was Palladium. "It'll make online banking so secure!" I remember commenting that with all the flack it was getting, it'll have no buy in from anyone else, and flop.

I don't think compulsive "tell it how it is" people are good for evangelist roles. :D

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

#144

Post by handrous »

dgb23 wrote: post #99
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…

> 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.

This is why, when people start asking for categories or hierarchies, you implement it as tags without telling them, if it's at all possible to do so.

Then when they decide they actually need tags, you either get to be a hero, or to goof off for a couple weeks, depending on your situation :-)

Nesting works the same way. "OK we said we needed N levels but actually we need arbitrary levels of nesting, and also we don't realize it but what we're asking for can introduce cycles to the structure". Every. Damn. Time.

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

#145

Post by psyc »

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.

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

#146

Post by infogulch »

LAC-Tech wrote: post #38
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.

I enjoyed this post, but I'm struggling to wrap my head around what relations you'd have in this OS. Sym links become foreign keys?

It's not about relations, it's about schemas and types. My complaint is that none of the schemas and types are communicated by the OS in an explicit, uniform, programmatic way.

Everything in 'special' mounted filesystems like procfs, sys, cgroupsv2, etc as a start. These all use implicit schemas of particularly named files with particular contents that you have to learn about out-of-band to just to do anything.

Requirement 1: Everything has an inspectable schema.

All the configuration files with their own home-grown format that you can only validate by restarting the program that relies on it and hoping that it doesn't crash your system is for the birds.

Requirement 2: Files that must have a particular format must also have a well-defined Type that can be validated to be correct in a uniform way outside the program that uses it.

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

#147

Post by klodolph »

smaudet wrote: post #139
klodolph wrote: post #131

Earlier quoted context omitted.

Not sure what you’re talking about. ObjC runtime is fairly small. The basics of what you need for ObjC is just objc_msgSend, which is basically a fancy hash lookup written in assembly language. If you want ObjC on a microcontroller, you’d want to port this function to your target architecture. There are a few other components you “need” but objc_msgSend is the key one. You’d probably also want some form of malloc(),…

It's probably exactly that runtime...desk devs have forgot that embedded is tiny, megs not gigs of memory, so not one but 2-3 orders of magnitude smaller. You can have all the 'simple' calls you like but if you need to malloc half a gig of ram just to get started...that is heavy and bloated. Also you say 'architecture' but unless you are talking a battery hungry cellphone you are probably talking 16 or 32 bit proc no…

> I don't know realistically what Obj C uses in the osx cpu architecture but I'm almost certain it's not going to be as simple as just retargeting your compiler...

Objective C is in mainline GCC. You retarget your compiler and port the runtime. As far as I know, any target with GCC support can run Objective C, given a runtime. The important parts of the runtime require kilobytes, not megabytes, of space.

Remember that Objective C was originally a very thin layer on top of C. You take all the [method calls] and replace them with calls to objc_msgSend(). The overhead is fairly small— your object instances need the “isa” pointer, which is basically just a pointer to a vtable. The objc_msgSend() function reads the vtable and forwards method calls to the correct implementation.

My experience is that Objective C binaries typically have a much smaller footprint than C++ binaries. That’s obviously not some kind of rule, but it reflects idiomatic usage of Objective C. In C++ you'd use a std::vector which is a templated class, which gets instantiated for every different T you use in your program. In Objective C, you’d use NSArray, which is monomorphic.

This all should be completely unsurprising—since Objective C first appeared in the 1980s, it’s no surprise that it doesn’t need much memory.

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

#148

Post by dgb23 »

handrous wrote: post #144
dgb23 wrote: post #99

Earlier quoted context omitted.

> 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.

This is why, when people start asking for categories or hierarchies, you implement it as tags without telling them, if it's at all possible to do so. Then when they decide they actually need tags, you either get to be a hero, or to goof off for a couple weeks, depending on your situation :-) Nesting works the same way. "OK we said we needed N levels but actually we need arbitrary levels of nesting, and also we don't…

Fully agreed!

It's a tyranny of hierarchical data-structures and ontologies. Always breaks down. Use relational models, graphs, tags, sets, uuids/global identifiers etc. Trees are an optimization strategy/snapshot and almost never a model for the real world.

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

#149

Post by abruzzi »

t43562 wrote: post #102
cpach wrote: post #81

Earlier quoted context omitted.

Didn’t BeOS have some features like that?

https://www.haiku-os.org/legacy-docs/practical-file-system-d... The Be operating system (BeOS) uses BFS as its native file system. BFS is a modern 64-bit journaled file system. BFS also supports extended file attributes (name/value pairs) and can index the extended attributes, which allows it to offer a query interface for locating files in addition to the normal name-based hierarchical interface. The attribute, inde…

Also, prior to BFS, in the earlier beta builds of BeOS, the file system was much more database like, but it ended up having performance issues (IIRC), so in a later version, they replaced it with BFS.

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

#150

Post by pjmlp »

klodolph wrote: post #147
smaudet wrote: post #139

Earlier quoted context omitted.

It's probably exactly that runtime...desk devs have forgot that embedded is tiny, megs not gigs of memory, so not one but 2-3 orders of magnitude smaller. You can have all the 'simple' calls you like but if you need to malloc half a gig of ram just to get started...that is heavy and bloated. Also you say 'architecture' but unless you are talking a battery hungry cellphone you are probably talking 16 or 32 bit proc no…

> I don't know realistically what Obj C uses in the osx cpu architecture but I'm almost certain it's not going to be as simple as just retargeting your compiler... Objective C is in mainline GCC. You retarget your compiler and port the runtime. As far as I know, any target with GCC support can run Objective C, given a runtime. The important parts of the runtime require kilobytes, not megabytes, of space. Remember tha…

GCC doesn't do modern Objective-C, only what they got from NeXT days.
Post reply on HN