What would you actually want in an operating system?

[Jezze]

The problem with doing stuff during inactivity is that you have no idea when the inactivity period will stop. If you are busy doing some kernel work while the user tries to use his system it could result in a sluggish experience becuase the user notices for example that starting his favourite program sometimes is really quick and sometimes takes a lot longer. This causes frustration, if it on the other hand always takes nearly the same time he is prepared for that. Also the problem with prefetching stuff is that these things might not even be used and then you have to discard it, perhaps even swap it out meaning you have wasted tons of cycles for nothing. You might get lucky, you might not. It gets especially terrible during long times of inactivity, I notice this on Linux where after my system has been idle for a while and I return its like all my programs need a lot of time just getting back to where they wore, sometimes even to the extent they crash.

[AndrewAPrice]

Yes; the end user could explicitly control things like pre-fetching, indexing, de-fragmenting, etc; if you really want a system where users do work for the computer (instead of having a system where the computer does work for the user).

Alternately, the OS could control it - e.g. having a much lower threshold for "is it worth doing?" when running from battery.

You don't have to make it complex, maybe an option in the Operating System's control panel labelled: "Perform maintenance tasks in the background? [Yes/No/Advanced]"

Yes enables them, no disables them. "Advanced" allows powerusers to configure exactly what is allowed to run in the background (indexing, de-fragmenting, network discovery, etc.) In your task manager/taskbar/ps applications that are allowed to run in the background should be a different colour, so the user always explicitly knows what could potentially be using processor cycles - with some mechanism to change this.

These things all mostly seems to be poor software update mechanisms (e.g. no efficient/global system for updates; combined with applications that do "check for update during boot" instead of "check for update when run"). It wouldn't be too hard to find a better way of handling software updates.

I agree with you that there is a better way to handle updates - but they don't do that. There are always ways to disable the updater, but it requires poweruser knowledge.

I like the idea of an operating system having a permission system for applications - similar to what you see on mobile devices but more thorough -
"Do you want to give this application permission to..."

• Run in the background?
• Play audio?
• Access your microphone?
• Access your webcam?
• Access the network?
• Host a network server?
• Access user files? [No/Read Only/Read & Write]
• Access system files? [No/Read Only/Read & Write]
• Directly access hardware?
• Launch child processes?
• Run in full screen mode?
• Access your modem? [No/Dial Only/Answer Only/Dial & Answer]
• Shutdown, sleep, and reboot your computer?

Applications can have a manifest of requested permissions, that popup either during install, on first run, or when the user configures the application.

[Brendan]

Hi,

The problem with doing stuff during inactivity is that you have no idea when the inactivity period will stop. If you are busy doing some kernel work while the user tries to use his system it could result in a sluggish experience becuase the user notices for example that starting his favourite program sometimes is really quick and sometimes takes a lot longer. This causes frustration, if it on the other hand always takes nearly the same time he is prepared for that. Also the problem with prefetching stuff is that these things might not even be used and then you have to discard it, perhaps even swap it out meaning you have wasted tons of cycles for nothing. You might get lucky, you might not. It gets especially terrible during long times of inactivity, I notice this on Linux where after my system has been idle for a while and I return its like all my programs need a lot of time just getting back to where they wore, sometimes even to the extent they crash.

For CPU time; with a decent thread priority scheme (which Linux mostly lacks) any background stuff would be pre-empted "instantly" (e.g. probably faster than waking a CPU out of a sleep state). For hard disk transfers; with a decent IO priority scheme, the time it'd take depends on the size of the transfer. E.g. if low priority/background stuff uses small single sector reads/writes (and not more lengthy multi-sector reads/writes) it should be able to switch to more important disk IO fast enough to not make any noticeable difference.

For memory; the idea would be to get the "most likely to be used" data into RAM (and the "least likely to be used" data out of RAM, including any writes that were buffered/postponed) while you can. Programs that are already running would be at the top of the "most likely to be used" list; so it shouldn't hurt running programs at all (and may improve their performance instead).

Of course immediately after boot you're going to have lots of free RAM ("cold cache" conditions) and everything that's "most likely to be used" will still be on disk. There's no good excuse for failing to (e.g.) pre-fetch my web browser's files into VFS cache while I'm getting my morning coffee.


Cheers,

Brendan

[Brendan]

Hi,

Yes; the end user could explicitly control things like pre-fetching, indexing, de-fragmenting, etc; if you really want a system where users do work for the computer (instead of having a system where the computer does work for the user).

Alternately, the OS could control it - e.g. having a much lower threshold for "is it worth doing?" when running from battery.

You don't have to make it complex, maybe an option in the Operating System's control panel labelled: "Perform maintenance tasks in the background? [Yes/No/Advanced]"

Yes enables them, no disables them. "Advanced" allows powerusers to configure exactly what is allowed to run in the background (indexing, de-fragmenting, network discovery, etc.) In your task manager/taskbar/ps applications that are allowed to run in the background should be a different colour, so the user always explicitly knows what could potentially be using processor cycles - with some mechanism to change this.

For system level maintenance tasks (e.g. indexing, de-fragmenting, network discovery, etc) I'd rather just do the right thing automatically (e.g. using heuristics to determine if it's worth it or not). For applications, excluding bad updaters, I'm not sure there's a problem that needs solving. Bad updaters are a major problem, but that can be solved in other ways.

These things all mostly seems to be poor software update mechanisms (e.g. no efficient/global system for updates; combined with applications that do "check for update during boot" instead of "check for update when run"). It wouldn't be too hard to find a better way of handling software updates.

I agree with you that there is a better way to handle updates - but they don't do that. There are always ways to disable the updater, but it requires poweruser knowledge.

I like the idea of an operating system having a permission system for applications - similar to what you see on mobile devices but more thorough -
"Do you want to give this application permission to..."

• Run in the background?
• Play audio?
• Access your microphone?
• Access your webcam?
• Access the network?
• Host a network server?
• Access user files? [No/Read Only/Read & Write]
• Access system files? [No/Read Only/Read & Write]
• Directly access hardware?
• Launch child processes?
• Run in full screen mode?
• Access your modem? [No/Dial Only/Answer Only/Dial & Answer]
• Shutdown, sleep, and reboot your computer?

Applications can have a manifest of requested permissions, that popup either during install, on first run, or when the user configures the application.

Do you remember when UAC was added to Windows? The local computer/IT shop here disables UAC on all computers running Vista because it annoyed people. It was a simple dialog box that asked one question ("Do you want to allow the following program to make changes to this computer?"). You're proposing a "13 or more checkboxes" thing?


Cheers,

Brendan

[AndrewAPrice]

Do you remember when UAC was added to Windows? The local computer/IT shop here disables UAC on all computers running Vista because it annoyed people. It was a simple dialog box that asked one question ("Do you want to allow the following program to make changes to this computer?"). You're proposing a "13 or more checkboxes" thing?

UAC pisses me off mostly because I have a few programs that need administrator permission, or when I want to copy a file in C:\Program Files\ and it pops up each time. That's not what I'm proposing.

During installation, the last step of your package manager/wizard will say:

Code: Select all

This application requests the following permissions:
* Run in it background. [x]
* Read your user files. [x]
* Access the network.   [x]
[Deny All] [Allow All] [Next]

You'll only ever see this once per application, unless you want to modify them at a later date.

[Combuster]

The thing with UAC is that
- Users don't want to be nagged.
- The system wasn't designed to prevent naggng.
- Nagging happens regardless
- Everyone fixes this by disabling security.

You obviously can't fix 1. You still want to prevent 4. Therefore you have to make it easy to prevent nagging (point 2), and make sure you have a legitimate excuse to blame applications if they do (point 3).

Also, I'd rather have an appstore-based system where every requested permission has to be properly argumented, and even then be disabled by default (screw you facebook for android, no microphone for you even if you might want to use it). Instead, applications can refer to system applications and dialogs for tasks that would require a permission otherwise.

Such as, an application is denied access to the filesystem by default. Instead it should use the file chooser app to let an user decide what to open, and as they do so, they implicitly grant permission for that one specific file or folder. You can't tamper with the file app and it will always look the same, a boon for user experience, and you got rid of the dialog "is this app allowed to read files" without nagging users into sacrificing security.

[embryo]

You don't have to make it complex, maybe an option in the Operating System's control panel labelled: "Perform maintenance tasks in the background? [Yes/No/Advanced]"

As it was already said all we need from an OS is do-what-i-mean. After some narrowing some participants have agreed to the i-want-to-control-it variant. But still there are some voices with it-should-be-flexible song. Now we can imagine fully controllable system with it's UI designed to allow very flexible system tuning. And it's really can be implemented. But there is one problem - we need a lot of time to complete such really flexible and controllable OS. Apple has tried such path (and Google has copied it), but we still see no viable solution - the OS is not fully controllable and the control is not flexible.

Can anybody here write new iOS or Android to add some flexibility and controllability? Both systems are not very complex, but the time required for such task is definitely tremendous. But somebody can sketch up some flexible system management tooling and here I see an opportunity for osdevers.

[bluemoon]

What if I want everything in the background to stop, so that the application I have in focus (my web browser, or a video game) can have all resources dedicated to it? If it's out of sight, it should be out of mind, unless we explicitly tell it otherwise.

If a web browser take all the computer resource, you may as well consider replace the browser or the computer, instead of the OS.
Computer is meant to do work it is ordered even without human watching/controlling it.
If it is out of sight, it should be out of mind, but it should still doing works.

[b.zaar]

all we need from an OS is do-what-i-mean.

I'd like to see this all the way down to the system calls. What I mean by this is that a programmer requesting a device like the frame buffer (cos it's what I'm currently working on =) should not have to look up a device specific code to set a mode. This could be as simple to look up as the old BIOS values or complex like scanning the vbe available modes one by one to find a mode you can work with. The interface to a service or device should feel natural like it's a normal C/C++/BASIC/PASCAL/JavaScript library function.

After some narrowing some participants have agreed to the i-want-to-control-it variant.

This should be available to any OS with some security checks just because we might all like the way a system works but not all like the same boot up manager, the same windows manager, shell or scripts and utilities.

But still there are some voices with it-should-be-flexible song.

This is close enough to the part I'd include as i-want-control.

Now we can imagine fully controllable system with it's UI designed to allow very flexible system tuning. And it's really can be implemented. But there is one problem - we need a lot of time to complete such really flexible and controllable OS.
...
Can anybody here write new iOS or Android to add some flexibility and controllability? Both systems are not very complex, but the time required for such task is definitely tremendous. But somebody can sketch up some flexible system management tooling and here I see an opportunity for osdevers.

I'll give it a crack, anyone wanna fund my efforts for 12 months? =)

[embryo]

a programmer requesting a device like the frame buffer (cos it's what I'm currently working on =) should not have to look up a device specific code to set a mode.

Under Windows there is API to do this without low level knowledge. But is it enough?

I'll give it a crack, anyone wanna fund my efforts for 12 months? =)

I can't fund you, but I will really appreciate your efforts

[Muazzam]

An OS should be really very, very Stable and flexible.

[b.zaar]

An OS should be really very, very Stable and flexible.

Only a real programmer could guarantee that though...

[b.zaar]

a programmer requesting a device like the frame buffer (cos it's what I'm currently working on =) should not have to look up a device specific code to set a mode.

Under Windows there is API to do this without low level knowledge. But is it enough?

I think DirectX can do this but it's not part of the core win32/64 api. I'd like to include it at the lowest level in the driver so apps can access a device as raw as possible or apply libraries like OpenGL/SDL on top. Sometimes this means the app controls the whole screen like a full screen DirectX app or sometimes it's run in a window but with the desired resolution/bpp combination independent of the current screen mode of the windows server like a windowed SDL app.

I'll give it a crack, anyone wanna fund my efforts for 12 months? =)

I can't fund you, but I will really appreciate your efforts :)

Thank you, so what's your number 1 must have feature?

[JAAman]

I think DirectX can do this but it's not part of the core win32/64 api. I'd like to include it at the lowest level in the driver so apps can access a device as raw as possible or apply libraries like OpenGL/SDL on top. Sometimes this means the app controls the whole screen like a full screen DirectX app or sometimes it's run in a window but with the desired resolution/bpp combination independent of the current screen mode of the windows server like a windowed SDL app.

wrong...
"DirectX" is part of the core winAPI (has been since "DirectX10" with windows vista -- that change is part of why winXP can't use D3D10)

and DirectX can do all the things you just mentioned here (including both full screen and windowed apps running using resolutions and bpp settings that are different from, and completely independent of, current screen settings)

[SpyderTL]

I stumbled across a Mono project called CSharp REPL, which is really similar to what I would want from an OS. (Natively, of course. )

http://www.mono-project.com/docs/tools+ ... ools/repl/





These are the windowed version. There is also a command line version...

Anyone used this?

Anyone (else) think this would be an awesome native shell for an Object Oriented OS?