OSDev.org

Brendan wrote: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.

Brendan wrote: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.

• 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?

Jezze wrote: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.

MessiahAndrw wrote:

Brendan wrote: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.

MessiahAndrw wrote:

Brendan wrote: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 wrote: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?

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]

MessiahAndrw wrote: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]"

MessiahAndrw wrote: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.

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

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

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

embryo wrote: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.

b.zaar wrote: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.

b.zaar wrote:I'll give it a crack, anyone wanna fund my efforts for 12 months? =)

muazzam wrote:An OS should be really very, very Stable and flexible.

embryo wrote:

b.zaar wrote: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?

embryo wrote:

b.zaar wrote: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 :)

b.zaar wrote: 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.