91–100 of 188 posts
My dream is simple OS that works kinda like DOS: * Micro OS - Boot base from floppy drive if need be * Let me edit a text file to left put in the pieces I wants instead of a hundred pieces I don't * Includes BASIC language that build build a binary * Includes text based GUI for a text editor * Allow me to pick the drivers I want I like concept of some Linux OS'es but the ecosystem has got some huge it takes an expert…
Also I don't think it makes it easier. What if I want to delete a process but I accidentally end up deleting a file because I mistyped the name of the process (or the file has the same name as the process; which one should be deleted?)? I think we need separate commands because the user needs to be in a different mindset when doing these operations.
I'm actually not a huge fan of the Unix philosophy for that reason; you end up with a lot of general purpose commands which work together in theory and you can combine them in an infinite number of ways... But in practice, they are too general and this means that combining them becomes too slow for a lot of scenarios... If commands are too small and too general, you will always end up having to write long sequences of multi-lined commands chained together in order to do anything useful and performance will be bad; you might as well just write C/C++ code.
> 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.
Tandem had a real database OS. They didn't have files. Just blobs in the database. Their distributed, redundant database system had proper ACID properties. It owned the disks; there was no file level below the database. This made a lot of sense for a system intended for high reliability transaction servers and nothing else. Banks loved Tandems.
Just a general question: Do you think there is a market for a new operating system? The cost of building something better or equal to mainstream systems seem too high to even consider challenging the status quo.
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.
Just a general question: Do you think there is a market for a new operating system? The cost of building something better or equal to mainstream systems seem too high to even consider challenging the status quo.
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…
No they won't fail but a responsive user interface is critical. A process running on an RTOS won't complete any faster (probably the opposite), but displaying some sort of acknowledgement that a key has been pressed or a button has been clicked without any human perceptible delay is really nice. I'd love for the user interface portion of an OS to run with real time constraints.
I've been using osquery ( https://github.com/osquery/osquery ) for a while. It is neat and I can appreciate the idea of 'exposing OS interfaces as databases'.
osquery is cool. But, as far as I know, it doesn't expose the filesystem as a database, it is closer to /proc-as-a-database. (osquery can monitor specific files, in particular security-sensitive files, and expose events related to those files in SQL tables; but I don't think that facility is scalable from certain specific files to the entire filesystem.)
As that page describes, the "query" command (or its equivalent GUI) can be used to write filesystem queries, e.g.:
query ((MAIL:from=="*joe*") && (MAIL:when>=%2 months%))Earlier quoted context omitted.
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. No they won't fail but a responsive user interface is critical. A process running on an RTOS won't complete any faster (probably the opposite), but displaying some sort of acknowledgement that a key has been pressed or a button has been clicked without any human perceptible delay is really nice. I'd love for the…
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…
For querying information, I think the idea of representing everything as the same data structure really makes sense. The Unix philosophy or a relational view is perfect for this. However, for more sematically complex things that have possibly surprising side effects, such as starting a service, setting up a new user account, connecting a drive, installing a printer, I think we need separate commands or procedures to encapsulate all the complex behavior.