OSDev.org

Hi OSDev world!,
I am writing an operating system for a research project, and need to know of a problem with today's operating systems. I tried Google and I found this article but that article is from the 70s (before I was born) everything else I got were problems related to the front-facing stuff.
So OSDev community, is there any problems with modern OSes? Not problems with hobby OSes like what you write but ones with regular OSes like Windows, Mac OS X, Linux, and *BSD.

They fail to utilize all hardware (in a single PC that it is installed on) at 100% efficiency.

- Monk

tjmonk15 wrote:They fail to utilize all hardware (in a single PC that it is installed on) at 100% efficiency.

That's silly. First of all, any engineer will tell you that things don't have to be perfect, they need to be good enough. Secondly, "100% efficiency" is not something that is achievable for several reasons: different designs yield better solutions to different problems so you need to make trade-offs, it's impossible to make predictions necessary for perfect scheduling, etc.

neel wrote:I am writing an operating system for a research project, and need to know of a problem with today's operating systems.

There are many areas you could focus on. Here are a few areas of current interest:

• Security. You could research anything ranging from writing less vulnerable systems (e.g., one approach would be to use safer languages) to solving the man-in-the-middle attack problem without using hacks like certificates.
• Privacy. How to make network requests in such a way that not even the request processor knows what it is you requested (e.g., homomorphic encryption, private information retrieval, etc.).
• Scalability. What is a good way of distributing your workload across a number of processing units (regardless of whether we're talking about a single or multiple systems)? To give an example of current trends, a lot of people are experimenting with the MapReduce model of parallel computation.
• Virtualization. Basically, how do you separate the code from the underlying machine and how can you use this to your advantage (portability, migration, etc.)?

Love4Boobies wrote:
There are many areas you could focus on. Here are a few areas of current interest:

• Security. You could research anything ranging from writing less vulnerable systems (e.g., one approach would be to use safer languages) to solving the man-in-the-middle attack problem without using hacks like certificates.
• Privacy. How to make network requests in such a way that not even the request processor knows what it is you requested (e.g., homomorphic encryption, private information retrieval, etc.).
• Scalability. What is a good way of distributing your workload across a number of processing units (regardless of whether we're talking about a single or multiple systems)? To give an example of current trends, a lot of people are experimenting with the MapReduce model of parallel computation.
• Virtualization. Basically, how do you separate the code from the underlying machine and how can you use this to your advantage (portability, migration, etc.)?

I'd add Performance to that list.
The main gripe I have with most OS's is their abysmal performance with regards to I/O. Doing heavy disk I/O on for example Windows can bring the UI to a crawl, which I find unacceptable.

Love4Boobies wrote:

tjmonk15 wrote:They fail to utilize all hardware (in a single PC that it is installed on) at 100% efficiency.

That's silly. First of all, any engineer will tell you that things don't have to be perfect, they need to be good enough. Secondly, "100% efficiency" is not something that is achievable for several reasons: different designs yield better solutions to different problems so you need to make trade-offs, it's impossible to make predictions necessary for perfect scheduling, etc.

Not only that, some designers have as a rule of thumb that any resource being routinely utilised at more than 70% gets duplicated. The idea being greater utilisation means longer queues which means longer response times. I honestly don't have the queueing theory background to give the what-ifs and why-nots but it seems to be an intuitively acceptable rule of thumb.

Edit:
I have figured out that the response time grows exponentially, not linearly, with utilisation which is why high utilisation should be considered bad.
Here's a PDF that I found on the net that gives a Reader's Digest style overview of what we should know:
http://www.treewhimsy.com/TECPB/Article ... sights.pdf
Experts reading this should jump in and criticise what I'm writing as I'm no expert as I wrote above.

one problem of window : can't write binaries executable while they are executing, which make various kind of problem for updating the system, deleting viruses, malware etc and lot of proprietary things that are not always very trivial to figure out, fortunatly they made big effort to document everything very nicely, but api and global concept of the system can be fairly complex and can make software development bit longer if you are not used to ms specific things, more than other system i think

one problem of linux/bsd : it's mostly polling based, which give some performance issues, if a 'thing' has low activity, you still waste lot of time to poll device or event stack for nothing, if it has high activity, you're most likely to have a slow rate of polling specially if the loop from which you do the poll is too busy (try running an X11 on a slow config, like let say an amiga 1200, and see how it sux very bad at managing event polling) , the whole select/polling approach is not great for real time performance and reactivity, lack of solid binary exe compatibility between distribution and versions is also a major inconvenient imo

one problem of bsd : it has a very simple code oriented policy, which make it great for security, and maintaining it, the code is very straight forward and readable, but it tend to go too much toward 'generic code to do everything in a simple manner' and sometime it miss a bit to really get the best of each hardware like linux, linux have many quirks and patch for every hardware, which from what i heard make bsd rather slower than linux for smp/multi tasking and other things, because the philosophy 'smaller/simpler code = faster' is not that much true anymore nowdays, that would need to be checked, but it's what i heard from people who works in data centers, and also bsd used to lack a lot of modern driver and can fail on many hardware, not sure if that's still true though

macos: much too specific without giving a clear advantage in the api, the macos policy always have been to provide user a pre selection of everything, it can be a good thing or a bad thing in itself, but it always limit the range of uses you can have from advanced end user perspective, you depend a lot on what the mac designer want the end user to be able to do, if that in the design , it will be great and easy and work fine, if not you'll have hard time to make something more specific out of it and are not even supposed to, and it's too expansive for what it actually does

h0bby1 wrote:one problem of window : can't write binaries executable while they are executing, which make various kind of problem for updating the system, deleting viruses, malware etc and lot of proprietary things that are not always very trivial to figure out, fortunatly they made big effort to document everything very nicely, but api and global concept of the system can be fairly complex and can make software development bit longer if you are not used to ms specific things, more than other system i think

The cause of this "can't write executable while they are executing" is the delay loading Windows implements to improve application startup performance.
As for application development itself, unless you want to tie yourself to Windows, there's no need to use Microsoft-specific functions.

halofreak1990 wrote:

h0bby1 wrote:one problem of window : can't write binaries executable while they are executing, which make various kind of problem for updating the system, deleting viruses, malware etc and lot of proprietary things that are not always very trivial to figure out, fortunatly they made big effort to document everything very nicely, but api and global concept of the system can be fairly complex and can make software development bit longer if you are not used to ms specific things, more than other system i think

The cause of this "can't write executable while they are executing" is the delay loading Windows implements to improve application startup performance.
As for application development itself, unless you want to tie yourself to Windows, there's no need to use Microsoft-specific functions.

well personally i'd rather have application that load a little bit slower, what kind of gain are we talking about here, something about fraction of seconds, i don't think i ever seen an application taking more than even 5 sec to startup under any os ever, so the performance gain is really thin in absolute time save, and it's still very annoying feature, i guess it can have the advantage that you can't delete system32 directory by accident

well if they make function for that you can't use them, they should not make them at all, i'm a bit exagerating, as they can still be usefull or life saver in some case i guess, but in most other case you'll just have 3go of useless dll and com object in the registry that you will never really use, who will slow down os loading and many thing and bloat the whole system up, and it would still be better to have a simpler and more intuitive kind of api and functionalities, it's like their security center, it's so annoying and bothering to configure that everyone disable it and it's useless, but also windows is much oriented toward end user easyness of use, and easy bug tracking , so it make it a bit harder on the side of developers to use lot of abstract classes and interfaces to have robust application context, if you want to do application for windows, you'll have to be a minimum tied to it anyway, and i don't think there are other os who provide such a rich application context either, but a middle ground between the two (unix with C all is file, and windows c++/com all is object) could be made

halofreak1990 wrote:The cause of this "can't write executable while they are executing" is the delay loading Windows implements to improve application startup performance.

For all I know it is not. This is a "feature" of the file open/locking semantics in the Win32 API. If you remove delay loading, the feature will stay there because it is relied upon by the legacy applications.
Because it is so part the API, it is ingrained into the filesystem layer as well.

from what i understood it's more due to exe sections being memory mapped from the exe file no ?

but microsoft application context is really complex, if you ever made com component using ATL, or direct show components, you can see how many things are tied together between the dll runtime, containing information that are specific to the module, and the atl implementation tweak with those thing that are dealt with in the runtime, the whole application context with dll/shared memory/com dll is quite something, but most of the thing it more look super obscure and complex for not much, but if you want to really program good quality advanced windows native application, things that have multiple dialog windows, interface with com component, it can quickly become a big head ache with their whole application model for that it works fine on all plateform

but it got much better starting with visual studio 2005, all the thing is handled in a much better way, but with vc6.0 it was very often a big headache because the development environment was not handling everything totally right all the time, and there was many way to break things

sometime it really looks like something from another planet, i'm pretty sure microsoft developers are not humans :/

h0bby1 wrote:one problem of linux/bsd : it's mostly polling based, which give some performance issues, if a 'thing' has low activity, you still waste lot of time to poll device or event stack for nothing, if it has high activity, you're most likely to have a slow rate of polling specially if the loop from which you do the poll is too busy (try running an X11 on a slow config, like let say an amiga 1200, and see how it sux very bad at managing event polling) , the whole select/polling approach is not great for real time performance and reactivity,

[Citation needed].

h0bby1 wrote:one problem of bsd : it has a very simple code oriented policy, which make it great for security, and maintaining it, the code is very straight forward and readable, but it tend to go too much toward 'generic code to do everything in a simple manner' and sometime it miss a bit to really get the best of each hardware like linux, linux have many quirks and patch for every hardware, which from what i heard make bsd rather slower than linux for smp/multi tasking and other things, because the philosophy 'smaller/simpler code = faster' is not that much true anymore nowdays, that would need to be checked, but it's what i heard from people who works in data centers, and also bsd used to lack a lot of modern driver and can fail on many hardware, not sure if that's still true though

There are some problems with your statement:

• No data to backup your claim about Linux being faster than "BSD"
• What do you mean with "BSD"? FreeBSD, OpenBSD, NetBSD, DragonFlyBSD, etc.? They all use different kernels with different performance characteristics.
• The availability of drivers depend on what you mean with "BSD".

I agree with the "smaller/simpler code does not imply faster code" sentiment though, but "small code base" does not automatically mean "simple code base".

DennisCGc wrote:

h0bby1 wrote:one problem of linux/bsd : it's mostly polling based, which give some performance issues, if a 'thing' has low activity, you still waste lot of time to poll device or event stack for nothing, if it has high activity, you're most likely to have a slow rate of polling specially if the loop from which you do the poll is too busy (try running an X11 on a slow config, like let say an amiga 1200, and see how it sux very bad at managing event polling) , the whole select/polling approach is not great for real time performance and reactivity,

[Citation needed].

h0bby1 wrote:one problem of bsd : it has a very simple code oriented policy, which make it great for security, and maintaining it, the code is very straight forward and readable, but it tend to go too much toward 'generic code to do everything in a simple manner' and sometime it miss a bit to really get the best of each hardware like linux, linux have many quirks and patch for every hardware, which from what i heard make bsd rather slower than linux for smp/multi tasking and other things, because the philosophy 'smaller/simpler code = faster' is not that much true anymore nowdays, that would need to be checked, but it's what i heard from people who works in data centers, and also bsd used to lack a lot of modern driver and can fail on many hardware, not sure if that's still true though

There are some problems with your statement:

• No data to backup your claim about Linux being faster than "BSD"
• What do you mean with "BSD"? FreeBSD, OpenBSD, NetBSD, DragonFlyBSD, etc.? They all use different kernels with different performance characteristics.
• The availability of drivers depend on what you mean with "BSD".

I agree with the "smaller/simpler code does not imply faster code" sentiment though, but "small code base" does not automatically mean "simple code base".

there are data that show linux scale better on smp things than bsd i can look it up, i saw this from people who work in data center who were discussing that, but maybe it's just some versions of bsd, i said it need to be checked out for having hint on this, i'm sure there are data because i have seen very detailed benchmark on this

but only looking bsd kernel code , like the usb drivers, if a device might need more delay at some point they put the delay by default for all device, it's not all the time big deal , and it make generic drivers that handle everything without problem with single code, but it's not the most optimized

for drivers, on bsd they still use oss for audio no ? this driver is a bit simplistic it's ok for simple audio playback, but linux has alsa/jack, and not sure how much of audio hardware like usb box or rack can bsd support for ex, same for video, not sure how much bsd can support for advanced video card feature like avivo or other thing on nvidia cards

linux still try to incoporate things, and it's becoming a industrial standard, even for desktop, and there are still large driver base that grow up on linux, and they have a whole system of quircks to have specific code path for all hardware manufacturer for many things, either disk or usb or other drivers, they always try to optimize each code path for each hardware the best with specific code, which make also the code unreadable and the exact behavior harder to predict

One problem with many commercial and even open source kernels is that they lack unit tests . Once the code becomes huge , it is better to have a suite for testing the sanity of the code. Sad fact is the everyone wants to do only the "fun stuff !" with no focus on quality.

--Thomas

h0bby1 wrote:for drivers, on bsd they still use oss for audio no ? this driver is a bit simplistic it's ok for simple audio playback, but linux has alsa/jack, and not sure how much of audio hardware like usb box or rack can bsd support for ex, same for video, not sure how much bsd can support for advanced video card feature like avivo or other thing on nvidia cards

OSS can refer to both an API and an implementation, OpenBSD partially implemented the API as a wrapper around the original sun audio API, as libossaudio(3). FreeBSD and NetBSD may do something similar, or use the 4Front OSSv4 implementation. Sun Audio was the original sound API for BSD Unix, an read(2)/write(2)/ioctl(2) + /dev/audio API which used a simple format called Au.. that was the de facto interface for a long time, and I believe the other BSD's still maintain some support for it today.

OpenBSD now uses it's own audio API instead called sndio(7) and includes a userland mixer called sndiod(8). There are kernel drivers for several audio chipsets, including devices supporting Intel HDA specification.

GPU support is actually in pretty good shape now as well, OpenBSD and FreeBSD have support for Intel and AMD/ATI KMS and include a newer Mesa. FreeBSD is even in a unique situation where it has vendor support in the form of a proprietary driver from Nvidia, this is on par with the Windows/Linux and Solaris drivers, I believe.

I think Avivio is UVD? If so, there is an open source implementation now which can eventually be ported to BSD and exposed using the VDPAU API. It's the same API used on Linux and FreeBSD in Nvidia's proprietary drivers.

You don't know what you're talking about, but it's easy to find fault in a system you've never used, h0bby1.

Thomas wrote:One problem with many commercial and even open source kernels is that they lack unit tests . Once the code becomes huge , it is better to have a suite for testing the sanity of the code.

It's nice to have unit test suites, but you cannot unit-test everything. Linux kernel uses QEMU nodes emulating different architectures to do "smoke-boot-testing", and they have large enough developer base to spot and fix the problems early on.

Windows is a bit more messy, but they have the largest installed base and the release cycles are very slow, so they can release initially "mostly working" version and afford to patch it up for several years after release. They also do have tests for certain subsystems internally.