I'm always sad when I see *nixes using FS as datatypes.
conf.d to indicate list of entries as files for instance.
A dream of an ultimate OS (1995)
151–160 of 188 posts
Re: A dream of an ultimate OS (1995)
#152The perfect OS is no OS. An OS is just specialized software that provides services, but by providing those services and only those services, you're locked into that OS, and all those services whether you want them or not.
And we have to do that because we don't want all our software to have to provide the basic services, but we don't really get that: we still have to provide all the libraries it needs, some of which emulate an OS anyway by providing a big, complex runtime.
So I don't think this is an OS problem, it's a build problem. If I can ask a machine what services it has, and ask the software what services it needs, it should be possible to find a minimal solution.
I think NixOS gets very close to this ideal, even though it's obviously built on a traditional OS. But if we're going to talk about the "ultimate OS" I think it's worth it to ask, "how much can we take away from this?"
And the reason to want that is simply driving towards the goal of making software components that are able to work together reliably rather than building these monolithic devices that only a handful of veterans can understand.
Re: A dream of an ultimate OS (1995)
#153The perfect OS is no OS. An OS is just specialized software that provides services, but by providing those services and only those services, you're locked into that OS, and all those services whether you want them or not. And we have to do that because we don't want all our software to have to provide the basic services, but we don't really get that: we still have to provide all the libraries it needs, some of which…
what you're interested in sounds a lot like a unikernel/library OS
Re: A dream of an ultimate OS (1995)
#154Earlier quoted context omitted.
> 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…
Real-time response and a/an RTOS are not the same thing. An RTOS only allows processes with a known (or computable) runtime to run so that it may make guarantees about timing of execution. In some RTOSes scheduling may be entirely static and determined at compile time. This type of OS is used in critical systems (aircraft, hospital equipment, nuclear bombs). It's not really the type of system you'd want for a general…
>An RTOS only allows
That's just the easy way to achieve hard realtime.
It is, fortunately, not the only way.
Re: A dream of an ultimate OS (1995)
#155Can someone describe the NEGATIVE aspects of having a database-OS?
It makes the conceptual model of the OS more complex. Filesystems with basic permissions are easy to understand becuse of the forced structure. IMO, ACLs are a bad idea for the same reason, they make it harder to see what is going on while not solving a problem I actually have. I guess they do solve problems that some people have so that makes them more attractive if you are one of those people but IMO there must be better ways to solve those problems.
Personally, I'd like to see version control and file compression integrated in my filesystem. I do not want my operating system to be distributed or rely on network access.
I also think a separation between administrative access to the full system and views of applications may be a good idea. It seems to me that the ideal OS would heavily restrict the file and network access of applications and there would be a separate administrative domain with full access but limited complexity. The operating system then manages the sharing of needed data between applications and network access that the user allows. I think having the system parse a standard configuration file format for applications would make sense in this model, but that configuration file can still just be text. Also having a sub-user permissions structure similar to the overall system users seems like a good idea to me. Many applications that users run are hostile and dealing with that requires major changes vs current desktop operating systems. Database vs. filesystem is a minor issue in comparison and personally I don't see the appeal of using a database.
Re: A dream of an ultimate OS (1995)
#156Oh, 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…
>Being an RTOS is only necessary if your application has a requirement for real-time response
Or, in other words, the operating system is not general purpose, because it is not suitable for these uses.
Do note these uses do include the likes of audio. If there's no way to guarantee latency, then a spike will surely eventually cause an overrun, which will be perceived as an audio hiccup. Sometimes, this is just an annoyance. On a live performance or in pro audio work, it can be fatal.
A good microkernel will allow mixed criticality tasks to share the system. A lot of recent research in the topic has brought SeL4 to this point.
Re: A dream of an ultimate OS (1995)
#157Earlier 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. 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..
I've never tried it, but isn't there a kernel for Linux that's been more optimized for desktop, but not quite real time?
Re: A dream of an ultimate OS (1995)
#158Earlier 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…
Audio. A great many people work with audio or want to work with audio, and Windows and OSX are lightyears ahead of Linux in terms of ease of use and overall quality. You'd think the PulseAudio fiasco would have improved the situation, but I believe the developers thought as you did, and so built a system that's woefully encumbered with latency. Jack improves the situation WRT latency, but it comes at the cost of an a…
> You'd think the PulseAudio fiasco would have improved the situation
PA is in rather good shape now & it has capabilities its predecessors didn't. But it's very hard to get people to update their notions about something once it sets in.
No matter how much Microsoft tries, Windows will always be 'insecure, virus-ridden', macOS will always be super stable, beautiful, no matter how much Apple screws up & Linux will always be unusable on the desktop no matter how many decades I'll spend enjoying it on the desktop at home and at work.
Sadly, it seems a person's mind tends to naturally lean conservative and it takes a herculean effort to regularly update one's preconceived notions.
Re: A dream of an ultimate OS (1995)
#159(1995)
Thanks!
Re: A dream of an ultimate OS (1995)
#160The perfect OS is no OS. An OS is just specialized software that provides services, but by providing those services and only those services, you're locked into that OS, and all those services whether you want them or not. And we have to do that because we don't want all our software to have to provide the basic services, but we don't really get that: we still have to provide all the libraries it needs, some of which…
What do you think of what we are building @ https://github.com/nanovms/nanos ? We are all about taking things away from the general purpose operating system and only focusing on what is needed to run a given service in prod.