Slashdot Mirror
A Motherboard That Doesn't Require An OS
An anonymous reader submits a link to this review of "motherboard that allows access to your multimedia devices via a special BIOS. No operating system required! Good for a home entertainment PC I guess." The review says that it will come bundled with a TV tuner card, too.
I'm guessing this means it's going to still crash, right?
Isn't an operating system a program that allows you to control your devices? This still does that, its just all contained in the ROM. Pretty neat, but still an OS. Surely not as bloated as MS media center. (note: I haven't actually tried media center, I'm just guessing)
"Wisdom is not a product of schooling but of the life-long attempt to acquire it." -Albert Einstein
The motherboard seems to be geared toward people wanted to create a multimedia center...I guess the real question is when does a collection of electronic parts become a computer and when is it a vcr, dvd, tivo, etc... :-)
Another layer of complexity! And for what? So the operating system you do install overrides it and uses its own routines to access the hardware.
BIOS = BASIC input output system.
Its just not meant to do more. Blurring the edges like this is just plain silly - a duplication of effort at best. Another thing to go wrong and more complexity where its not needed. Now we have bloatware in the HARDWARE too!!!!
These posts express my own personal views, not those of my employer
Features in the bios seems a perfect application for the Linux Bios project, which puts the linux kernel on the bios flash. Could a minimalist Linux distribution be made to do similar features (TV cards, ethernet) while still fitting in the bios memory?
Phoenix is attempting to make a transition from a bios to a trusted startup environment. This means that it may be hard to install operating systems that are not signed by Phoenix... for money. Thus, windows, Redhat EL, and other commercial operating systems will continue to work fine. This may make custom Linux installs next to impossible - without modchips. (can anyone say xbox?)
So it supports various hardware in the BIOS rather than the OS. But unless it's got the rest of an OS on it, you're either putting some OS on top of it (which can be simpler than other OSes, but the fact is that those OSes have already been written and removing support would be more work) or you can write code on the bare metal.
I'd hate to give up all the things that an OS supports for me, but I suppose that many of them (memory management, processes, libraries, windowing, keyboard, filesystem) aren't necessary on an embedded system. As long as there's a cross-compiler for it and a way to get that stuff on, you may well be able to work with just the BIOS.
Oh, and I tried to RTFA, which would presumably answer my question, but it's slashdotted, so I'm really aiming my question at the embedded software developers out there.
Say it with me: OpenFirmware
The fact that PC makers keep reinventing the wheel is annoying.
Javascript + Nintendo DSi = DSiCade
Why on earth would this feature be useful to ANYONE.
TV-Tuner functionality is questionable at best in a full-fledged OS. But in a BIOS?? Surly you must be joking!
I love that I can play my CDs and MP3s on my pc... while I work on other things. This monopolizes the whole system and turns it into an expensive DVD player. (Name one thing this can do that a cheap DVD player and a TV can't)
Not to mention that it's an embarrasing waste of resources. A 366mhz G3 could do this and more.
Oh, and hypothetically, I think it would be possible to hack something like this into a machine using openFirmware.
As an aside, it wouldn't be too difficult to write a small OS, deriving bits from Linux or BSD which could do the same thing and only take a few (under 5) seconds to boot (which would be quite plausable as you'd only need to load VERY few drivers). I could boot BeOS on my 750mhz athlon to the desktop in under 10 seconds.
-- If you try to fail and succeed, which have you done? - Uli's moose
Checkout MCA, it seems to do much of what you're asking for. Of course, nobody uses MCA these days - the parts are old, slow, and expensive,
I was using an OS'less motherboard in 1983. My Commodore 64 kicked butt!
Bottom line: "BIOS" is just a name. It used to stand for "Basic I/O Services", but now it means "whatever's convenient to have in onboard ROM so you don't have to read it off a disk." Words change.
why do you say it is a motherboard without an OS? of course it has an OS, it is on ROM like many other systems (ie: C64, Amstrad CPC...).
Hear hear! If hardware makers could agree to move the drivers down to the BIOS, that could be a significant move to tear down one of MSFT's strengths. Right now, they have a very wide range of supported hardware. There could be a significant industry reshuffle if the industry was able to achieve this. Then hardware vendors would only have to produce one driver (and it wouldn't necessarily have to be OSS - although it would be nice). They could spend more time improving their one driver, removing the bugs rather than supporting how many operating systems. MSFT would choke on this however because of their loss of competitive advantage - how much easier would it be to create new operating systems? Opps I mean window managers ;)
Same here (I'm a Linux software developer as well)... for example, how many Office-like suites are there on Linux? how many different X shells? (GNOME, KDE, etc.) Call it OSS, "freedom", "choice", or whatever... it's redundant effort beating to death things that have already been done 100 times before. (Many times, these are redundant and well known/understood problems already not needing yet-another-solution, they are just easy to put out and "gather fame" in the community for doing it yet-again.) Think what could be done if those projects were off solving problems other than these beaten-to-death-redundant problems.
I have seen very few projects use publicly available libraries and instead, rewrite libraries like linked-lists, trees, etc. typically because the developers can't "trust" the libraries out there because they didn't write it and aren't intimately familiar with the inner workings and claim that they have to rewrite so that they can be (what in effect is often like 1%) more efficient by having their own "custom" library to do the work.
Before having a universal driver in a BIOS on an add-in card would be useful, you would need specifications for interfacing with said universal driver so it could be used by the various OSes you mention.
Developing some sort of 'common driver api' can happen regardless of if the actual driver code lies on a BIOS or is loaded from an HD and give mostly the same results (you would just have to load the driver from a disk or the net).