No, all the extra firmware will load one device at a time. So you get to see all 4 NICs load their firmware, your onboard SAS controller loads its RAID stuff, then your fibre-channel HBAs, your BIOS does its thing, and so forth and so on, not necessarily in that order, and all in serial.
One of the reasons things are done this way is that generally each device's firmware will give the operator an opportunity to modify settings as it boots, so it will ask you to hit a key or some combination of keys and then wait a number of seconds for that to happen.
If we had some fancy modifications to LinBIOS maybe you could just tell the BIOS that you want to get into the firmware options for X device and then it would take you right to it, while skipping all the waiting for input.
But, alas, we don't, so we just wait for 5 or 10 minutes while the server boots.
It takes place in a flat desert yes, but that desert is also the Black Rock Desert-High Rock Canyon Emigrant Trails National Conservation Area, and there's only one road in or out of the area, meaning that letting people just drive off over the desert will tear up the earth (and damage the ecosystem there) and allow people to try to jump on to the road anywhere they please, leading to slowdowns and accidents.
I know printing it out in binary format has already been mentioned, but there is actually a tool for this. If you use high quality paper, it might last for centuries.
Why don't you do everyone a favor and read the article? The writer explicitly states that you can rest your arm and only move the controller with your wrist with great accuracy.
Don't forget that many decent RAID controllers will have either integrated or upgradeable cache memory, often 128MB or greater. That can decrease latency significantly, especially compared to a single disk with a much smaller cache.
With newer monitors and XF86 4.x you can just use Option "DPMS" in the monitor section and not worry about knowing the refresh rates. It's unfortunate that there's no way (at least that I'm aware of) of specifying that when using the XF86Config script, but I suppose that's another good reason for a fork/branch.
There are in fact fuel cells that work both ways, creating current from combining hydrogen and oxygen and also flowing backwards to electrolyze water back into hydrogen and oxygen. Some of the energy required for the electrolysis could come from regenerative braking, or turning the motor backwards when going downhill.
Further, as stated the power has to come from somewhere, and there are always the renewable options of solar power, wind, hydroelectric and others. The article says that the study makes the assumption that hydrogen would come from hydrocarbons, which is one of the things that can be totally avoided with forethought. Why not just plug your car in when you get home at night, and have a full tank in the morning? Even electrolysis off of grid power is more efficient (though still a source of pollution) than many inefficient combustion engines.
Exactly, the point of higher fps is so that when you get more geometry in the game, moving at high speeds, etc. and the framerate drops, it's not as much of a bump-down, and won't disturb your gameplay too much. A good thing to remember is that most fps benchmarking utilities (like the one built into the quakes) are based on the average framerate rather than the minimum one..the most important number, as far as I'm concerned, is the minimum FPS that a game reaches, rather than the average. Also, from what I've seen, alot of these numbers are based on 640x480 or whatever...I don't know anyone who plays at that sort of resolution for normal gameplay...
Slashdot Mirror
No, all the extra firmware will load one device at a time. So you get to see all 4 NICs load their firmware, your onboard SAS controller loads its RAID stuff, then your fibre-channel HBAs, your BIOS does its thing, and so forth and so on, not necessarily in that order, and all in serial.
One of the reasons things are done this way is that generally each device's firmware will give the operator an opportunity to modify settings as it boots, so it will ask you to hit a key or some combination of keys and then wait a number of seconds for that to happen.
If we had some fancy modifications to LinBIOS maybe you could just tell the BIOS that you want to get into the firmware options for X device and then it would take you right to it, while skipping all the waiting for input.
But, alas, we don't, so we just wait for 5 or 10 minutes while the server boots.
It takes place in a flat desert yes, but that desert is also the Black Rock Desert-High Rock Canyon Emigrant Trails National Conservation Area, and there's only one road in or out of the area, meaning that letting people just drive off over the desert will tear up the earth (and damage the ecosystem there) and allow people to try to jump on to the road anywhere they please, leading to slowdowns and accidents.
Scotty?
I know printing it out in binary format has already been mentioned, but there is actually a tool for this. If you use high quality paper, it might last for centuries.
Here's the (free) software: http://ronja.twibright.com:8080/optar/
Hey,
Why don't you do everyone a favor and read the article? The writer explicitly states that you can rest your arm and only move the controller with your wrist with great accuracy.
Don't forget that many decent RAID controllers will have either integrated or upgradeable cache memory, often 128MB or greater. That can decrease latency significantly, especially compared to a single disk with a much smaller cache.
With newer monitors and XF86 4.x you can just use Option "DPMS" in the monitor section and not worry about knowing the refresh rates. It's unfortunate that there's no way (at least that I'm aware of) of specifying that when using the XF86Config script, but I suppose that's another good reason for a fork/branch.
There are in fact fuel cells that work both ways, creating current from combining hydrogen and oxygen and also flowing backwards to electrolyze water back into hydrogen and oxygen. Some of the energy required for the electrolysis could come from regenerative braking, or turning the motor backwards when going downhill.
Further, as stated the power has to come from somewhere, and there are always the renewable options of solar power, wind, hydroelectric and others. The article says that the study makes the assumption that hydrogen would come from hydrocarbons, which is one of the things that can be totally avoided with forethought. Why not just plug your car in when you get home at night, and have a full tank in the morning? Even electrolysis off of grid power is more efficient (though still a source of pollution) than many inefficient combustion engines.
More like special monitors, and video cards to match. Normal pixels are only capable of red green and blue, thus the extra colors aren't represented.
Exactly, the point of higher fps is so that when you get more geometry in the game, moving at high speeds, etc. and the framerate drops, it's not as much of a bump-down, and won't disturb your gameplay too much. A good thing to remember is that most fps benchmarking utilities (like the one built into the quakes) are based on the average framerate rather than the minimum one..the most important number, as far as I'm concerned, is the minimum FPS that a game reaches, rather than the average. Also, from what I've seen, alot of these numbers are based on 640x480 or whatever...I don't know anyone who plays at that sort of resolution for normal gameplay...