It is painfully obvious that in order for any new operating system to garner a significant following, it needs good hardware support. The better this hardware support is (IE, the more devices 'work' with it because they have good device drivers for it) the more the general public believes this operating system is a "good one". Consequently, regardless of how innovative or original or even efficient a new operating system is at what it does, average users will perceive it as "broken" if it does not work on their hardware which their "good" operating system uses. Nevermind the reason for this is often because of proprietary hardware with closed "standards"; the potential users will bail ship.

So, we have a potential market which could be huge but, because of artificial limitations imposed by companies both by denying access to hardware specifications and, failing that, even refusing to make device drivers for their devices for non-"mainstream" operating systems, the OS market is subsequently dominated by the giant and a few others, and we all know whom this giant is. This creates a very artificial condition in which no one else is able to compete. Oh, sure, niche OSes have their place, but what really matters is who has control of the mass market, the commoners.

I'm sure the big friendly giant likes his place a whole lot and wishes nothing to change as he sees nothing wrong with this, but I sure hope the rest of you see this inherent problem as very troubling.

In the past, I have suggested there be some sort of universal device driver file format. This was met with criticism from some of the members here. Some of it was justified. However, I do believe those who were most adamantly opposed to the idea failed to realize the purpose of that previous discussion. The purpose was not to propose a hard-and-fast binding system, inflexible to change. The purpose was to propose an idea, an idea which may then be modified/mutated however others see fit as they added in their own ideas, an idea to evolve a solution to this barrier. Is it really that beneficial to destroy ideas of others in burning flames without proposing suggested alternatives of one's own? After all, constructive criticism is a great way to evolve beneficial changes, whereas outright cynicism only brings morale down and creates strife. One builds a community and the other tears it down.

In this vein of community effort, I propose a new idea. However, before I do so, I should make the meaning of this thread explicitly clear. Listen up! The purpose of this thread is for generation of brainstorming ideas on ways to solve the device driver oligopoly problem. In this manner, I expect less discussion on my own idea for this solution and more generation of new ideas, although there will be discussion on all ideas presented I don't have the power or authority to implement anything so far-reaching as a single person. This is why I reach out to a community effort, to garner support, to spark ideas, and to, hopefully, over time, band together enough people with enough talent so that through this community pool, something great may be accomplished.

I do not know how this will work. I do not know how to get it started. I do know there is a very talented pool of programmers on these fine boards. I do know there are some very good ideas in the minds of these same people. I hypothesize if I can get these people to concentrate on the same issue and to discuss it with each other that maybe, just maybe, they will discuss this with others/etc, until at some point in the future, the "right" person or people come across this to make it happen.

Now that the purpose is very clear, I should tell my idea. My next idea is for there to be a very simple "device driver interface" program. It could be considered a primitive OS by some. If this gets some initiative behind it, the goal would be for hardware manufacturers to see this interface as a real contender and for them to MAKE drivers for it themselves, solving the lack of drivers for alternative OSes problem. This simple layer will have ports to every known hardware machine--for example, x86 machines, Apple Macintoshes, Sun Sparcstations, etc... These are examples and not limits. The layer will export an API for each type of hardware device. When new features come out in hardware over time, more API functions may be added, increasing the version number of this device driver interface program. There need to never be deprecated functions. Deprecated or removed functions only lead to broken code somewhere and this is certainly never desired.

Next, an OS designer would build his/her OS on top of this layer. It serves as the base of the OS, with everything else as the developer sees fit. In addition, it in no way limits one of these OSes from accessing the hardware directly with traditional device drivers, if indeed this is desired. This will serve as a first block towards OS development. Then, once the OS is functional, some of the drivers from this layer could be converted to native drivers for speed increases, once information on them was obtained.

In this way, it would make the end users perceive hardware which works only slowly through this interface as obsolete, thereby encouraging hardware manufacturers to publicly release their hardware specifications for others to make better drivers for their own OSes. In the end, it would break the vicious cycles if all works well. In addition, a layer of portability would be introduced, allowing hardware to actually be more useful than it currently is.

Now, all are free to discuss my point, enhancing it, detracting from it, as they see fit. However, I'd really rather more ideas surface. It is imperative that we take back our computers from the giant and his minions.

After a quick reading of this, I noticed that it sounds similar to OpenFirmware (http://www.openfirmware.org/) and Intel's EFI (http://www.intel.com/technology/efi/). While I have no experience with EFI, OpenFirmware is pretty cool, and I'd love to see it on an x86 or ARM box

ShortCoder, it will never happen. A generic protocol will be too inflexible, or too clumsy because it would take too many parameters all over the place.

And, it's been tried by some of the very big companies. They tried to establish a generic driver binary interface, but didn't succeed.

Oligopoly; unless you have the resources to combat this you are doomed to failure. Some Sun Tzu:



You have stated here that this is a fight. You may want to take another approach...infiltration or some other form as direct attacks fail due to the enormity of resources the other side has. Until you have the resources to offer an attack, then you are in the building stage. Build without regard for attack. When you are sufficiently big, you can attack...and win.

I appreciate both the original suggestion and Smiddy's excellent response. I disagree with both parties:
Smiddy, notwithstanding SunZi's two millenia old military strategem, it is not necessary to be "big" in order to succeed. (you can search for General Vo, and Doctor Guevara.) It is only necessary to be SUPERIOR, in the minds of the END USERS. Superiority can be defined in any number of ways, I prefer FAST, EFFICIENT, ECONOMICAL, AND EASILY MODIFIED. Most operating systems offer NONE of these features.
What about a layer of drivers, i.e. the idea of the original post: HMM. Sorry, I don't think this idea will work. It will, if the manufacturers cooperate, (and in my experience with VIA and TRANSMETA, they will NOT cooperate, prefering even to go bankrupt, rather than release their precious information about accessing hardware), result in a MESS to sort out. Consider the simplest task of any kernel: accessing the hardware, responding to an interrupt, reading the timer, sending data to a video controller, offloading work to the DMA controller, etc. How is this NEW, EXTRA, unnecessary layer of protocols going to make it easier to create a ring zero operating system based on cooperative multitasking, for example? I acknowledge your frustration, and share your pain, M$ and UNIX clones dominate the horizon. It is very much the dark ages at present, with dragons and sleeping giants. We await the renaissance. Bogdan, wake up! There are dragons to slay! What we really need, is not a new layer of protocols, it is a CHART showing
1. the interrupts generated by, (and expecting acknowledgement from the cpu for,) each of the hardware components;
2. the internal registers of each device (DMA, video, audio, USB, wireless controllers);
3. illustrations of accessing EACH device, IDE, SATA, DVD, etc FROM protected mode, without using BIOS.
Such a chart, if available, would be, in my opinion, far more useful, than a variety of new protocols to be incorporated into any new operating system.

To Tom:
Do not worry, I am very much awake

Yes IMHO the only solution is to have clear and pertinent information about each every and every hardware device and standards... toghether with simple standard/reference implementation and/or developer guides.

Then each programmer can use his favourite programming language to make his own drivers as he/she find to be the best.

Any extra layer in between will not solve the problem... it will just move it somewhere else and make thing unnecessary slow and bloated and complicated...

Such an abomination would probably have to be interpreted to work on different hardware ...

I agree, but with the already available information is possible to make a good OS , most hobby OS still don´t implement all the available standards
because this is a lot of work, and the main problem of linux is not the lack
of drivers but the old design and the bloatware.
I think that instead of define another universal driver interface it would be better to recompile information , something like RBIL but for hardware and with better explanations. Once the docs are available coding the drivers is pretty easy, is the easy thing to code in a OS, is harder to debug but most bugs are due to the bad documentation, the drivers itselfs are very simple programs.

Oh, I see, like ENRON and others who falsely claimed their appearance and so were, in the minds of the END USER, superior? I think rhetoric is an important facet too but your claims have to be true in order to be successful in the long run.

I have to disagree with your assessment though. I would specify that most commercially available desk-top operating systems do not sport those features. There are many operating systems obscurely available that are all of those combined. But they wouldn’t be classified as a desk-top operating system, since, as the author of this thread points out, don’t have the device drivers to be competitive.