Slashdot Mirror


Stallman Pushes For Free BIOS

An anonymous reader writes "One key area that Richard Stallman, GNU project founder, hopes to develop is an OSS-based BIOS. But his work has been hindered by PC manufacturers who haven't been receptive to the idea. Stallman told Builder AU that: 'we're looking for companies willing to cooperate with the community in this way.' On challenges facing developers today, Stallman said the worst was the proliferation of laws that explicitly ban free software for certain jobs."

5 of 419 comments (clear)

  1. Re:Bah by akaiONE · · Score: 5, Insightful

    One key factor to wanting to develop a free BIOS or "BIOS-like" solution to the startupsequence is that unlike what most endusers are aware of, the BIOS is a pain. Its slow, consumes a lot of bootup time and really isnt needed much longer. A free alternative would provide the user with shorter bootup times and more control over their own hardware. BIOS at its current state are just there for hardware detection/error handling and checking availability of an OS. The LinuxBIOS-project have reduced the bootup time consumed to just 5 seconds afaik. Thats really a lot less than the current BIOSes out there. Most of todays operating systems discards whatever the BIOS provide them and probe hardware directly anyways..

    --

    "-Who said sit down?!"
    -- S. Ballmer @ MSDC 2003.

  2. OpenBIOS, Open Standard by turgid · · Score: 5, Informative

    OpenBIOS is what you want, and unlike LinuxBIOS, it's implementing an Open Standard too, as used by IBM, Apple and Sun : IEEE 1275-1994 or Open Firmware.

  3. open bios by Anonymous Coward · · Score: 5, Insightful

    All you PC kiddies, who havnt used say, a sun box, dont know what you are missing.

    Whilst you may think that a bios is only usefull for tweeking memory timings to get a few more FPS from games, there are loads more things that it can do. For example on a sparc you can do memory, network and scsi tests at a low level before any OS gets to mess with the hardware. You can even program in forth at the OK prompt.
    The ability to boot off the network is now in place on most modern bioses, but that has come about as a direct result of having it on server class bioses for years.

    The fact that there is a full on TTY driver in the sun bios, means that you can plug the serial out into a another box and have full access to all aspects of the bios remotely. This may not seem much of a big deal to home users, but to a sysadmin it could save you hours of travel. Then there is the fact that you can change bios params. from within the OS.

    Modern bioses by just havnt kept pace with modern hardware. There is a monopoly by a few companies, all pushing out a similar product that has just the minimum functions to run the box.

    Whilst people may or may not love Stallman due to his abrasive nature youve got to admit that without him, there would be no linux, no GNU and a lot of us would be out of a job.

    So, when M$ mandates that all mother board manufacturers uses a bios like that on the Xbox, or their OS wont run on the box, who will they listen to ?? A load of linux "loonies" of a multi billion dollar corp ??

    Yes we have hacked Xbox to run linux, but its been patched and the linux hacks are getting harder and harder.

    Now under DMCA if you bypass a copy protection you are almost a terrorist. How many of our employers are going to run linux, if its illegal to bypass the bios to install it?

  4. Re:Link has little info about bios by johannesg · · Score: 5, Interesting
    of course hardware manufacturers don't like to release the details of the hardware.

    Why is that so natural? It used to be, when you bought a computer you got the entire schematic and a complete description of all the hardware registers. Up until the 16-bit generation you could buy that documentation for a small price - I know, I still have my "Amiga Hardware Reference Manual" gathering dust somewhere at home.

    But all of a sudden it is no longer possible. Why?

    I can at least tell you this: it isn't because hardware API's, all of a sudden, have become so unique, so incredibly advanced, that just telling people about register layout would cause vital secrets to escape the company. So having gotten that out of the way, why then?

    It could be argued that it is a hassle actually writing documentation. But this cannot be the problem: the documentation must still exist for those few people who write drivers today. So that isn't it either.

    Then it is possible that some sort of licensing scheme prohibits the companies from actually making the information public. Licensing from whom, I wonder? Who benefits from keeping this information locked up? I won't answer this one, but I bet you can guess...

  5. Re:Steps Against DRM by mwa · · Score: 5, Insightful
    Now go ahead and mark me a troll for having an unpopular opinion.

    Naa. It's not that you're a troll. It's just that you've fallen into the trap of contemporary thinking that most software is commercial software. That's simply not true. Most corporations have more lines of code for internal applications than MS Windows and the Linux kernel combined.

    The fact is that the vast majority of that code is pure expense. Accounts Payable, Accounts Receivable, Payroll, Inventory control, etc., applications have been re-written thousands of times by different companies. It's only fairly recently that commercial packages for these have become available for "enterprise" use. They are expensive and can require changes to business processes that make a particular company's operation less efficient overall. Either that or pony up for consulting hours or source licenses to make custom modifications that have to be retrofitted into new realeases as they become available.

    The bottom line is that if companies worked together to develop an open source suite of application components, each company's expenses would be lowered. Programmers would still be employed to compose the overall system so that it suits the companies management, organizational model and business processes. Programmers would still be employed to contribute to the open source process because it would be cheaper than recurring licensing costs and improve business effeciency.

    And that only addresses business-related applications. IT is a hotbed of opportunities for cost reduction through participation in open source projects. Any company with an IT organization faces the same challenges: How do we manage all these network devices, servers, workstations, etc.? How do we get notified of a problem before the business is impacted so we can prevent a disruption of income? You can buy into the OpenView/Tivoli/Unicenter/etc. mega-management framework/suite/nightmare (which may impose artificial and arbitrary restrictions on your systems and network infrastucture) and spend big $$ in administration and "management of the management", or you can employ open source developers to work on projects with other companies facing the same issues. The price tags of these suites plus support labor most likely exceeds the cost of paying the same number of staff a little bit more for development experience.

    Plus, I'll wager all my karma that any company running one (or more) of the big NMS suites has a variety of open source applications (MRTG, Nagios, NMIS, etc.) deployed as "point solutions" to fill gaps that it's just to painful to try to fill with the commercial products. We have one (unnamed) commercial performance management system that is licensed by the number of nodes monitored. The constant growth in our network combined with the traditional big-company purchasing bureaucracy means we never have enough licenses to monitor everything properly. So we either play the license shell game (moving licenses to nodes in the current hotspots) or we go look at NMIS for free.

    Slowly, management has come around to the fact that open source deployment is faster, if not as flashy, as far more expensive commercial applications and at least as effective. They came to that realization because when problems came up they saw with their own eyes that our open source tools had the answers and the commercial products didn't because the commercial products were not licensed to "see" the problem.

    Where they have not gone yet is understanding that since the open source applications are not as robust and flashy as they would like, they can fix that by letting staff participate on those projects to make them even more suitable to our environment. What have we got to lose? We spend enourmous labor hours on maintenance of servers and commercial software that doesn't quite meet our needs. How about we drop licensing costs, quite fighting applications (and vendors) to get them to do what we need, and spen