Slashdot Mirror
Stallman Calls For Action on Free BIOS
Dolda2000 writes "Seeking to achieve 100% software freedom, RMS is now calling for action for a free BIOS. From the article: "The most uncooperative company is Intel, which has started a sham 'open source' BIOS project. The software consists of all the unimportant parts of of a BIOS, minus the hard parts. It won't run, and doesn't bring us any closer to a BIOS that does. It is just a distraction. By contrast, AMD cooperates pretty well." For reference, there are currently two projects for a free BIOS that I know of: LinuxBIOS and OpenBIOS."
It makes sense, to me anyways, to have an open bios. How can one claim to run a free system when their very boot process is hidden and secretive?
Sounds like bias in bios
http://www.sandstorming.com
I can't really imagine a free piece of software that will undoubtedly render some people's motherboards totally unusable.
Admittedly, not many people actually screw up their motherboards today because of company-supplied BIOS updates, but in my opinion the most likely reason for that is that most people don't update their motherboard's BIOS.
I think this is a necessary problem to solve for a host of reasons (the most pressing in my mind being removing "Trusted Computing Initiatives" or DRM) but I can't imagine who might be willing to distribute such a thing because of the liability concerns.
I'm a big tall mofo.
Does Anyone know what Intel gets out of not opening it up? Are there any IP issues?
Evolution or ID?
to create "free" BIOS help Intel? Would gain market share? Would it somehow end up with a new revenue stream that it cannot access with its current marketing and other strategies? What can it gain by winning over a bunch of geeks?
This is not flame bait. I am just trying to understand why corporations like Intel would cooperate.
All I can say is stop whining and move on.
BP http://www.card-central.com
That'll be great to get a really good Open Source BIOS - we'll have new features and capabilities not ever thought of before: who knows, maybe we'll see a Nintendo Emulator for our POST...
An open-source BIOS is something I'd really appreciate having, especially with the big corporations moving towards their big 'Trusted Computing' platform. It's MY hardware and I'll runn whatever the hell I want on it, not what some mega-corporate conglomerate decides I should.
- Unzip the self-extracting archive.
- Find the disk image included therein, and burn it to CD-RW as an ElTorito bootable CD. (With nothing in the data track.)
- Boot from CD and flash BIOS.
- Erase CD-RW.
- Don't Profit!
I'd love to have an alternative to the BIOS which is open source, or free software, or both. That way I can finally claim to have a computer completely free of closed, proprietary software. And maybe have a chance of configuring the hardware a little better as well. Dell's BIOS is painfully short on options.How am I supposed to fit a pithy, relevant quote into 120 characters?
You can help our campaign by buying AMD CPU chips and not buying Intel, and by publishing statements about what you're doing. Likewise, buy motherboards that support free BIOS.
According to the FreeBIOS website, Acer , Via and SiS support it . And it will probably see a LOT of Bochs in testing too. So I might opt for an Acer laptopt finally (it's cheap too)Quidquid latine dictum sit, altum videtur
Apple uses open firmware for their boot mechanism, which is already pretty "open"
The problem with a motherboard BIOS is that it's tailored to the motherboard. Could the open source fratenity actually produce a workable product across a large number of motherboards? Would they produce something that works properly on all of them, instead of having modules that have been got to a state where they're good enough for the hacker creating them, but not Joe average on the street.
To be honest, if it's just a BIOS clone, I won't be interested anyway - wake me up when someone recreates OpenFirmware for the PC.
I think that an open BIOS could really change things. The bios is something that hasn't seen true development or innovation since it's inception. Many products have been used by the masses, and not improved, untill FOSS was there to take it's job, and then they got on the ball, and they started competing with each other. This benefits everybody in the end. Besides, anybody who has ever done any OS or bootstrapping development, knows that there are way to many peculiar BIOSs out there, that have to be planned for. They load your code at different locations, they set the registers to different values, and your left wasting those first 512 bytes, just cleaning up what the bios did.
LinuxBIOS is not a BIOS, it's a non-standard firmware interface.
This is pretty much OK for embedded use, but for anything where you need standard BIOS functionality, it's useless. Worse, the name "LinuxBIOS" implies that it is BIOS functionality, which causes people to try to use it in inappropriate situations.
It might just be me being naïve, but would Intel really go to such lengths to create a "distraction"? I find it a bit paranoid to think they'd start a project with the sole intention of just slowing down the progress for an open sourced BIOS.
"Anybody who tells me I can't use a program because it's not open source, go suck on rms. I'm not interested. 99% of that I run tends to be open source, but that's _my_ choice, dammit." (Linus Torvalds, October 26, 2004)
Come on. Intel only started their project in the past couple years. If you can't finish Hurd on your own, don't gripe about other projects which aren't moving fast enough for you. Or, hey, maybe you could look in the other kernels... you know, the Open Source kernels which aren't owned by the FSF. They seem to be able to do the job. They've been running all this time, while Hurd hasn't.
Sure, you're going to say Hurd runs. Well, where's the GNU/GNU Distro?
[
This makes it even more critical that we get free software BIOSes, and soon!
How am I supposed to fit a pithy, relevant quote into 120 characters?
The problem with a statement like "We need a Free BIOS" is exactly what you mean by "BIOS".
There are two extremes to the schools of thought on this.
The first is the minimalist: The BIOS is just enough code to put the machine into a state where it can load the real OS, and once the real OS is loaded the BIOS is no longer relevant. At a minimum this code would just set up the basics of the machine, and then load some section of the hard disk into memory and jump to it.
The second is the maximalist: The BIOS should provide abstract access to all hardware so that the OS does not have to have drivers. The BIOS would provide routines for the disk controller, video, human interface systems (mouse/keyboard/etc.), memory control, system control, you name it. The OS would never get its hands dirty accessing real hardware.
Both of these approaches have problems. The Minimalist approach means the OS has to support all hardware - which is the lament those of us who don't run Microsoft operating systems will sometimes have. If your OS does not know about your shiny new FooCard then you are out of luck. In the ideal Maximalist case, the BIOS would supply routines to access all the functions of the FooCard and your OS would Just Work no matter what.
However, the problem with the ideal Maximalist approach is that desiging a BIOS API that will work with all operating systems is HARD . Your BIOS has to have a means of calling back into the OS (since real, non-trivial drivers need to have things like semaphores, queues, interrupt handlers, rescheduling points, etc.), but then you have to insure that all operating systems supply all those APIs with the same semantics.
Now, ask yourself, if you designed a BIOS callback API around the Windows semantics (drivers cannot block, drivers must schedule a deferred procedure call if they cannot complete, drivers cannot cause a page fault to swap) how different it would be from a Unix-y style callback (drivers can block, drivers can pagefault from swap, drivers run til they are done).
The current thoughts are "The OS knows best what to do, let the OS have the drivers".
Now, in the context of a Free driver, you have to decide where between the Minimalist and the Maximalist you want to draw the line. Do you want to force the OS to have the code to set up the memory handlers and PCI bridges, for example? If the OS can handle reprogramming the PCI bridges it sure makes PCI hotplugging a great deal easier!
If you look at the LinuxBIOS approach, it is more of a maximalist approach targeting the Linux kernel. This is great if you run Linux, but what if you want to run *BSD, or Windows, or CP/M-86?
It would be possible, barely, to do like my old Multia did - provide BOTH a Windows friendly BIOS and a *nix friendly BIOS, and a means to switch between them. But now you've just doubled (actually more than doubled) the work for a system manufacturer - he has to write a BIOS for Windows, a BIOS for Linux, an BIOS for NetBSD....
"Just publish the specs, and we will write the driver!"
Again, publishing all the specs is hard - there's always that little "Oh yeah, we found that if the temp is less than 5C you have to wait an additional 50uS for this part to respond to a query - it's not intended behavior but it is observed behavior, Charlie found that out."
And even if you can completely document all the specs, there is still the little issue of "How do I, the end user, get the BIOS for *my* OS flashed onto this board?" - if you think the manufacturers are going to flash boards with seventeen different BIOSes depending upon the customers whims... I have some oceanfront property in Goddard, KS to sell you.
Then there is the issue of add-in cards - how do you integrate any BIOS they may have on them into the BIOS on your motherboard?
Now, I know somebody will point out OpenFirmware - the idea that the cards provide drivers in a bytecoded language targeting an API
www.eFax.com are spammers
actually, Intel cooperates quite a bit, by maitaining their own network cards or providing 2 or 3 developers for the linux acpi subsystem:
diego@estel ~/kernel # grep -i @intel.com MAINTAINERS | wc -l
11
Isn't it really time for some improvements in the bios area? Most OSes today don't use much of what is there, and the BIOS only function is to set up a number of parameters most non-overclockers/non-nerds could care less about.
What about making something more useful than what is there now? Something that could have more features, such as replacing grub all together? (as in be able to boot any of your OSes on any any kind of bootable hardware) Maybe even have it run *gasp* in 32/64-bit mode and leave all the old horrors of x86 BIOSes behind, and maybe even make it possible to tailer it to other kinds of hardware (not x86).
If they want people to support this, they really need to add some value to the whole thing, as many do care less about holier-than-thou hippiness.
This is a good starting place. "I have a dream" that someday we can have open hardware as well as software (aka www.opencores.org).
Man is the lowest-cost, 150-pound, nonlinear, all-purpose computer system which can be mass-produced by unskilled labor.
I mean, leaving aside the "free-as-in-speech" angle, surely the "free-as-in-beer" angle has undeniable attractions?
Is it really just a case of the dominant vendors wanting to use BIOS quirks to lock-in their market share?
If you had read the article by Stallman you'd have found out that Stallmann is specifically asking people that agree with him on the need for a free bios to boycott Intel and tell them about the reason for boycotting them.
So what Stallman is trying to do is build a market force that will persuade Intel that it is in its best interest to create a free bios or at least to not stand in the way of creating one.
Hope this answers your question.
RMS, seeking 100% freedom, calls for a free governement. He was quickly carried off to Guantánamo Bay, Cuba for what was called a "debriefing". Knowledgable sources have stated that he will be released "someday".
This is a greatly injust comment to the man who started the free software movement. Please note that RMS is the man behind gcc, the most important free piece of software in existance.
Intel support sucks....
They might have some great people working on linux but the company in general just doesn't care.
It took intel a full year before they had even half decent support for their wireless chipset despite promisses that they would support it when promoting it.
They refuse to release proper specs on their video chipsets in order to let X use the proper panel size on a laptop.
Jeroen
Secure messaging: http://quickmsg.vreeken.net/
Some onboard boot code is certainly required, but I would like the BIOS to stay as minimal as possible. Basically, just enough to load the bootloader.
There is trend toward larger and more featureful BIOS. I just don't understand that. Everything that can be done by the OS should be. Updating an OS is much easier than a BIOS, for starter.
And while you are there, why not drop the DOS-supporting cruft ? (like most of the BIOS software interrupts, for example)
:wq
I could be completely stupid, but isn't one of the jobs of the BIOS the configuration of the chipset and any embedded devices? For instance, an embedded AGP chipset that "Shares" some of the system RAM for video RAM, or a southbridge with several optional devices that may or may not actually be used on the motherboard.
The many and myriad chipsets out there all have quirks and special setup needs, even in really simple configurations. Chipsets have many registers that may need to be configured based on the layout of the traces on the motherboard - I've seen older VIA chipsets with registers for timing delays and (I think) slew rates on IO pins.
This would require a small army (or a company like, say... oh, I don't know... PHOENIX) to not only sift through the mountains of often crappy documentation to squeeze the most out of the chipset, while keeping the board stable.
If it's a choice between a stable, well-tweaked CLOSED BIOS and an unstable, lowest-common-performance-denominator OPEN BIOS, I'll pick the closed one, thanks.
do we really need a BIOS?
Can we live and power our computers without one?
Why don't we strip all obsolete junk away, i.e. the A20 gate? Once we do that, why don't we get rid of the BIOS itself?
The less hardware and software, the more direct access we'll have to the hardware, and the less software-wrappers we'll have around hardware -> higher speed, less code, more time for important things.
I can't answer those questions. Can you?
"All you have to do is be fragile and grateful. So stay the underdog." Chuck Palahniuk, Choke
Everyone should support and increase the compatibility of OpenBIOS!
OpenFirmware is the best BIOS standard ever, the joy of being able to code
from the command line and have non-interrupt-hijacking calls to the firmware,
a rudimentary HAL etc. is absolutely 100% cool.
It won't improve your Windows experience but who the hell cares about that?
It already has the support of Apple, Sun, SGI and IBM, comes in 32 and 64bit
versions in the standard, has a framebuffer, text console that redirects to
serial, video etc. automatically, blah blah blah.. Intel won't support it
because they like EFI.
But forget Intel too
Everyone should move to PowerPC, but then call me biased..
I'm sorry, but you're making a wrong assumption: this is not a zero-sum game. A zsg would require a situation where every gain on your opponent's side is a loss for you. Software development doesn't work that way. If you "invest" in creating new software that's freely shared you increase the pie, so to speak. By allowing other people to use your work and not requiring them to re-invent the wheel there is a net gain for the community, including you, since you benefit from others. This is a principle that might be hard to understand for someone who accepts the tenets of capitalism as the only ones possible (I do not wish to insult you, but many Americans seem terribly narrow-minded and uninformed in that respect, having been tought from childhood that everything related to communism is "bad" without ever going into detail).
-- Language is a virus from outer space.
RMS is not only the last person I would expect to put ego above cause, he is one of the few people in the world who truely understands what he started.
I wish people would just chill about the guy.
Kind Regards
"A few great minds are enough to endow humanity with monstrous power, but a few great hearts are not enough to make us w
Intel is actually trying to get rid of BIOS (that is controlled by PHOENIX), pushing its own "Extensible Firmware Interface" (http://www.intel.com/technology/efi/), which seems to be something like OpenFirmware reinvented.
The license on the download page looks like a standard 2 clause BSD license.
isn't the whole point of "Trusted Computing" to keep us from circumventing DRM?
Right now I'm running an AMI bios, a VIA chipset and an AMD processor. Shouldn't an open-source BIOS be subject to regular standards organizations, rather than a vendor?
And who exactly, when they've spent years working on a project on nothing more than blood sweat and tears and not a few Mountain Dews, is going to allow a company to come in, fork their code, write their own extensions, and keep them locked up ad infinitum?
The answer is no one. No one who does open source for fun, for the purity aspect will want to do this (Although I imagine there are a few masochists out there who don't understand dual licensing). Companies who want to do open source will do something like Sun and their CDDL, or won't do OSS at all.
He's done some very good things, but his goals may not all be relevant to me - and I said show us the code because results are often more relevant than goals. Simple proof of concept stuff says a lot more than ranting - I should have just left it as "show us the code" instead of putting in my own rant.
I really don't think RMS slamming Intel is going to acheive anything positive at all. RMS setting up some sort of BIOS group instead of just slamming Intel would acheive something.
I think in a few years' time, we'll see technology that could be adapted to a garage electronics shop. Some things might still have to be purchased from a commercial vendor, like silicon wafers and such, but I've seen plenty of articles in MIT Technology Review during the last 5 years that really look like they could allow hobbyists to cheaply produce their own microelectronics.
I think the hard part is going to be getting our hands on the software needed to design the things though. Here's some info that might might get you started if you want to browse for more ideas - http://www.geek.com/news/geeknews/2004May/bch20040 525025304.htm
Before we start to discuss on creating a FreeBIOS, I would like to ask, how do you flash your motherboard BIOS in a GNU/Linux Operating system?
Do we have a UniFlash counterpart in GNU/Linux?
(Btw, UniFlash is a DOS utility.)
Because AFAIK, I still have to boot a DOS floppy in order to have my motherboard BIOS flashed; or rely on tricks like creating a Bootable USB flashdrive wilth DOS on it.
Can management remain happy by keeping their baby to themselves, or would GPL require that the source to 'a' be made available?
If this code is all purely internal, and you're not distributing it outside the company, then you can do essentially whatever you want. The GPL only really covers distribution in that respect. It does have some words about modification of GPL'd code, but nothing there requires you to release or distribute your modifications to other people.
The above assumes someone else wrote 'b' and 'c'. How would the scenario change if I wrote 'b' and 'c'? Would it then be possible to keep management happy, and if so what would the licensing structure be?
If you wrote B and C, and don't have some clause where all your work is owned by the company, then it's a different matter. You own the copyright, so you can do essentially whatever the hell you want. If the company owns the copyright, then you'd have to convince them to release B and C as GPL instead.
But essentially, the owner of a piece of code can do anything they damn well please. The only catch here is in accepting patches back from other people. If you release a piece of code as GPL and somebody makes a patch, then they have created a derivative work and it's under the GPL now with respect to you. So you can't take those patches and then shove them back into something you're doing. Oh, you can if the ABC software is only distributed internally, you just can't relicense those patches under any other type of licensing scheme.
The point here is that if ABC is something you only use internally anyway, then it makes little difference what the licensing scheme on the code is. You just can't come back and distribute ABC later. If distributing ABC as a whole is a possibility, then licensing matters, but assuming all of ABC was written by people in the company or by you or what have you, then it doesn't matter all that much. You're hardly likely to sue yourself for violation of your license.
The only case where you have to watch it is when you release GPL'd code and accept patches back. You don't own those patches, and they are GPL'd to you. Accepting patches is a problem if you want to distribute ABC later.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
after the first release of a GPL'd BIOS, I bet RMS will get pissed off about the new BIOS being called "FreeBIOS" instead not "GNU/FreeBIOS".
"I think Europeans stereotype Americans and their views too narrowly. It makes America easier to understand for them maybe."
Yes, OR maybe that's an easy excuse to downplay any critique on Amerikans and the USA from us europeans.
For sure, there is a danger in using clichés and stereotypes, but it is also true, that those clichés *DO* hold a lot of water. Actually, I can't say I know of any well-established cliché about the nature of a people, that didn't had some truth in it. And that includes those of my own people/country, even though I would be hardpressed to acknowledge them in public. (Something which most USA-citizens seem to have too, only in a bigger national-zealot-reflex manner).
But actually, they ARE true, to a large extend.
The danger comes from turning that cliché into an absolute viewpoint: that ALL europeans or americans are like that. Being rational and honest, no one can actually claim such a thing, of course. So, while I may think that, in general, the USA - and especially it's current government - is arrogant, narrow-minded, uncritical and downright hypocrite idiots, I temper this viewpoint with the knowledge the USA also had and has critical thinkers and rebels that show signs of independend thought, intelligence and a cosmopolitan attitude, like Carl Sagan, M.Moore, R.Stallman and some others I've come to know by their work. Those people certainly deserve respect.
It does not follow the USA as a whole deserves respect. Certainly not like things are going currently. However you want to turn it, you must realise that the USA is behaving like a bully, and is increasingly acting - especially since the end of the cold war - like the world is their backyard where they can do what they want.
This is not surprising, since they ARE currently the only true superpower left, and being the strongest (as bullies usually go), they think everything is permitted. Sooner or later, they will discover their error.
--- "To pee or not to pee, that is the question." ---
The early BIOS was there to provide basic I/O support ... hence the name. but not all machines in the day had such a thing. This really came about from the fact that microprocessors were also being utilized in embedded applications involving firmware. So it was natural to think of having a firmware do common parts, like low level hardware support. But big computers, such as IBM mainframes, had no such thing. And they didn't need it. And a PC doesn't need it, either ... especially an I/O API part.
What is really needed to get an operating system started? Really, just a boot loader. The first computer I used was a PDP-8 minicomputer. It had a front panel where you could set switches to define data and address, and store the results into core memory. There was a boot loader program we would manually toggle into core memory when we needed to (core memory, BTW, retained its contents when powered off). That boot loader would then read the paper tape reader and load the operating system. But there was no I/O support from the boot loader. There was no firmware. The OS being loaded was self contained.
The next computer I worked on was an IBM mainframe (several of them, actually). Early models (360 series), did what was call IPL (initial program load) by triggering a single CPU instruction to perform a single channel I/O operation to read from a specified device (selected numerically by dials on the front panel). The first read operation loaded in just enough additional instructions to start more read operations to bring in enough of a boot loader to load the entire OS image. Then it branched to the OS and things took off. Again, there was no firmware I/O support other than these machines did have separate "I/O channel processors". The OS had to do whatever it would do on it's own.
Fast forward to the emergence of BSD and Linux on PC. The BIOS is used to load the boot loader which loads the OS. The boot loaders generally do use the BIOS API, but in theory, they should not have to. The OS (32 bit and 64 bit versions now) don't need, and generally can't use, the BIOS API.
So I say, get rid of it. Let's not have an I/O API in the BIOS anymore. Then let's quit calling it a BIOS (because it won't be that anymore).
That leaves 2 functions which what we now call a BIOS does already, which we still need to do. One is to configure the hardware. This is one of the hard parts because it has to be tailored to the chipset and maybe even CPU involved. The other is to load the operating system.
The hardware configuration could be handled in a different way. By adding on a 2nd smaller (maybe 16-bit) CPU, it can run a firmware program separate from the OS (the host CPU) that not only configures the hardware, but can also constantly monitor it while the OS is running. It could even be networked for those 10,000 machine server farms.
This same extra CPU could also do the boot loading. But it wouldn't need to do much device I/O. It should have the ability to read a few basic devices (serial port, USB, Firewire, floppy, CDROM, ethernet, and IDE/SATA hard drives) sequentially from a specified starting point and load blocks into RAM or into flash memory (or flash to RAM). Put it in a loop and it can do this with megabytes of OS images directly (this serving as the full boot loader). Flash memory of 4MB to 16MB would be plenty (for now).
I doubt we'll ever get a totally non-proprietary machine. But at least by having no more OS to firmware interfacing, we can eliminate some of the issues. And the extra control processor (something the later IBM mainframes already have many of anyway) will enhance the hardware support as well.
now we need to go OSS in diesel cars
We all know the whole 80x86 architecture is bodgey and suboptimal ..... people only stick with it because that's what Windows runs on. Why don't we just go out of our way to create a brand new, streamlined design for a hardware platform, using something like Power G5 processors? {And you'll note the plural there.} Not just the BIOS, but the whole motherboard. We could start from scratch, make it totally legacy-free if we so desired; though it'd be stupid not to support USB, SATA and one of the graphics card busses. The entire spec could be open. We could probably even specify repair-friendly stuff like "All ICs to be socketed, all jumper points to be labelled, LED indicators required on foo and bar".
Je fume. Tu fumes. Nous fûmes!
Theoretically, yes. But reverse-engineering is not as good as having access to specs. (and that's why RMS and others are asking to disclose them in the first place).
BTW, having people reverse engineer their hardware is not something they can influence, but they may choose to keep the specs secret (or offering access only under NDA).
How does something that directly contradicts reality get modded insightful ?
The current scarecrow to throw at your enemies is terrorism, not communism. Please follow your times.
Also, if you meant that shared ownership implies communism, it logically follows that any company with more than one shareholder is communistic.
AFAIK most open source projects are (or at least started as) the work of people, not corporations.
Um, isn't this exactly what the company releasing its code would want ? That anyone who distributes products based on the code must release any enhancments to the code under GPL as well ?
You do realize that just because you, the original author and copyright holder, released version 1.0 under the GPL, doesn't mean you that you are under any obligation to release version 1.0.1 under any license - assuming, of course, that you own the copyrights to all the code in version 1.0.1 ? Licenses are used togrant rights, under certain terms, to people who don't have the copyright to whatever is being licensed.
Or were you bemoaning over companies inability to take GPL'd code, add some features, and sell the result as their own proprietary product ? If so, keep on lamenting; you won't get any sympathy from me.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Companies sell me hardware.
...). Yup, DLink is now $80 ahead (at least on me).
Not (commodity) driver software.
I would STILL buy hardware -- in fact I require that any hardware
I buy be supported by open systems. No support == no sale.
I really, truly, don't want the hardware vendor writing drivers.
(except as an example of how the hardware is EXPECTED to be used).
Take Intel as an example. Intel supplies some proto-code to illustrated
how protected mode works. But Intel does NOT supply Windows, BSD, Linux
etc with the processor chip.
Does the GPL hurt at all under these rules? Perhaps a company is afraid
that simply having access to the register specs is going to allow
a competitor to build a compatible chip and sell it for less money.
Figure 6 months to tape out, test, write documentation, market -- and
think about the cycle on existing chips! It won't make any difference,
unless the original chip is SO simple that it is trivial and not worth
the purchase price.
Also, patents on chip algo implementations can be obtained (I even
have some, so it 'aint that difficult!)
Perhaps you want me to believe that Intel can compete whilst opening
a register spec on the processor itself, while NVIDIA and ATI can't compete?
I'll even grant you that... but, personally, I only use open drivers.
(more secure, crashes can be dealt with, and have a future). Even if the
open driver solution costs WAY more.
For example, I use the DLink 800+ Ethernet to Wireless Bridge, rather than
a closed-source 802.11b solution. Cost? $20 vs. $100. Benefit? The open
solution will work with any platform (PC, SPARC, Windows, Solaris, BSD,
Oh, and the software within the 800 isn't even `GPL'! Its simply a bridge
from 802.11b standard and Ethernet standard.
As to software - low level OS and driver and commodity software must
be open source. Specific applications may be distributed in a more rigid
manner (although I STILL prefer source distribution, not knowing if the
vendor is going out of business, or what her plans are -- escrow would
work as well).
Ratboy
Just another "Cubible(sic) Joe" 2 17 3061
Offhand, I can think of three strong arguments for an OpenBIOS.
- Decreased obsolence: As others have noted, changes in BIOS requirements can be responded to given the BIOS source. BIOS maintenance is no longer at the whim of the hardware vendor. This could extend the useful life of hardware.
- Decreased HW lockout: As others have noted, the move toward "Trusted Computing" could easily take a sinister turn. An open BIOS would make it much harder for hardware vendors to lock out libre software.
- Increased OS compatibility: Many seem concerned about getting hardware compatibility right in an open BIOS. The flip side of this is that getting the BIOS to work with an open OS would become much easier. The premiere example is ACPI, where the BIOS often has bugs with corresponding Windows workarounds.
I think the goal of producing an open BIOS that works well on a number of machines is quite a difficult one. The rewards of achieving it, however, seem high.In the days of CPM on Z80, it was not uncommon for the BIOS to be available as source code. In fact, Digital Research provided a skeleton BIOS so that developers could copy their example onto new hardware. Of course, a BIOS that was only 2 kilobytes was not a big deal, but it shows that the principle can work. And there's no "magic" involved.
Contribute to civilization: ari.aynrand.org/donate
You have a few incorrect assumptions in there.
First, you seem to assume that there should be a license monoculture. While that eases the learning curve, it isn't necessarily realistic. Each of GPL and BSD licenses has its place today. The GPL works very well for projects that need to establish a "community space" for sharing work. It has been especially successful, IMO, in projects where many parties can come together to distribute the effort of "infrastructure" -- code that would otherwise be a cost-center for everyone involved. The Linux kernel itself is a great example of this. BSD is highly appropriate for projects that prioritize the utility of the work to all parties over the community sharing ethos. It proven to be especially relevant to reference implementations of standards, where acceptance and deployment of the standard itself is more important than any code that merely implements it.
Second, you ignore dual (or N-way) licensing. For example, the folks that released FFTW (Fastest Fourier Transform in the West) at MIT did so with the blessing of the university because they could dual license. Researchers and those willing to contribute back to the work as a community effort reaped the benefits, while commercial entities with different licensing needs could pay as usual.
The Zesiger License is an interesting compromise, but I'm unclear as to how it would work in practice. The GPL and BSD licenses have "social" properties that have proved very valuable to certain projects. Zesiger may simply be another point in a continuum, useful to some, less so to others. Also, it'd be nice if Zesiger or a variant had an escrow clause to help avoid "lost" code, e.g. because the company failed, creator had no backups and a hard drive crash one month before the release deadline, etc. Maybe extend SourceForge with "SourceVault" -- pages with little timers on 'em. 8-)
As some have pointed out, we need business models that will support all the kinds of works that developers produce and users require. Licenses themselves create community rules that support or inhibit certain kinds of interaction, and thus certain ways of users obtaining support and developers earning a living. While it'd be great to have a "silver bullet" license that found that mythical perfect balance, I'm not yet convinced that goal is practical or even possible.
Have you READ that thing?
"This license may be modified at any time, even retroactively, by Zesiger Inc., or whoever it chooses to serve in it's stead, in order to preempt all possible legal issues which may pervert the intent of this license."
Retroactively modifying the terms under which I'm already using code? Sorry but I don't believe they took legal advice on that and I wouldn't touch anything that attempted anything so insane.
To summarise the summary of the summary: people are a problem. ~ h2g2
I just read the FAQ:
"Requirement #3 under Getting a License Approved says Create a legal analysis of the license as it complies with the terms of the Open Source Definition...The analysis should come from a licensed practitioner of the law in your country. Fortunately, the Zesiger License is completely incompatible with that requirement since it's specifically designed to never need any "practitioners of law" in any country. It's an international license, so we're not to going even try to get legal opinions from every country in the world."
It's intended to be used internationally therefore they HAVEN'T taken legal advice anywhere at all? And you say this isn't insane? It's "designed to never need any 'practitioners of law' in any country"? Nice trick that. Doesn't really fit with your theory of the courts rejecting unsuitable retroactive changes.
To summarise the summary of the summary: people are a problem. ~ h2g2
> They refuse to release proper specs on their video chipsets in order to let
> X use the proper panel size on a laptop.
There's a patch out there that gets this working. Google for 1280patch. Yes, I work for a company that puts Linux on laptops. =)
25% Funny, 25% Insightful, 25% Informative, 25% Troll
Slashdot has a bias toward stupid tech jokes in comments.
My other first post is car post.
...by following the instructions in the motherboard's manual. It said, "Be sure to connect to our website for any updates to the BIOS," so I very naively did so. At the time, I thought it was soooo nifty that I could download the update and copy it to a diskette that my new machine would boot from and automagically perform on itself. Of course, I also thought it was really nifty that I had managed to plug in all of the parts on the first try to produce a working machine!
Then I got a little nervous at the warnings that the update process couldn't be interrupted to avoid grave consequences. See, I didn't have a UPS, so I worried all through the update procedure.
Then it worked! There wasn't any discernible difference, though, and dang it if it still didn't recognize my drive. So I called Customer Support, and the polite woman asked, right off the bat, whether I'd flashed the BIOS. "Why, of course," I answered proudly, thinking I'd passed some kind of test that would otherwise have required me to admit that I hadn't, after which I'd have to call back, etc.
"Oh, I'm sorry, Sir. You've voided the support warranty. I'm afraid I can't help you."
Of course I started spluttering, and I even tried to deny that I had, but she was well-trained. And she already had the board's serial number.
Turned out I had a bad cable, anyway.
So I'm all for open-source BIOSes. And friendly support that charges a reasonable fee. And nice people everywhere. And the end of evil. And religious people who are also tolerant. And rainbows. And stuff that doesn't suck.
"Press to test."
(click)
"Release to detonate."
"Trusted Computing" used to be called "Palladium", but it got so trashed and exposed as an excuse for Microsoft to prevent anyone else from being able to read their files, and even potentially from being able to boot non-Palladium signed operating systems, that they changed the name. Richard Stallman was one of the people who was really raising red flags about its management of core parts of your hardware and denying access to other, non-Microsoft controlled software.
Like putting RFID tags in everyone's backside, there are real potential benefits but incredible social risks of the approach. And "Trusted Computing" is precisely one of the things that an open-source BIOS community would help manage and keep from doing things it blatantly *should not* do, such as be used to prevent motherboard makers from preventing you from using any OS other than their vendor-approved one (Windows).
- it just isn't "quite" free. AFAIK, both
SUN Microsystems and Apple use OpenBIOS. Each
of these vendors, of course, use a different
implimentation which is at least partially
dependent upon the hardware supported. In each
case, it is possible to modify boot parameters
in a (more or less) English readable format, at
the boot console level. At the core of OpenBIOS
(OpenBOOT) is a Forth language bootstrap, which
by definition is extensible. (Various Forth
gurus state that the entire Forth language can
be built from 13 or 15 core commands.) It is
quite possible to extend the OpenBIOS/BOOT core
to support new hardware not envisioned during
OEM R&D.
Given the memory densities currently available,
there is no reason why any system board or chip
level manufacturer, including Intel, could not
offer their customers the flexibility of OpenBIOS.
IMHO, it really boils down to greed of certain
manufacturers - closed source and closed APIs
results in more new motherboard sales. This is
no different, really, than software OEMs that
push upgrades on their customers in leu of the
patches needed to fix bugs and vulnerabilities.
If I were shopping for an OEM system board for
any project that required long term support (like
aviation, spaceflight, military, financial), I
would tend to favor a hardware platform that had
the flexibility and extensibility of OpenBIOS.