Phoenix BIOSOS? 394
jhfry writes "In an interesting development by an unexpected source, Phoenix Technologies is releasing a Linux-based, virtualization-enabled, BIOS-based OS for computers. They implemented a full Linux distro right on the BIOS chips, and by using integrated virtualization technology, it 'allows PCs and laptops to hot-switch between the main operating system, such as Windows, and the HyperSpace environment.' So, essentially, they are 'trying to create a new market using the ideas of a fast-booting, safe platform that people can work in, but remain outside of Windows.'"
Hrm (Score:5, Insightful)
Boot time? (Score:5, Insightful)
I hope they won't increase bloat inside BIOS.
The Achilles heel of this... (Score:1, Insightful)
Re:First post (Score:2, Insightful)
This is why you first post as anon.
Re:built-in virtualization (Score:3, Insightful)
Oh, never mind. Apparently they did. I should really RTFA before commenting.
Re:...only if the BIOS chip is replaceable. (Score:5, Insightful)
Re:The Achilles heel of this... (Score:5, Insightful)
I'll forgive your lack of experience on this matter but I have to answer your implication that driver absence is a Linux problem.
There is a problem with manufacturers who decide to keep their hardware specs secret and so make it difficult to have device driver support under Linux. It is true. It is a lot less common, but still true.
But this is not a problem that is exclusive to Linux. There are many devices that are older and will never have support for WindowsXP or Vista or Windows 7. The devices are considered old and outdated by these same manufacturers and do not want people using them any longer and so they don't pay to have people write drivers for more current versions of Windows. It happens. This problem also happens with Mac OS X. Recently, I upgraded my wife's machine to OS X 10.5.x and her Canon scanner does not and will not have drivers for 10.5.x even though 10.4.x and prior are still supported. All I could get were weak apologies from support but there is no intention to change from their position. They recommended that I buy some software from a 3rd party that costs twice what the scanner costs today in stores. (It is pretty weak that they actually display the MacOSX compatible logo on the package and it is no longer completely true...)
My point is that when drivers are not open sourced and/or the hardware specs are not openly available, your hardware is limited by the willingness of the hardware maker to support it. This is true of Windows, Mac OSX and Linux alike. This is NOT a Linux problem. It is a Manufacturer-with-their-heads-up-their-asses problem.
Re:Hrm (Score:5, Insightful)
He basically makes the argument that TPM is a dual-use technology: it can be used for good or evil. Problem is, the evil uses could easily be disabled without impairing the good uses... but that hasn't happened.
"Remote attestation" is for DRM, plain and simple. It's evil. There is no reason I'd want my computer to produce a report of what software I'm running without giving me the ability to change that report before it's sent out. That feature is useless for me as a user; it's only useful to third parties that want to restrict the software I'm allowed to run (e.g. by refusing to send me a video stream unless they know I'm using their preferred player).
If they removed remote attestation from the TPM spec, or simply put a switch on the side of the computer so the owner could forge attestations whenever he felt like it, it wouldn't be evil. So the question is, if Trusted Computing is such a boon for users, why does it still have features that only serve to undermine those very users?
Re:The Achilles heel of this... (Score:3, Insightful)
Re:Hrm (Score:5, Insightful)
> So the question is, if Trusted Computing is such a boon for users, why
> does it still have features that only serve to undermine those very users?
Or you might consider a slightly bigger world than your basement and uses for computers besides downloading porn and playing WoW. Remote attestation might not be something you care for, but if you were designing an ATM system you might feel differently about the ability to know, with a pretty high confidence, that the remote terminals are uncorrupted.
You are stuck on the idea that it is YOUR computer and that will always be so, that the person in front of the display owns the machine. But that just isn't true in a great many scenarios. I'd really like a system that allowed me to know if one of the workstations around here had been compromised. All of our machines are 'mine' in the sense I'm the one responsible for them, the employees sitting in front of em just use em.
Even remote attestation can be used for either good or evil. The key is to resist when big media tries to use it for evil. And it's evil because the machines aren't TimeWarner's yet they want to assert ownership over them just because they are displaying their precious IP.
Re:Flash memory has a limited number of writes. (Score:5, Insightful)
... but an unlimited number of morons !!!
Re:GPL'd code available only by request? (Score:2, Insightful)
It's not like it matters how easy they make it to access the source. Since it's under the GPL, there will be easy-to-use and easy-to-install community projects spun off from this, just like for wireless routers. Only people wanting to sync the project they manage with the manufacturer's source will need to try to acquire the manufacturer's code. Everybody else will get it in the form of a third-party improved distribution.
Re:Hrm (Score:5, Insightful)
Remote attestation might not be something you care for, but if you were designing an ATM system you might feel differently about the ability to know, with a pretty high confidence, that the remote terminals are uncorrupted.
Fair enough. But if I were designing an ATM (or a kiosk, or any other public-facing terminal where remote attestation might have a legitimate use), I could put whatever additional hardware in there I wanted. I'm already adding a keypad, card reader, touch screen, etc. so why not one more thing?
Remote attestation isn't something that needs to be built into the average PC. On a typical user's desktop, remote attestation doesn't really have any legitimate uses, only evil ones.
I'd really like a system that allowed me to know if one of the workstations around here had been compromised. All of our machines are 'mine' in the sense I'm the one responsible for them, the employees sitting in front of em just use em.
If those workstations came with a switch on the side for forging attestations, and you didn't want users doing that, you could simply disable the switch. Just like you can already disable CD-ROM drives, USB ports, or whatever else users might use to compromise the workstations.
Re:The Achilles heel of this... (Score:5, Insightful)
A driver missing on an OS isn't the OS developers' fault, but it is their problem. There is a difference. They're not responsible for making the drivers, so its not their fault. Users still don't want to use an OS where they can't use their electronics, though, so it is a problem for the OS developers.
The solution to that problem may be intractable in some cases (a manufacturer refuses to divulge drivers under any circumstances, and no-one is willing to put in the effort to reverse engineer). However, Linux has done remarkably well, and things are only getting better driver-side.
But you're right its not a Linux-exclusive problem. My current printer doesn't work with my Mac, and older equipment may not work with newer versions of Windows.
Re:The Achilles heel of this... (Score:5, Insightful)
How many FOSS drivers must I mention before you admit Linux does have a problem?
More specifically: how many FOSS drivers *which are not maintained in the kernel tree* must I list?
1. MTP008 temperature sensor was removed from 2.6 (was in 2.4).
2. Peracomm USB ethernet (stopped working while in kernel tree)
3. DIB0700 (and many, many other) based DVB cards - the manufacturer helped making the driver but it still (after over 3 years, in 8.10) is not up-to-date/maintained in the kernel tree.
4. Numerous Wifi cards some of which partially work and some not.
5. Webcams (gspca).
Need I go on?
6. EeePCs ... most came with Linux, most drivers still do not work even in 8.10.
Nobody claims this is exclusive to Linux, it is just a lot more pronounced in Linux.
My point is that even when drivers are FOSS and the manufacturer has willingness Linux *users* can and do have problems.
I leave it as an exercise to the reader to find out why and who is to blame.
Re:The Achilles heel of this... (Score:5, Insightful)
There are many devices that are older and will never have support for Windows XP or Vista or Windows 7. The devices are considered old and outdated...
In almost every case - they are old and outdated -
at least those devices produced for the home and SOHO markets.
I replaced a old HP printer with a wireless multifunction HP printer-scanner-fax with Vista drivers -
and by old I mean that only the parallel port worked with XP.
The new - refurbished - ink jet cost $99 with a one year HP warranty. It lacks only the color LCD for instant photo printing.
This is NOT a Linux problem. It is a Manufacturer-with-their-heads-up-their-asses problem.
There comes a time when the geek needs to let go. To pull the plug.
Open Source is not a panacea.
Someone still has to sit down and make the decision to write and test a new driver for a fast-fading piece of legacy hardware -
and if he says the hell with it, there is not much you can do.
Re:The Achilles heel of this... (Score:2, Insightful)
I also have a Mac, but it doesn't have any peripherals. Those are all attached to my Linux desktop machine. Which brings me to addressing the concern of the parent with his Canon scanner woes:
Why not try installing Sane (and xsane) to interface with the scanner?
Sane supports most of the more common brands of scanner, provided they don't rely on funky things like parallel ports.
Re:Hrm (Score:3, Insightful)
Because it's about vendors trusting they have control of *your* machine, not about you *trusting* control of your machine.
Re:The Achilles heel of this... (Score:5, Insightful)
If the manufacturers will release the damn specs the geeks write the drivers for them and those drivers get included with every distribution by default.
While that is an interesting argument, there are a few fundamental problems that bother me:
a) The incentive of manufacturers to release said specifications is low. Regardless of money made on the acquisition of a wider user base (often through more hardware sales), such specifications create issues for intellectual property and often serve as an opportunity for any competing manufacturers to digest a well-prepared buffet of the inner workings of hardware and the software that supports it.
b) The incentive of said 'geek' to actually sit down and not only write but actively maintain said drivers is based on demand and free time. This leads to the parent post "now you see it, now you don't" support syndrome.
c) The incentive of a manufacturer to release quality specifications is next to non-existent. In many cases, only the most determined OSS master-mind is capable of both understanding what are often meant as 'internal use only' documents and actually creating a driver. While I have little doubt such people exist, there is only so much time, sweat, blood, and tears that many people are willing to give for results.
Note that I actively contribute to the open source community and use Linux on a regular basis. That said, I don't believe manufacturers are (entirely) to blame.
Re:The Achilles heel of this... (Score:3, Insightful)
and if he says the hell with it, there is not much you can do.
Well , you can write it yourself.
Or better , find other people , who want the same driver , and cooperate to make the driver. This is how most of the drivers are made and improved.
What the heck (Score:5, Insightful)
Which is why our landfills are filling up with e-waste faster than they should be. Great example of attitudes in a disposable society.
I'm all for progress and new technology, but why discard something because it just needs a new set of drivers? The reason why manufacturers can get away with this crap is because people don't get pissed off enough and light up their call enters with complaints.
Re:The Achilles heel of this... (Score:3, Insightful)
The "Apple Tax" is more than worth it. OS X is virtually 100% secure, and its worth paying the cost difference to ensure my stuff is on my Mac and Time Machine drive, rather than being sold off to the highest bidder off a server in Tehran.
Bwahahaha
Great Idea ... M$ will kill it (Score:4, Insightful)
Or at least pee on it and create a wall of FUD. Their mighty and perfect OS usurped by lowly BIOS - and a BIOS running Linux. How totally non-elegant !
Its a great idea and I would actually have a reason - a real reason - to upgrade my hardware. But I can see M$ telling Dell - HP - etc. if you want to put Windows a BIOSOS system ... no OS discount for you !
However I would love to see the industry find a way to shove this down Balmers throat.
Re:The Achilles heel of this... (Score:5, Insightful)
Re:The Achilles heel of this... (Score:2, Insightful)
Re:The Achilles heel of this... (Score:5, Insightful)
Re:The Achilles heel of this... (Score:4, Insightful)
Where Open Source Works and where it doesn't (Score:5, Insightful)
This brings up an important point. There is plenty of incentive for someone to write a web server, a database manager, an OS kernel or thousands of other generic bits of software. There is almost NO incentive for someone to write a driver for an obsolete device. The former can be a source of consulting and employment. The latter can actually work against you.
I mean, if a hardware manufacturer finds out you like to write device drivers for obsolete hardware, they're not going to be pleased. All those people keeping their old printers will prevent the manufacturer from profiting by making new ones. And if you really get creative by making the hardware do all sorts of new tricks it never did before, they're probably going to look for some excuse to get rid of you.
They want to sell new product, not keep the old stuff going. I know it's wrong to say this, but that's how the world's economy is configured right now.
Re:The Achilles heel of this... (Score:4, Insightful)
Re:The Achilles heel of this... (Score:3, Insightful)
Wrong.
1. You need to compile the module.
2. You need to recompile the module on every kernel (security) patch.
Re:The Achilles heel of this... (Score:3, Insightful)
I gave you one particular product line on which the WiFi does not "just work" (EeePC).
I am happy to hear you have had no problems. I would be much, much more happier if I did not have any problems either.
Re:The Achilles heel of this... (Score:3, Insightful)
I believe you (it works for me too, after several days of fixing), but they are not using *vanilla* Ubuntu (8.04LTS/8.10) so it does not work out-of-the-box.
8.04 cannot handle WPA2 properly (loses the key constantly). For both 701 and 900 you need either to compile the driver or use array.org.
Both are, IMHO, unacceptable solution for an average user and huge PITA even for experienced user (like me).
Re:The Achilles heel of this... (Score:3, Insightful)
Re:Hrm (Score:3, Insightful)
Then don't be surprised when Time Warner says "Fuck you back, you can't have our content."
Good, bring it on! I think we know who'll win that staring contest. There's plenty of other content I can access without ceding control of my PC.
THAT'S what TPM media attestation is all about. Balancing the equation.
Hah. The "equation" is already heavily slanted toward Big Content. TPM slants it even more toward them, and you call that balance?