Based on the outcome of this little experiment, I would definitely believe that cells could interfere with other systems - including aircraft systems - even though it may seem counterintuitive.
Because some personal, anecdotal experience goes a lot further than the 100s of FAA reports of incidents related to electronics in the cabin.;-)
But as previously posted, what OS has been guiding rockets? Wind-SCO-s?
Uhm, nope. You know there _are_ other OSs out there besides Windows and Linux. Sure, a post like that makes for good Karma, but for crying out loud, what is the exact value of your post?!
I will tell you which OSs have been running stuff like this; real-time, embedded OSs, such as VxWorks, QNX and all the others. Until recently linux SUCKED ASS for real-time applications. I don't think even Torvalds would mind me saying so. It just wasn't designed that way. There have been major improvements lately, which are all very promissing, but for applications that really demand real-timeness, probably very few people (in their right frame of mind, no offense) would choose Linux.
Why not just encrypt the whole hard drive or the just sensitive data? To the thief, it's as good as it being erased.
Because Phoenix has a business plan that's going down the gurgler really quickly (ever seen a BIOS on a xScale/MIPS/PowerPC?) and they need something to keep people wanting to have their BIOS. This is what _they_ believe is the answer.
That must have been a little while ago then. I develop BIOSs for a living and it's been a couple of years since I worked on a board that actually had the Flash socketed. (the Meritec socket for TSOPs is just too damn expensive)...
Not that I disagree that Phoenix is smoking too much weed or anything though...
To reply to a whole bunch of comments that declare how VOD is going to fail:
First of all, people are confusing delivery method with reproduction technology. VOD is delivery, DVD is delivery (as in a shiny disc) AND reproduction (as in MPEG2 and AC-3): A DVD is in fact VOD. It plays whenever you want it to. So basically we are comparing Apples and IBMs here. VOD, as per definition, does not mean that you don't get to keep a copy on a local storage device.
Now for VOD failing because of
- Quality: "people will want better quality"
Not really. People had CDs and moved down to MP3s; obviously people care more about convenience than about quality, especially since quality is arguably more important in audio than video. In any case, some day digital video _will_ reach a state where a human can not distinguish technically better quality.
- Physical Media: "people will want to have a hard copy"
Same argument as above applies, I don't think anyone downloading their MP3s from Kasaa cares all that much. But think of a world where you could play the movies you had paid for anywhere and anytime you wanted to. Now does VOD still sound bad? Who the hell cares about physical media??!!
People that use this argument have become slaves of the RIAA and MPAA. This is EXACTLY what they want. But in all reality, the future has no place for things like CDs and DVDs. At the end of the day, the real value is in the movie or the music, not the booklet or the silver disc. The music or movie's what you want to get, so who the fsck cares where it comes from?
- People want to keep their own disc
Yeah right, ask blockbuster how adament people are about that.
I think people are confusing licensing issues with the true defninition of VOD, which is to watch video when you want to. I think VOD could be just as popular as internet for the very same reason: information when you want it.
right when I started there was a whole pile of software boxen in the hallway. My manager told me that I could take whatever I wanted. So I looked around and found really early versions of Windows and DOS. I thought it was cool and so I took em home. Then one day after perhaps one too many evenings of Linux hacking I was cleaning up my room... you guessed it, out they went. I have to admit, I regret that a bit...
Since I would like to keep using my ass for sitting on, this is not the type of question to post to Torvalds, but maybe someone here can enlighten me:
Why is there not more effort being put into making the scheduler real-time and pre-emptive (and I don't mean pre-emptive at the application level, but all the way down to the driver level)?
I know the SMP support solve some of the pre-emptive issues, but all in all these scheduler patches sound very kludgy. Is it because the unix subsystem precludes such a thing, or is the kernel design just too far off to make this work, or is there simply no desire because these patches are considered a 'better' approach?
For example, are context switches extremely expensive for the Linux kernel?
This is NOT intended as flaimbait, just true interest.
Your reply makes absolutely no sense (except maybe that you where able to add some of the favorite M$ bashing).
a software company (notorious Microsoft comes to mind) can get away without being liable for the countless bugs that cost untold billions in damages, why do you think a company with a 'backdoor' in their product is going to be anymore liable?
a) who do you think has the deepest pockets to sue? Being liable, and being sued for it are two different things. Even though M$ may be liable, who is going to sue them? On the other hand, M$ sueing an individual because (s)he deliberatly added code that caused damage to their company is a lot more likely. b) courts usually consider harm done intentionally as something entirely different to something that's done unintentionally. c) whether it holds up in court or not, being sued for liability is NOT going to be a fun trip.
No question the dude who wrote the code will get the boot, but do you really think that a bug and a backdoor are that much different?
Yes, I do think so. See above.
I work with digital video (on aircraft) which is released on our product well before it's released as DVD. The movie industry is very protective about this material. If we had a backdoor in our software which allowed me to download the video from the system (which is otherwise impossible) to an other computer, we have been assured that we will be held liable for any damage (even if the backdoor didn't directly allow it, but perhaps a bug in it). And believe me, these people don't fuck around.
But if you want to find this out the hard way, be my guest.
Writing backdoors is an extremely stupid and dangerous thing to do.
Obviously you take the risk to get fired on the spot. But of far greater risk is your liability. What if your backdoor causes (unexpected) damage to the company? Do you have the pockets to make up for that? Because you can rest assured they will be knocking at your (front) door.
If you have to write a backdoor for 'good' reasons, make sure the company is aware of it, and there should be no problems at all.
The 'putting in a backdoor to make sure a customer pays in time' is stupid as well. If someone writes software for me and comes back with an 'update' after we pay that removes a backdoor, that was exactly the last time that person would work for me.
In fact, that programmer would have signed a contract that specifically states that we do not allow backdoors, but I guess not all companies think of that... Regardless, that programmer has wasted the company's time, with all sorts of (legal) consequences.
>> "We did it that way because we don't want to eat up disk space, and we wanted to make it easier if people had to restore from a backup."
Just how do you manage to restore data that never gets backed up?
Good point. Or how is 512 bytes of data "eating up disk space"?
The response is laden with stupidities:
But when you write to an area of the disk that's not ordinarily used, people think you're trying to hide something
Uh, yeah?! Are they trying to say that they put it there for an other reason?
Or: The PCTest results show that SafeCast consumes less than 1MB of memory on a typical Windows XP machine, according to Intuit.
So, let me see, if I install say, 100 pieces of software (not that unthinkable), I should consider it 'normal' that 100MB of my memory is basically gone?
Linux already satisfies the four most popular criteria: Real Time capabilities...
How is that? Surely you are not speaking of the great RTLinux hack? I mean RTLinux != Linux. It _runs_ Linux and can communicate with Linux, but as far as I'm concerned this is not a solution I would choose unless I _really_ had to use Linux for one reason or an other.
Linux itself is NOT real time and it will probably take a while (if ever) to achieve that. The kernel design is just not right for it (I'm not saying the kernel design is not right though).
Anyways, this has been discussed several times, and I think the most important thing here is that very few embedded apps actually need real-time behaviour. I've used Linux once in an embedded system and it performed beyond expectation.
But I wish people quit claiming Linux was real-time when it simply is not. Running an other OS which loads Linux as a sub-task doesn't make Linux real-time. And I really don't think you're going to fool any embedded developer.
Who else is going to deceide it and why should developers implement something they do not like ?
Well, at the end of the day, if the project is not a commercial one, but developed by enthusiasts, maybe the developer will. I'm just saying that the developer is not the ideal person to make UI decisions.
If you are talking open source projects, well, anyone can do whatever the hell they want. So if the programmer decides to do the UI, fine. Just don't expect it to be a good UI. (and maybe sometimes it _will_ be a good UI, some people are multi-talented)
But if you talk about doing the right thing, having a programmer design the UI has been proven to lead to some pretty dodge projects. Read Alan Cooper's stuff. It's really interesting.
The best thing would be if UI designers that are trained and gifted would start contributing to open source projects. But like I said, unfortunately there's not very many of those around...
I know exactly how it works. Anyone that has ever initialized modern DRAM will never forget the painful exercise.
I suppose bootloader is an unfortunate term I chose, but as I said in an other reply, I don't like to call it BIOS because it doesn't provide the legacy shit.
What I am talking about is a replacement for the BIOS though, just like LinuxBIOS.
To be more precise, my 'BIOS replacement' does the following, roughly: - init Super IO so 'post codes' can be provided over RS-232 - init DRAM - init programmable interrupt controller - init timer - init video - display 800x600x24 graphics display - init chipset - init network chip - try load OS from harddrive - if harddrive fails, try load OS from network - in either case, if OS loads, start OS
total time from power up to loaded OS: 2 seconds from network, 3 seconds from harddrive, since harddrive takes 3 seconds to spin up.
Sorry to continue on, on my own comment, but I just wanted to add some stuff.
Ironically, Alan Cooper's website has become a little less 'obvious' to navigate. So here's a direct link to Alan Cooper's books (like "The Inmates Are Running the Asylum").
To continue on the subject of how configurable a UI should be, I think it's very important to consider _what_ is configurable.
Take for example themeing. I couldn't care less for that shit. I have no time to fuck around with purtyfing a machine. I change machines too often and I use too many different machines.
On the other hand, say I start a large download from an FTP site and decide to go get a beer because it's a really large download that's going to take two hours, and while I'm gone, it bombs out at 50%, putting up a message box asking whether I want to retry or cancel, What The Fuck do the developers of that software think I would want to answer? Of course I want it to retry.
The alternative would be to write the software such that it would display the fact that it has problems, along with a 'cancel' button to quit anytime I like, but in the meantime it would continue to retry until it has what I wanted.
I mean the fact that I asked the fucking computer to download the file indicates that I want it right? Why would it need to ask me if I want to retry because of some technical glitch that I couldn't care less about?
Well, you catch my drift.
So, yes, I do want an option in the configuration that says "retry as long as I don't press cancel".
But I think too many configuration options are there because the developers are insecure about what's 'right'. Hidding the 'for experts only' options is a nice thing, but look at OS/X, they just said 'this is it, this is the right way' and they seem to be largely right.
At the end of the day, to make a product succesful, it's no good to have options to configure stuff that only one or two people care about. If you can have the UI present things in two different ways, and you have an evenly divided group of users that feel strongly that it should be either one way or the other, then yes, it should probably be configurable. Otherwise, screw it. Apparently not enough people complained about the fact that you have to hit 'Start' to shutdown your computer in Windows...
As mosfet writes: Check this out to see a developers take on the whole "less-is-more" debate going on about Linux user interfaces
Now, I've no doubt he's a very gifted developer. But more often than not, a developers opinion on UI issues should be disregarded.
It's not because they couldn't potentially be good at it, it's because their brain is occupied with technical issues that have no relevance to an end-user.
Alan Cooper has written some pretty fine books about these issues, which I'm sure any developer related to UI design finds very informative. Some of the anecdotes are hilarious.
Unfortunately, it seems that Human Interaction Design is still not very high on the list when people design a product, resulting in there not being very many people that have specialized themselves in this field. It goes without saying that finding the right people for such a job for open source projects is tricky, to say the least.
From what I read, this is NOT the answer
on
BIOS' Days Are Numbered
·
· Score: 5, Interesting
Intel however, doesn't seem to quite understand the issue. I mean, EFI is partially stored on the hardrive?! Sounds to me they are making things more complex, instead of less.
The quote " In effect, it's a tiny operating system in its own right," scares the shit out of me.
And all this hype about graphics, I mean, come on. I wrote a boot loader in 64K that booted straight into true color, 800x600 graphics mode, including a compressable image. It's not a big deal. And of course "With the BIOS, that's limited to VGA or worse" is horseshit, the BIOS can use the VESA BIOS to switch to any mode it desires. This is all a non-issue. It's been solved.
Yes, network diagnostics is good. But I'd rather have a secure network boot, because then I can do anything, including loading a remote OS even though the harddrive shat on itself.
The BIOS is the last place on the PC where people have to write in low-level assembler code, and we want to end that" he said. Instead, EFI is almost entirely written in C,
Bullshit, there are BIOSs that are written in C. Actually, my bootloader is written in C++. There.
so if your OS freezes you can go in and look at the state of the machine, change configuration, load a different driver, and do a sensible restart
Yeah right, I can totally see my mom do that. I've spent hours trying to get Windows XP Embedded to NOT probe a secondary IDE channel because it was not terminated correctly and would hang the boot, using the kernel debugger and all. Never got it to work. And this is going to all work just like that?
Finally, it can pretend to be a BIOS. "We're not expecting people to throw out the BIOS overnight, so EFI can support legacy systems by running on top of an existing BIOS and handing over control when appropriate."
Ah! I was wondering where that backwards compatibility was. I'm so happy that we are moving one step forwards and two steps back.
Yep, this probably sounds a flamebait, a silly rant, whatever. There's some good ideas there, but I don't think they are on the right track...
At the end of the day, the BIOS (boot loader) should be in Flash (ROM) so that it still works even if there's no harddrive. It should get the hell done with all hardware initialization and boot the frigin OS. Putting more complexity in the BIOS means more bugs, means more updates, means more security risks.
Slashdot Mirror
Based on the outcome of this little experiment, I would definitely believe that cells could interfere with other systems - including aircraft systems - even though it may seem counterintuitive.
;-)
Because some personal, anecdotal experience goes a lot further than the 100s of FAA reports of incidents related to electronics in the cabin.
But as previously posted, what OS has been guiding rockets? Wind-SCO-s?
Uhm, nope. You know there _are_ other OSs out there besides Windows and Linux. Sure, a post like that makes for good Karma, but for crying out loud, what is the exact value of your post?!
I will tell you which OSs have been running stuff like this; real-time, embedded OSs, such as VxWorks, QNX and all the others. Until recently linux SUCKED ASS for real-time applications. I don't think even Torvalds would mind me saying so. It just wasn't designed that way. There have been major improvements lately, which are all very promissing, but for applications that really demand real-timeness, probably very few people (in their right frame of mind, no offense) would choose Linux.
Cringely got something like 10Km with a Pringles can
Then again, Cringely never bothered to disclose exactly how he accomplished this 'fantastic' feat.
Why not just encrypt the whole hard drive or the just sensitive data? To the thief, it's as good as it being erased.
Because Phoenix has a business plan that's going down the gurgler really quickly (ever seen a BIOS on a xScale/MIPS/PowerPC?) and they need something to keep people wanting to have their BIOS. This is what _they_ believe is the answer.
Last I checked, the BIOS was in a socket.
That must have been a little while ago then. I develop BIOSs for a living and it's been a couple of years since I worked on a board that actually had the Flash socketed. (the Meritec socket for TSOPs is just too damn expensive)...
Not that I disagree that Phoenix is smoking too much weed or anything though...
To reply to a whole bunch of comments that declare how VOD is going to fail:
First of all, people are confusing delivery method with reproduction technology. VOD is delivery, DVD is delivery (as in a shiny disc) AND reproduction (as in MPEG2 and AC-3): A DVD is in fact VOD. It plays whenever you want it to. So basically we are comparing Apples and IBMs here. VOD, as per definition, does not mean that you don't get to keep a copy on a local storage device.
Now for VOD failing because of
- Quality: "people will want better quality"
Not really. People had CDs and moved down to MP3s; obviously people care more about convenience than about quality, especially since quality is arguably more important in audio than video. In any case, some day digital video _will_ reach a state where a human can not distinguish technically better quality.
- Physical Media: "people will want to have a hard copy"
Same argument as above applies, I don't think anyone downloading their MP3s from Kasaa cares all that much. But think of a world where you could play the movies you had paid for anywhere and anytime you wanted to. Now does VOD still sound bad? Who the hell cares about physical media??!!
People that use this argument have become slaves of the RIAA and MPAA. This is EXACTLY what they want. But in all reality, the future has no place for things like CDs and DVDs. At the end of the day, the real value is in the movie or the music, not the booklet or the silver disc. The music or movie's what you want to get, so who the fsck cares where it comes from?
- People want to keep their own disc
Yeah right, ask blockbuster how adament people are about that.
I think people are confusing licensing issues with the true defninition of VOD, which is to watch video when you want to. I think VOD could be just as popular as internet for the very same reason: information when you want it.
right when I started there was a whole pile of software boxen in the hallway. My manager told me that I could take whatever I wanted. So I looked around and found really early versions of Windows and DOS. I thought it was cool and so I took em home. Then one day after perhaps one too many evenings of Linux hacking I was cleaning up my room... you guessed it, out they went. I have to admit, I regret that a bit...
Since I would like to keep using my ass for sitting on, this is not the type of question to post to Torvalds, but maybe someone here can enlighten me:
Why is there not more effort being put into making the scheduler real-time and pre-emptive (and I don't mean pre-emptive at the application level, but all the way down to the driver level)?
I know the SMP support solve some of the pre-emptive issues, but all in all these scheduler patches sound very kludgy. Is it because the unix subsystem precludes such a thing, or is the kernel design just too far off to make this work, or is there simply no desire because these patches are considered a 'better' approach?
For example, are context switches extremely expensive for the Linux kernel?
This is NOT intended as flaimbait, just true interest.
According to the article it's only a 5W with an old 0.18um process.
Then again, a more equivalent (in terms of performance) Intel CPU would be the Mobile Celeron at 400MHz which consumes 4.23W max.
Your reply makes absolutely no sense (except maybe that you where able to add some of the favorite M$ bashing).
a software company (notorious Microsoft comes to mind) can get away without being liable for the countless bugs that cost untold billions in damages, why do you think a company with a 'backdoor' in their product is going to be anymore liable?
a) who do you think has the deepest pockets to sue? Being liable, and being sued for it are two different things. Even though M$ may be liable, who is going to sue them? On the other hand, M$ sueing an individual because (s)he deliberatly added code that caused damage to their company is a lot more likely.
b) courts usually consider harm done intentionally as something entirely different to something that's done unintentionally.
c) whether it holds up in court or not, being sued for liability is NOT going to be a fun trip.
No question the dude who wrote the code will get the boot, but do you really think that a bug and a backdoor are that much different?
Yes, I do think so. See above.
I work with digital video (on aircraft) which is released on our product well before it's released as DVD. The movie industry is very protective about this material. If we had a backdoor in our software which allowed me to download the video from the system (which is otherwise impossible) to an other computer, we have been assured that we will be held liable for any damage (even if the backdoor didn't directly allow it, but perhaps a bug in it). And believe me, these people don't fuck around.
But if you want to find this out the hard way, be my guest.
Writing backdoors is an extremely stupid and dangerous thing to do.
Obviously you take the risk to get fired on the spot. But of far greater risk is your liability. What if your backdoor causes (unexpected) damage to the company? Do you have the pockets to make up for that? Because you can rest assured they will be knocking at your (front) door.
If you have to write a backdoor for 'good' reasons, make sure the company is aware of it, and there should be no problems at all.
The 'putting in a backdoor to make sure a customer pays in time' is stupid as well. If someone writes software for me and comes back with an 'update' after we pay that removes a backdoor, that was exactly the last time that person would work for me.
In fact, that programmer would have signed a contract that specifically states that we do not allow backdoors, but I guess not all companies think of that... Regardless, that programmer has wasted the company's time, with all sorts of (legal) consequences.
Yeah, it's been asked before, but I'll ask it again: how much does one of these front-page, disguised as 'article', advertisements cost exactly?
Queen, anyone?
No thanks.
Heh, poor Germans. Still running a 440BX. :-)
>> "We did it that way because we don't want to eat up disk space, and we wanted to make it easier if people had to restore from a backup."
Just how do you manage to restore data that never gets backed up?
Good point. Or how is 512 bytes of data "eating up disk space"?
The response is laden with stupidities:
But when you write to an area of the disk that's not ordinarily used, people think you're trying to hide something
Uh, yeah?! Are they trying to say that they put it there for an other reason?
Or:
The PCTest results show that SafeCast consumes less than 1MB of memory on a typical Windows XP machine, according to Intuit.
So, let me see, if I install say, 100 pieces of software (not that unthinkable), I should consider it 'normal' that 100MB of my memory is basically gone?
Do I need to go on?
Nice job yanking it through a translator; /. two sites at once! :-)
with no loss of audio quality.
So now I can finally play like McFly in Back to the Future, without permanent hearing damage.
I bet the rest of the band is going to really appreciate this feature.
Linux already satisfies the four most popular criteria: Real Time capabilities ...
How is that? Surely you are not speaking of the great RTLinux hack? I mean RTLinux != Linux. It _runs_ Linux and can communicate with Linux, but as far as I'm concerned this is not a solution I would choose unless I _really_ had to use Linux for one reason or an other.
Linux itself is NOT real time and it will probably take a while (if ever) to achieve that. The kernel design is just not right for it (I'm not saying the kernel design is not right though).
Anyways, this has been discussed several times, and I think the most important thing here is that very few embedded apps actually need real-time behaviour. I've used Linux once in an embedded system and it performed beyond expectation.
But I wish people quit claiming Linux was real-time when it simply is not. Running an other OS which loads Linux as a sub-task doesn't make Linux real-time. And I really don't think you're going to fool any embedded developer.
bootrom?
:-)
Yeah, that's not a bad idea. I think I just might start using that
Who else is going to deceide it and why should developers implement something they do not like ?
Well, at the end of the day, if the project is not a commercial one, but developed by enthusiasts, maybe the developer will. I'm just saying that the developer is not the ideal person to make UI decisions.
If you are talking open source projects, well, anyone can do whatever the hell they want. So if the programmer decides to do the UI, fine. Just don't expect it to be a good UI. (and maybe sometimes it _will_ be a good UI, some people are multi-talented)
But if you talk about doing the right thing, having a programmer design the UI has been proven to lead to some pretty dodge projects. Read Alan Cooper's stuff. It's really interesting.
The best thing would be if UI designers that are trained and gifted would start contributing to open source projects. But like I said, unfortunately there's not very many of those around...
I know exactly how it works. Anyone that has ever initialized modern DRAM will never forget the painful exercise.
I suppose bootloader is an unfortunate term I chose, but as I said in an other reply, I don't like to call it BIOS because it doesn't provide the legacy shit.
What I am talking about is a replacement for the BIOS though, just like LinuxBIOS.
To be more precise, my 'BIOS replacement' does the following, roughly:
- init Super IO so 'post codes' can be provided over RS-232
- init DRAM
- init programmable interrupt controller
- init timer
- init video
- display 800x600x24 graphics display
- init chipset
- init network chip
- try load OS from harddrive
- if harddrive fails, try load OS from network
- in either case, if OS loads, start OS
total time from power up to loaded OS: 2 seconds from network, 3 seconds from harddrive, since harddrive takes 3 seconds to spin up.
A bootloader is not a BIOS
I know, I just don't like to call my code a BIOS because it does not provide any of the legacy BIOS functions. All it does it boot the OS.
I suppose bootloader is a bad term, please suggest something better.
Sorry to continue on, on my own comment, but I just wanted to add some stuff.
Ironically, Alan Cooper's website has become a little less 'obvious' to navigate. So here's a direct link to Alan Cooper's books (like "The Inmates Are Running the Asylum").
To continue on the subject of how configurable a UI should be, I think it's very important to consider _what_ is configurable.
Take for example themeing. I couldn't care less for that shit. I have no time to fuck around with purtyfing a machine. I change machines too often and I use too many different machines.
On the other hand, say I start a large download from an FTP site and decide to go get a beer because it's a really large download that's going to take two hours, and while I'm gone, it bombs out at 50%, putting up a message box asking whether I want to retry or cancel, What The Fuck do the developers of that software think I would want to answer? Of course I want it to retry.
The alternative would be to write the software such that it would display the fact that it has problems, along with a 'cancel' button to quit anytime I like, but in the meantime it would continue to retry until it has what I wanted.
I mean the fact that I asked the fucking computer to download the file indicates that I want it right? Why would it need to ask me if I want to retry because of some technical glitch that I couldn't care less about?
Well, you catch my drift.
So, yes, I do want an option in the configuration that says "retry as long as I don't press cancel".
But I think too many configuration options are there because the developers are insecure about what's 'right'. Hidding the 'for experts only' options is a nice thing, but look at OS/X, they just said 'this is it, this is the right way' and they seem to be largely right.
At the end of the day, to make a product succesful, it's no good to have options to configure stuff that only one or two people care about. If you can have the UI present things in two different ways, and you have an evenly divided group of users that feel strongly that it should be either one way or the other, then yes, it should probably be configurable. Otherwise, screw it. Apparently not enough people complained about the fact that you have to hit 'Start' to shutdown your computer in Windows...
As mosfet writes:
Check this out to see a developers take on the whole "less-is-more" debate going on about Linux user interfaces
Now, I've no doubt he's a very gifted developer. But more often than not, a developers opinion on UI issues should be disregarded.
It's not because they couldn't potentially be good at it, it's because their brain is occupied with technical issues that have no relevance to an end-user.
Alan Cooper has written some pretty fine books about these issues, which I'm sure any developer related to UI design finds very informative. Some of the anecdotes are hilarious.
Unfortunately, it seems that Human Interaction Design is still not very high on the list when people design a product, resulting in there not being very many people that have specialized themselves in this field. It goes without saying that finding the right people for such a job for open source projects is tricky, to say the least.
First of all, I'll link to my post two days ago.
Intel however, doesn't seem to quite understand the issue. I mean, EFI is partially stored on the hardrive?! Sounds to me they are making things more complex, instead of less.
The quote " In effect, it's a tiny operating system in its own right," scares the shit out of me.
And all this hype about graphics, I mean, come on. I wrote a boot loader in 64K that booted straight into true color, 800x600 graphics mode, including a compressable image. It's not a big deal. And of course "With the BIOS, that's limited to VGA or worse" is horseshit, the BIOS can use the VESA BIOS to switch to any mode it desires. This is all a non-issue. It's been solved.
Yes, network diagnostics is good. But I'd rather have a secure network boot, because then I can do anything, including loading a remote OS even though the harddrive shat on itself.
The BIOS is the last place on the PC where people have to write in low-level assembler code, and we want to end that" he said. Instead, EFI is almost entirely written in C,
Bullshit, there are BIOSs that are written in C. Actually, my bootloader is written in C++. There.
so if your OS freezes you can go in and look at the state of the machine, change configuration, load a different driver, and do a sensible restart
Yeah right, I can totally see my mom do that. I've spent hours trying to get Windows XP Embedded to NOT probe a secondary IDE channel because it was not terminated correctly and would hang the boot, using the kernel debugger and all. Never got it to work. And this is going to all work just like that?
Finally, it can pretend to be a BIOS. "We're not expecting people to throw out the BIOS overnight, so EFI can support legacy systems by running on top of an existing BIOS and handing over control when appropriate."
Ah! I was wondering where that backwards compatibility was. I'm so happy that we are moving one step forwards and two steps back.
Yep, this probably sounds a flamebait, a silly rant, whatever. There's some good ideas there, but I don't think they are on the right track...
At the end of the day, the BIOS (boot loader) should be in Flash (ROM) so that it still works even if there's no harddrive. It should get the hell done with all hardware initialization and boot the frigin OS. Putting more complexity in the BIOS means more bugs, means more updates, means more security risks.