If they're not writeable, then they're all empty. Perhaps you meant not re-writeable?
Not writeable, period, as far as I can tell from the article - at least in home drives. You would stamp them in the production plant, and that would be it. The drive reads out the waviness of the plastic coating the metal substrate - there's no easy way to etch that yourself (you can't even use lasers to carve it, as the feature size is much too small).
This is an interesting device, but I'm leery of trying to use an AFM probe for readout. They're fragile, so I would suspect that the mean time before failure for these devices will be less than spectacular.
This is only one of many possible high-density storage technologies on the horizon. The article itself contains a link to many others; read them, and see what other interesting things are going on.
What the original poster is talking about is a massive sky hook, I think, which isn't a loop. Check out the link.
The article that you cite does mention that there has to be a return path; this would mean either a loop or other more exotic methods (such as the plasma gun suggested in the article).
The setup described is fundamentally different from what the original poster was suggesting, though - the sky hook generates power from the motion of the shuttle through the Earth's magnetic field. The original poster suggested stringing wires from the surface of the Earth upwards, which are stationary with respect to the Earth's magnetic field.
Any method of power generation that taps motion with respect to a magnetic field is actually just drawing power from the kinetic energy implicit in that motion - i.e., as you generate power, you slow down with respect to that field. For something in low earth orbit, like the shuttle using a sky hook as described, this will eventually degrade your orbit and bring you back to earth. The kinetic energy that you're tapping is also just the kinetic energy that you gave the shuttle during liftoff - so using this kind of scheme for power generating satellites is not useful, as you are just getting back the energy that you put into the satellite in the first place to put it in orbit.
There are other neat ways that you can use sky hooks, other neat things that you can do with extremely strong tethers, and ways of using tall towers to generate power on Earth, but these are beyond the scope of this discussion.
Nuclear fuel produces -enormous- amounts of highly radioactive waste
A minor quibble here - the amounts of waste produced are actually quite small. The energy density in nuclear fuels, even when burned in conventional, inefficient fission plants, is between four and five orders of magnitude higher than the energy density of fossil fuels. Correspondingly _less_ fuel is needed, and so you wind up with between 10,000 and 100,000 times less waste material than with fossil fuel plants.
Instead of a billion tonnes of coal burned to produce three billion tonnes of CO2, for instance, you'd get ten thousand tonnes of uranium oxide producing ten thousand tonnes of plutonium oxide and mixed nasty isotopes.
This is still not negligeable, but you could store this in a gymnasium with room to spare. Compared to a _billion_ tonnes of coal.
What we actually need is a reliable way of storing _small_ amounts of waste for very long periods of time. That, or transmuting it all into something with a shorter half-life (expensive).
Anyways, the ideal power source would be to string up a very long conductor from the earths surface to 100 or 200 kilometers into space. Hook up a small weight on the end to keep it in geosyncronous orbit and then reap the electricity coming off it in droves as it cuts through the earths magnetic field.
Um, no.
Firstly, in order for your weight to pull the wire outward, it has to be at or above the altitude at which geosynchronous orbits are normally found - about 40,000 km (about 25,000 miles). That's more than 100 or 200 km. The _wieght_ of this wire will be very substantial - enough that the tensile strength on the wire is far greater than any material currently in use can sustain. Find materials that can take these kinds of stresses, and we will be able to do far more interesting things than generating power.
Secondly, I think you mean the sun's magnetic field (carried outwards by the solar wind). The earth's magnetic field rotates with the earth - your wire will not be moving with respect to it, and so will generate no power from it. The sun's magnetic field will give you power, but it's open to question how much (could someone with the required numbers and background provide an estimate, please?).
Thirdly, you need a loop of wire to generate power from a magnetic field in this manner, not just a single wire. If you had magical cable that could withstand the required stresses, this could be built in the manner you describe, but that's a pretty big "if".
In summary, there are a lot of other methods that can be implemented _now_ that are more practical.
the only part of your cheerful little story that I don't buy into is the "rocks are radioactive" part of it. Some rocks are more than others. Some air is more radioactive than other air. Was the lichen radioactive due to naturally occuring exposure, such that it would have been the same level a century ago?
Actually, many types of rocks are radioactive (though something like, say, a spent fuel rod is a few orders of magnitude _more_ radioactive). There is actually a significant health hazard if the bricks and concrete in your basement are made from stone that is high in Thorium. As a part of its decay chain, Thorium becomes Radon, which is a radioactive gas (the heaviest of the inert gasses). This tends to collect in basements, giving you dangerous radiation exposure if you are exposed to it for years.
This has been happening for as long as rocks have existed on Earth.
Now, I'm not saying that nuclear power is without its dangers; I'm just pointing out that many rocks are indeed radioactive:).
This is built up frustration at the Slashdot moderators. They consistantly moderate posts incorrectly. The entire concept should be dropped.
I was here before the present moderation system was in place. It wasn't pretty. While some posts are unjustly moderated down (or up), the vast majority of moderation that I've seen has been deserved.
In this case - I agree that it was an informative post. However, the moderator that marked it down didn't agree. If other moderators think that it was informative, it will be marked up again.
Last but not least, the moderators are the _readers_. Read the moderator guideline documents, and the articles on the subject. If you browse slashdot regularly, and post, you _will_ get moderator access now and then. The whole "all moderators are corrupt" view looks a bit strained in this light.
A fair amount of light ? How about a few photons here and there. Any light that is disspersed will go in all directions. Trying to intercept such scattered light and properly demodulating and demultiplexing it would be extremely difficult without even considering encryption.
Ever go to an outdoor laser show? What you're seeing there _is_ scattered light, without the benefit of smoke generators.
The light is also being transmitted at a very specific, known frequency. Put a good quality filter on the tapper, and your signal-to-noise ratio improves considerably.
Want more signal? Place your receiver so that it's as close as it can be to looking down the beam.
You can't do laser communications over miles with a laser pointer. There is a very bright laser producing the beam, and a fair amonut of scattering.
You can't create a Beowulf Cluster using the BeOS. Putting aside the fact that the definition of a Beowulf cluster means that it runs on Linux, Linux alone will not be able to run on a Beowulf either. Certain security issues and kernal issues have to be resolved before it can run over a parallel processing computer.
That assumes that you want to run the OS itself as a shared process. If all you want is a distributed application, this isn't necessary (though kernel support of shared memory helps, as another poster pointed out).
Anyone have any ideas? As far as I understand it, the DEC Tulip chipset is supported...
I've heard other people report problems with this chipset too. Send in a bug report to Be (check their web page). They'll either revise it themselves (if it was an internally written driver) or get the contractor to revise it if it was something that they paid for.
Re. the NE2000 compatible card, in principle that should work with the "NE2000" setting. In practice, who knows.
From a purely diagnostics point of view, I'd suggest trying each of the cards individually, to see if having the two cards in at once is causing problems (the uninitialized card may be causing bus or IRQ contention).
For one thing, you can't add distributed shared memory support to the kernel.
True. However, depending on the application, workarounds could suffice. A scheme that I speculated about would have a "lock memory region" command that you would call before accessing a data structure, that paged it in from the remote box that it was stored on if necessary, and also handled coherence. You would unlock it when you were finished with it. This would have substantial overhead, but for many classes of problem it would be adequate.
Similarly, for many classes of problem just a set of distributed clients with their own memory spaces would work. It all depends on what you are trying to do.
However, Sounds like it could all get expensive, $50-60 a copy per node.
Um, the boxes that you are clustering will probably cost enough to make $50-$60 utterly insignificant, even if you use cheap celeries. My cost estimate for building a cluster of my own was about $400 US per node for just hardware (still haven't done it yet, in case you were wondering).
Probably because of "first post" in the subject line.
Re. moderators being stupid, remember that hundreds of moderators will read your message. Any incidental stupidity will average out - so your final score probably _will_ reflect what the average active slashdotter thinks it should be. If you disagree with this, well and good, but that reflects a difference of opinion as opposed to "stupidity" on the moderators' part.
Moot point for the moment, though, as this has only been up an hour or two.
While PVM, MPI, etc. might need tweaking to be ported, I don't see why you couldn't do distributed processing over BeOS boxes. I've been toying with the idea of implementing something like that myself in my (mythical) free time.
In practice, you can set up clusters on just about any system that supports both multithreading and networking. YMMV.
The idea is pretty cool, but if you are transmiting several differnt frequencies at once will you not also need several emiters for each frequency and what happens if one of them gets out of alignment.
That depends on the modulation and mixing schemes that they use. By the time the carrier reaches the output, it's been multiplexed on to one beam, so lining up several emitters shouldn't be necessary.
OTOH, the transmitting and receiving mirrors will have to be aligned very precisely. There are a few ways to do this (even ways to do this automatically). Solving this is picky but not intrinsically difficult.
Come to think of it with that much band width the television / movie bizz has got to be excited. This has got to be cheaper than a satalite uplink and if there is a remote even within the usable range of this tech all they have to do is set up and shoot the video down it.
It would probably wind up being more expensive than satellite for TV broadcasting, actually, because TV is _broadcasting_ - using one (espensive) satellite to send data to many, many homes. The cost of the satellite is amortized over the number of viewers that it serves. A laser link, OTOH, only serves one user.
Where it would be more useful is in transmission of TV data from the master station to other distributing stations, but they already have microwave links in place for this (that's what all of those towers in the countryside with dishes and ariels on them do, among other things). Lasers would give higher bandwidth, but how many cable channels do they want to transmit?
What is the efective range of this anyway?
That depends on several things, but a previous poster said single-digit kilometres (or miles, if you prefer). This sounds reasonable. Haze in the air will scatter the beam after a while even in clear weather.
It's a laser beam going from roof to roof. Eavesdroppers will have to intercept this beam. It's much easier to dig up a cable and tap that.
Not really. If there is dust, smog, or rain in the air, a fair amount of the light will scatter. With proper equipment, it wouldn't be too hard to tap the beam.
I am fully aware that games are getting more complex then those of earlier years, but there is still no doubt in my mind that code still could be optimized. And my comment goes beyond just games; but applications and Operating Systems as well...
Again Linux is the exception....
Correction: Windows is the exception. See the post that I referred to.
Re. games, I realize that most game software isn't perfectly tuned, but all of the "boost FPS by 50%" optimizations will already have been made, because it is in the game company's financial interest to do so - as a result of this optimization, they can either lower the system requirements or keep the frame rate and jack up the graphics detail. Both correlate directly to better sales.
From where do you get the impression that games are horribly written?
What is the point in making faster computers? Just gives software companies the ability to slack off a bit...
Please click on "user info" above and see my previous response in this thread. It is a reply to another poster who presented almost identical arguments.
Never, if the gaming companies have anything to do with it. As processors and memory become faster, games become more bloated and less well-written.
Um, no. New games require more hardware because they have fancier special effects and more detailed models. This is not really related to code complexity. It makes the _data_files_ larger, naturally, but that's about it.
Granted, there are some game writers who consider special effects a reasonable substitute for gameplay and plotting. These writers' games will sink, however, because consumers do want games that are actually fun to play.
Re. hardware vs. games, game hardware requirements will plateau when cheap hardware exists that can handle just about all of the special effects in the OpenGL feature set for photorealistic models at high resolution in real-time. Beyond that, there isn't anything left to add hardware load on the graphics side of things.
Things like AI and physics may continue to develop after that, but physics at least won't add much more load if you have hardware that powerful.
Added to that, processor design has become more bloated, moving deeper into a large, complex instruction set. Simpler processors, such as the ARM, outpaced the Intel chips even at a fraction of the clockspeed, because they were better designed.
Um, no. Look at just about any non-Intel processor. Intel chips are bloated because Intel continues to support and extend an instruction set that wasn't designed to be extensible. They're about the only major microprocessor manufacturer that made this mistake.
Also, didn't ARM not _have_ a floating-point unit? With more silicon to devote, of course they'll be faster at integer operations.
Finally, throw in that most modern OS' are bloated and top-heavy, Linux being one notable exception
And *BSD and BeOS and...
Microsoft is the primary culprit for slow OSs. This is because Microsoft is purely market-driven, and the market that they cater to would rather buy a new version of the OS with more features than a new version of the OS that works more efficiently.
OSs and chips can be designed cleanly - and _are_, with only a few exceptions. Take a look around at what's available, and you may be pleasantly surprised.
It is a pitty that we'll have to forget that old machine code, which some of us got so attached to.
Does it also mean that it is a bad idea to buy an "old" PentiumIII processor ?
Software written for the Merced may not run on a PIII, but software written for older x86s will still run on the Merced. Just as current x86 chips can emulate "real mode" for older apps, so the Merced will be able to use and/or emulate the processing modes used in current x86s.
A dedicated x86 clone - like the K7 - will be able to run these applications faster. However, _if_ they did a good job on the Merced's core, applications written natively for the Merced will run faster than applications written natively for the K7, as the K7 will still be hampered by the x86 instruction set and register structure.
_If_ Intel did a good job on the Merced core, it will be fast but still 1.5x as expensive as other RISC solutions due to the extra silicon needed to support x86 legacy features.
However, I gather that they may not have done such a good job on the core. We'll see when prototypes are benchmarked.
Anyone care to hazard a guess how much energy can be extracted from your typing fingers, relative to how much energy the laptop consumes?
Sure. This is actually pretty easy.
Assume that the force required to press a key is at most 1 N (roughly the force exerted by a 100g weght). More than this and I'm not using the keyboard:).
Assume that the keys move at most 1 cm (0.01 m) down when you press them. More than this gets silly.
Assume that I hit at most 10 keys per second sustained typing rate.
Energy per keystroke is force * distance, or 0.01 J. Keystrokes per second times energy per keystroke gives energy per second (or power), which is 0.1 W.
So, it doesn't look like this is viable unless we have *really* low power notebooks:).
PPCLinux. It didn't suit Apple. So specs were withheld. Same with BeOS (sorta.. Be is a diff case)
That's a BS lie passed areound by Be Inc. so that they can only develop new stuff for Intel. LinuxPPC runs on every Mac Apple sells, including the B&W G3s and the iMac. Why can LinuxPPC do it and Be can't, especially when the LinuxPPC source code is open-source?
Click on "user info" above and see my previous response.
If Linux doesn't work on a particular G3 system, the user thinks "Oh well, we haven't reverse-engineered this one yet. I'll wait for the next patch.".
If BeOS doesn't work on a particular G3 system, the user thinks "This CD that I paid for doesn't work. BeOS sucks.".
Be _has_ to be able to guarantee that its OS will work on all or nearly all systems - and will continue to work without modification until the next major revision is released. Without Apple's cooperation, they can't do that.
Be is run by a bunch of lazy idiots. If they could get their OS to run on machines in the past without specs AND LinuxPPC AND YellowDog can get their OS to run on any Mac (even G3s and iMacs) without any specs then why can't Be make it run on G3s?
Because Linux can get away with partial support for a long time.
If a Linux distribution works on some but not all G3-based systems, Linux advocates will download it or buy it anyways. If it works, great. If their system is a variant that isn't yet supported, well, they haven't lost that much. Sooner or later the hardware specs are reverse-engineered and it works. By that time, Apple has introduced another hardware variant, and the cycle continues.
BeOS caters to a different audience. They aren't people who like being into cutting-edge software development - they're working on other things (various types of art and other media-related work). They want to put in the CD and watch it go. They aren't going to pay money for a CD that might or might not work on their system.
Linux can afford to come out with incremental patches that support progressively more systems, because that's the way Linux works and what users are used to. Be can't. They make a single, polished release, and possibly a maintainence release a few months down the road. That's it. Those have to support all hardware until the next major release comes out.
With Apple not giving out specs and possibly changing specs at whim to foil reverse-engineering, Be can't guarantee that their releases will work. So, they can't sell for G3-based systems.
If the specs were given, it actually wouldn't take that much more work to support both platforms. BeOS was originally written with that in mind, and so were most of the drivers under BeOS. But, Apple isn't cooperating and Intel is, so Apple support is shelved.
With 1.1, the removed the nasty termination clause.
Actually, no. In 1.1 they properly defined "covered code" and "larger work", and loosened the requirement to send updates to their site (so that the license isn't invalidated if their site goes down).
There is still vague language in the termination clause that can cause the entire license to be terminated if there is a legal dispute. The license to all of the code - not just the part being disputed. All of the license - not just saying that you can't distribute it.
Well just looking at another view of this, talking about the bone breaking and blood loss ect. One could gather that this could use quite well in the medical research feild.
You miss my point - QC might *not* do this any better than standard computers.
Slashdot Mirror
Not writeable, period, as far as I can tell from the article - at least in home drives. You would stamp them in the production plant, and that would be it. The drive reads out the waviness of the plastic coating the metal substrate - there's no easy way to etch that yourself (you can't even use lasers to carve it, as the feature size is much too small).
This is only one of many possible high-density storage technologies on the horizon. The article itself contains a link to many others; read them, and see what other interesting things are going on.
The article that you cite does mention that there has to be a return path; this would mean either a loop or other more exotic methods (such as the plasma gun suggested in the article).
The setup described is fundamentally different from what the original poster was suggesting, though - the sky hook generates power from the motion of the shuttle through the Earth's magnetic field. The original poster suggested stringing wires from the surface of the Earth upwards, which are stationary with respect to the Earth's magnetic field.
Any method of power generation that taps motion with respect to a magnetic field is actually just drawing power from the kinetic energy implicit in that motion - i.e., as you generate power, you slow down with respect to that field. For something in low earth orbit, like the shuttle using a sky hook as described, this will eventually degrade your orbit and bring you back to earth. The kinetic energy that you're tapping is also just the kinetic energy that you gave the shuttle during liftoff - so using this kind of scheme for power generating satellites is not useful, as you are just getting back the energy that you put into the satellite in the first place to put it in orbit.
There are other neat ways that you can use sky hooks, other neat things that you can do with extremely strong tethers, and ways of using tall towers to generate power on Earth, but these are beyond the scope of this discussion.
A minor quibble here - the amounts of waste produced are actually quite small. The energy density in nuclear fuels, even when burned in conventional, inefficient fission plants, is between four and five orders of magnitude higher than the energy density of fossil fuels. Correspondingly _less_ fuel is needed, and so you wind up with between 10,000 and 100,000 times less waste material than with fossil fuel plants.
Instead of a billion tonnes of coal burned to produce three billion tonnes of CO2, for instance, you'd get ten thousand tonnes of uranium oxide producing ten thousand tonnes of plutonium oxide and mixed nasty isotopes.
This is still not negligeable, but you could store this in a gymnasium with room to spare. Compared to a _billion_ tonnes of coal.
What we actually need is a reliable way of storing _small_ amounts of waste for very long periods of time. That, or transmuting it all into something with a shorter half-life (expensive).
Um, no.
Firstly, in order for your weight to pull the wire outward, it has to be at or above the altitude at which geosynchronous orbits are normally found - about 40,000 km (about 25,000 miles). That's more than 100 or 200 km. The _wieght_ of this wire will be very substantial - enough that the tensile strength on the wire is far greater than any material currently in use can sustain. Find materials that can take these kinds of stresses, and we will be able to do far more interesting things than generating power.
Secondly, I think you mean the sun's magnetic field (carried outwards by the solar wind). The earth's magnetic field rotates with the earth - your wire will not be moving with respect to it, and so will generate no power from it. The sun's magnetic field will give you power, but it's open to question how much (could someone with the required numbers and background provide an estimate, please?).
Thirdly, you need a loop of wire to generate power from a magnetic field in this manner, not just a single wire. If you had magical cable that could withstand the required stresses, this could be built in the manner you describe, but that's a pretty big "if".
In summary, there are a lot of other methods that can be implemented _now_ that are more practical.
Actually, many types of rocks are radioactive (though something like, say, a spent fuel rod is a few orders of magnitude _more_ radioactive). There is actually a significant health hazard if the bricks and concrete in your basement are made from stone that is high in Thorium. As a part of its decay chain, Thorium becomes Radon, which is a radioactive gas (the heaviest of the inert gasses). This tends to collect in basements, giving you dangerous radiation exposure if you are exposed to it for years.
This has been happening for as long as rocks have existed on Earth.
Now, I'm not saying that nuclear power is without its dangers; I'm just pointing out that many rocks are indeed radioactive
I was here before the present moderation system was in place. It wasn't pretty. While some posts are unjustly moderated down (or up), the vast majority of moderation that I've seen has been deserved.
In this case - I agree that it was an informative post. However, the moderator that marked it down didn't agree. If other moderators think that it was informative, it will be marked up again.
Last but not least, the moderators are the _readers_. Read the moderator guideline documents, and the articles on the subject. If you browse slashdot regularly, and post, you _will_ get moderator access now and then. The whole "all moderators are corrupt" view looks a bit strained in this light.
Ever go to an outdoor laser show? What you're seeing there _is_ scattered light, without the benefit of smoke generators.
The light is also being transmitted at a very specific, known frequency. Put a good quality filter on the tapper, and your signal-to-noise ratio improves considerably.
Want more signal? Place your receiver so that it's as close as it can be to looking down the beam.
You can't do laser communications over miles with a laser pointer. There is a very bright laser producing the beam, and a fair amonut of scattering.
That assumes that you want to run the OS itself as a shared process. If all you want is a distributed application, this isn't necessary (though kernel support of shared memory helps, as another poster pointed out).
I've heard other people report problems with this chipset too. Send in a bug report to Be (check their web page). They'll either revise it themselves (if it was an internally written driver) or get the contractor to revise it if it was something that they paid for.
Re. the NE2000 compatible card, in principle that should work with the "NE2000" setting. In practice, who knows.
From a purely diagnostics point of view, I'd suggest trying each of the cards individually, to see if having the two cards in at once is causing problems (the uninitialized card may be causing bus or IRQ contention).
True. However, depending on the application, workarounds could suffice. A scheme that I speculated about would have a "lock memory region" command that you would call before accessing a data structure, that paged it in from the remote box that it was stored on if necessary, and also handled coherence. You would unlock it when you were finished with it. This would have substantial overhead, but for many classes of problem it would be adequate.
Similarly, for many classes of problem just a set of distributed clients with their own memory spaces would work. It all depends on what you are trying to do.
Um, the boxes that you are clustering will probably cost enough to make $50-$60 utterly insignificant, even if you use cheap celeries. My cost estimate for building a cluster of my own was about $400 US per node for just hardware (still haven't done it yet, in case you were wondering).
Probably because of "first post" in the subject line.
Re. moderators being stupid, remember that hundreds of moderators will read your message. Any incidental stupidity will average out - so your final score probably _will_ reflect what the average active slashdotter thinks it should be. If you disagree with this, well and good, but that reflects a difference of opinion as opposed to "stupidity" on the moderators' part.
Moot point for the moment, though, as this has only been up an hour or two.
In practice, you can set up clusters on just about any system that supports both multithreading and networking. YMMV.
That depends on the modulation and mixing schemes that they use. By the time the carrier reaches the output, it's been multiplexed on to one beam, so lining up several emitters shouldn't be necessary.
OTOH, the transmitting and receiving mirrors will have to be aligned very precisely. There are a few ways to do this (even ways to do this automatically). Solving this is picky but not intrinsically difficult.
Come to think of it with that much band width the television / movie bizz has got to be excited. This has got to be cheaper than a satalite uplink and if there is a remote even within the usable range of this tech all they have to do is set up and shoot the video down it.
It would probably wind up being more expensive than satellite for TV broadcasting, actually, because TV is _broadcasting_ - using one (espensive) satellite to send data to many, many homes. The cost of the satellite is amortized over the number of viewers that it serves. A laser link, OTOH, only serves one user.
Where it would be more useful is in transmission of TV data from the master station to other distributing stations, but they already have microwave links in place for this (that's what all of those towers in the countryside with dishes and ariels on them do, among other things). Lasers would give higher bandwidth, but how many cable channels do they want to transmit?
What is the efective range of this anyway?
That depends on several things, but a previous poster said single-digit kilometres (or miles, if you prefer). This sounds reasonable. Haze in the air will scatter the beam after a while even in clear weather.
Not really. If there is dust, smog, or rain in the air, a fair amount of the light will scatter. With proper equipment, it wouldn't be too hard to tap the beam.
Again Linux is the exception....
Correction: Windows is the exception. See the post that I referred to.
Re. games, I realize that most game software isn't perfectly tuned, but all of the "boost FPS by 50%" optimizations will already have been made, because it is in the game company's financial interest to do so - as a result of this optimization, they can either lower the system requirements or keep the frame rate and jack up the graphics detail. Both correlate directly to better sales.
From where do you get the impression that games are horribly written?
Please click on "user info" above and see my previous response in this thread. It is a reply to another poster who presented almost identical arguments.
Um, no. New games require more hardware because they have fancier special effects and more detailed models. This is not really related to code complexity. It makes the _data_files_ larger, naturally, but that's about it.
Granted, there are some game writers who consider special effects a reasonable substitute for gameplay and plotting. These writers' games will sink, however, because consumers do want games that are actually fun to play.
Re. hardware vs. games, game hardware requirements will plateau when cheap hardware exists that can handle just about all of the special effects in the OpenGL feature set for photorealistic models at high resolution in real-time. Beyond that, there isn't anything left to add hardware load on the graphics side of things.
Things like AI and physics may continue to develop after that, but physics at least won't add much more load if you have hardware that powerful.
Added to that, processor design has become more bloated, moving deeper into a large, complex instruction set. Simpler processors, such as the ARM, outpaced the Intel chips even at a fraction of the clockspeed, because they were better designed.
Um, no. Look at just about any non-Intel processor. Intel chips are bloated because Intel continues to support and extend an instruction set that wasn't designed to be extensible. They're about the only major microprocessor manufacturer that made this mistake.
Also, didn't ARM not _have_ a floating-point unit? With more silicon to devote, of course they'll be faster at integer operations.
Finally, throw in that most modern OS' are bloated and top-heavy, Linux being one notable exception
And *BSD and BeOS and...
Microsoft is the primary culprit for slow OSs. This is because Microsoft is purely market-driven, and the market that they cater to would rather buy a new version of the OS with more features than a new version of the OS that works more efficiently.
OSs and chips can be designed cleanly - and _are_, with only a few exceptions. Take a look around at what's available, and you may be pleasantly surprised.
Does it also mean that it is a bad idea to buy an "old" PentiumIII processor ?
Software written for the Merced may not run on a PIII, but software written for older x86s will still run on the Merced. Just as current x86 chips can emulate "real mode" for older apps, so the Merced will be able to use and/or emulate the processing modes used in current x86s.
A dedicated x86 clone - like the K7 - will be able to run these applications faster. However, _if_ they did a good job on the Merced's core, applications written natively for the Merced will run faster than applications written natively for the K7, as the K7 will still be hampered by the x86 instruction set and register structure.
_If_ Intel did a good job on the Merced core, it will be fast but still 1.5x as expensive as other RISC solutions due to the extra silicon needed to support x86 legacy features.
However, I gather that they may not have done such a good job on the core. We'll see when prototypes are benchmarked.
Sure. This is actually pretty easy.
Energy per keystroke is force * distance, or 0.01 J. Keystrokes per second times energy per keystroke gives energy per second (or power), which is 0.1 W.
So, it doesn't look like this is viable unless we have *really* low power notebooks
That's a BS lie passed areound by Be Inc. so that they can only develop new stuff for Intel. LinuxPPC runs on every Mac Apple sells, including the B&W G3s and the iMac. Why can LinuxPPC do it and Be can't, especially when the LinuxPPC source code is open-source?
Click on "user info" above and see my previous response.
If Linux doesn't work on a particular G3 system, the user thinks "Oh well, we haven't reverse-engineered this one yet. I'll wait for the next patch.".
If BeOS doesn't work on a particular G3 system, the user thinks "This CD that I paid for doesn't work. BeOS sucks.".
Be _has_ to be able to guarantee that its OS will work on all or nearly all systems - and will continue to work without modification until the next major revision is released. Without Apple's cooperation, they can't do that.
Because Linux can get away with partial support for a long time.
If a Linux distribution works on some but not all G3-based systems, Linux advocates will download it or buy it anyways. If it works, great. If their system is a variant that isn't yet supported, well, they haven't lost that much. Sooner or later the hardware specs are reverse-engineered and it works. By that time, Apple has introduced another hardware variant, and the cycle continues.
BeOS caters to a different audience. They aren't people who like being into cutting-edge software development - they're working on other things (various types of art and other media-related work). They want to put in the CD and watch it go. They aren't going to pay money for a CD that might or might not work on their system.
Linux can afford to come out with incremental patches that support progressively more systems, because that's the way Linux works and what users are used to. Be can't. They make a single, polished release, and possibly a maintainence release a few months down the road. That's it. Those have to support all hardware until the next major release comes out.
With Apple not giving out specs and possibly changing specs at whim to foil reverse-engineering, Be can't guarantee that their releases will work. So, they can't sell for G3-based systems.
If the specs were given, it actually wouldn't take that much more work to support both platforms. BeOS was originally written with that in mind, and so were most of the drivers under BeOS. But, Apple isn't cooperating and Intel is, so Apple support is shelved.
Actually, no. In 1.1 they properly defined "covered code" and "larger work", and loosened the requirement to send updates to their site (so that the license isn't invalidated if their site goes down).
There is still vague language in the termination clause that can cause the entire license to be terminated if there is a legal dispute. The license to all of the code - not just the part being disputed. All of the license - not just saying that you can't distribute it.
IMO, this needs to be fixed.
You miss my point - QC might *not* do this any better than standard computers.