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

A dream of an ultimate OS (1995)

okmij.org

Post reply on HN
Print view View original

101–110 of 188 posts

Re: A dream of an ultimate OS (1995)

#101

Post by 0xcde4c3db »

TickleSteve wrote: post #79
snvzz wrote: post #61

Oh, it's the every OS sucks story again. It's all about the user experience. System should be friend and still enable the user to increasingly get more out of the computer. It also needs to be extremely responsive. AmigaOS got a lot right back in the 80s. BeOS (and now Haiku as spiritual successor) took a lot from that (system kits vs amiga's default set of shared libraries, and the concept of datatypes) and added so…

Being an RTOS is only necessary if your application has a requirement for real-time response and is also itself designd for bounded-response-time. Ignoring drivers for the moment, your typical desktop application does not have a need for a bounded response time. Desktop applications typically do not fail due to a dialog box being popped up a few milliseconds late. The underlying drivers, on the other hand, do tend to…

> Desktop applications typically do not fail due to a dialog box being popped up a few milliseconds late.

Not a few milliseconds, but a few dozen seconds might be a different story. While it might be hard to predict or measure an exact number, your deadline is however long it takes for the user to equate it to "forever" and kill the process / leave the website / uninstall the app / etc..

Re: A dream of an ultimate OS (1995)

#102

Post by kerkeslager »

maattdd wrote: post #85

Unrelated to the article, but the author (Oleg) is one of the star of the typed functional programming world. For example, one of his research project (BER MetaOCaml) is about generating typesafe OCaml at runtime (to improve performance mostly). I strongly recommend you to check this ( http://okmij.org/ftp/ML/MetaOCaml.html ) if you are interested in the field.

Yeah, it's always interesting to see what makes it onto the front page of HN from the blogs I read regularly. He's the sort of person I'd love to be around so I could ask him questions, but if I were with him in a room and could ask him 10 questions, none of them would be about operating systems.

Re: A dream of an ultimate OS (1995)

#103

Post by nickpsecurity »

TickleSteve wrote: post #79
snvzz wrote: post #61

Oh, it's the every OS sucks story again. It's all about the user experience. System should be friend and still enable the user to increasingly get more out of the computer. It also needs to be extremely responsive. AmigaOS got a lot right back in the 80s. BeOS (and now Haiku as spiritual successor) took a lot from that (system kits vs amiga's default set of shared libraries, and the concept of datatypes) and added so…

Being an RTOS is only necessary if your application has a requirement for real-time response and is also itself designd for bounded-response-time. Ignoring drivers for the moment, your typical desktop application does not have a need for a bounded response time. Desktop applications typically do not fail due to a dialog box being popped up a few milliseconds late. The underlying drivers, on the other hand, do tend to…

There is some benefit to real-time ability in an OS. Mainly, to prevent one application from freezing up the system. That's happened to me both on Windows and Linux. Took work to wrestle it back into my control again.

I remember people who used the QNX demo disk on old machines describing how they could do big compiles in the background with the system still responsive to input. I'm guessing the parts interacting with the user had higher priority.

Re: A dream of an ultimate OS (1995)

#104

Post by taffer »

smallnamespace wrote: post #82
miltondts wrote: post #40

Earlier quoted context omitted.

That's the beauty of the relational model, it doesn't specify data structures. Those can be added later by indexes. For more info check https://www.researchgate.net/publication/2364452_Data_Struct...

The set of indexes are a form of data structure though, with all the state juggling and heuristics that usually go along with them (What access pattern requires this index? When do I have too many of them? What locks when I add/drop an index?). This adds complexity and unpredictability to the user.

I would argue that dropping and creating indexes is much less work than refactoring large parts of your codebase just to change a data structure. Also, you can have multiple indexes on a table and the RDBMS ensures that they are always synchronized, which is something you won't achieve if you code the data structures yourself.

Re: A dream of an ultimate OS (1995)

#105

Post by nickpsecurity »

rzzzt wrote: post #54

From a sufficiently abstract point of view, one could argue that classic DBMSs are already looking like small operating systems: - are composed of multiple processes; can include process management code - can access hardware directly (for efficient arrangement, caching and retrieval of data) - include support for multiple users, concurrent sessions - stored procedures require compiler tooling and runtime (VM) - can b…

A lot of things are starting to work like operating systems for performance and/or security reasons. We might need to eliminate the distinction in our thinking to get better results on new systems. Quite a few programmers and researchers already have, making things like you describe. Others are building from hardware up to try to make their implementations more 1-to-1 with how hardware works.

Re: A dream of an ultimate OS (1995)

#106

Post by cmrdporcupine »

Animats wrote: post #41
mirimir wrote: post #8

> But it does not have to be this way. If a database engine is implemented as a core system service, along with simple tools to browse and modify database records, the gordian knot of system configuration files disappears. MacOS comes very close to this ideal, with ResEdit as this universal database editor. Or AS/400, which is more or less a SQL database.

ResEdit was an interesting idea. It suffered from a major problem - terrible data integrity. The original version had to work on floppies, with very slow seeks and writes. So it didn't reach an consistent state until you were all done and closed the resource fork of the file. Attempts were made to use it as a database, but stuff was always getting corrupted. The original MacOS suffered badly from being a cram job int…

And it's tragic when you consider that LisaOS had multitasking, process separation, and I believe a hardware MMU.

The Mac grabbed most of the good UI aspects of the Lisa, but stripped out all the decent OS concepts. It worked to sell the first Macintoshes, but didn't scale out later, and by that time they'd killed off the Lisa.

Re: A dream of an ultimate OS (1995)

#108

Post by goatinaboat »

rzzzt wrote: post #54

From a sufficiently abstract point of view, one could argue that classic DBMSs are already looking like small operating systems: - are composed of multiple processes; can include process management code - can access hardware directly (for efficient arrangement, caching and retrieval of data) - include support for multiple users, concurrent sessions - stored procedures require compiler tooling and runtime (VM) - can b…

Yes this has been true of major RDBMS for a long time. A conventional OS bootstraps Oracle (for example) and Oracle handles its own memory management, process scheduling, IPC, talks directly to storage, handles logins and interactive use, etc etc. Same with SQL Server. The AS/400 takes it to the extreme.

Re: A dream of an ultimate OS (1995)

#109

Post by fouc »

rzzzt wrote: post #54

From a sufficiently abstract point of view, one could argue that classic DBMSs are already looking like small operating systems: - are composed of multiple processes; can include process management code - can access hardware directly (for efficient arrangement, caching and retrieval of data) - include support for multiple users, concurrent sessions - stored procedures require compiler tooling and runtime (VM) - can b…

You raise a point - we have a bunch of small operating systems running on top of our existing operating systems. DBMSes, editors (emacs), browsers, and more. There's a great amount of inefficiences being added because everyone is re-inventing OSes and/or DBMSes at every layer.

Re: A dream of an ultimate OS (1995)

#110

Post by fouc »

cryptica wrote: post #92

This sounds like my nightmare operating system. Reusing the same command to operate on very different kinds of objects is a bad idea. A file is very different from a process. A database table is very different from a file. Whenever you try to homogenize operations on different kinds of objects under a single operation name, you inevitably lose flexibility or you have to add a lot of if-then-else statements inside the…

He probably meant having the same internal interface, it would still be doable to have various aliased commands that call the same interface.

As for UNIX philosophy of stringing together lots of general purpose commands to get the desired result - the nice thing about that is you don't need to know programming, and it's very convenient for one off scripting.

Post reply on HN