The initial seed ribbon will not support very much, obviously. Beyond that though, even the early ribbons are expected to lift up to 200 tons. This is by no means a limit, merely what is expected to be the safest and most economical course of development. Once the initial ribbon goes up, it is pretty much inevitable that much larger ones will follow.
Moreover, even the first ribbon is expected to have a payload capacity of 13 tons, and a trip to GEO will take about a week. The useable capacity is *far* greater than with any existing means of launch. (The shuttle can deliver less than 4 tons to GEO, and it certain can't launch 50 times a year.)
This is a bit too simplistic however, for two reasons. As things go up the ribbon, they get lighter. In actuality, you can get much more out of the ribbon by sending multiple climbers up at appropriately spaced intervals. Second, many things only need to go to LEO, so the frequency of "launches" could be much greater.
It is not necessary to store the waste for 3000 years. What needs to be done is to start building reactors which don't waste 99% of the fuel, like the ones currently in use. Moreover, if you don't waste all the fuel, there is very little waste to begin with.
The Integral Fast Reactor is a reactor design which basically addresses all concerns about nuclear power. Not only is it passively safe, the radioactive waste returns to original levels within 300 years.
"This is achieved through a signal implanted within the offscreen range (vertical blanking interval) of the video signal..."
So, of course it is removed--it is not part of the visible picture! Even if you could capture that junk, it would not serve its intended purpose anyway.
Thing is XML was desgiend to be readable and easy to parse.
XML is a miserable failure on both counts. It may technically be readable, but it is excruciating. Easy to parse, it most certainly is not. About the only thing it has going for it, is that it is an extensible standard.
This is a non-issue. With the typical fuel cycle for a fast reactor, producing weapons grade plutonium is basically impossible. It can be done, but you would need to run a completely different fuel cycle, explicitly for the purpose of producing plutonium. The only way for this to go unnoticed is to build and operate your own private reactor, so there is no more inherent danger.
An added benefit though, is that these reactors are capable of burning plutonium. As such, they can be used to dispose of our current stockpile. Actually, they can burn all sorts of stuff which is currently considered waste. After some on-site reprocessing, you continually send most of the material back through. (Current reactors only utilize something like a few % of the fuel and the remainder is the highly dangerous and long-lasting waste that everyone is so terrified of.) The minimal waste that is left over in an IFR, will reach background radiation levels in ~300 years.
Perhaps just as important, they are inherently safe from meltdown; if the cooling system fails, the reaction stops. This has even been tested in practice, and works as expected. Basically, it is a nearly ideal source of power from almost every aspect. All of the dangers and drawbacks of current designs have been addressed--what remains is to educate people about this clean, safe, and abundant source of power.
Below are links to the Wiki, and a sort of FAQ about the IFR. The latter addresses any concerns about proliferation.
One of the reasons proposed over at Arstechnica has to do with byte ordering. Currently on intel macs, all disk IO has to be byte swapped, degrading performance. ZFS on the other hand will store data in the machines native format.
Even so, all of the other features of ZFS are worth much more than this. If Apple is anything more than a consumer widget company now, ZFS should definitely be under consideration.
ZFS is far from "just another filesystem," and comparing it to existing filesystems indicates a lack of understanding. Take a look at this presentation for more information.
I can certainly see the value in explicit notification of page usage, but I have to wonder if this isn't attacking the problem at the wrong level. It seems that these problems are caused by the semantics of read() and write() calls, requiring data to be read/written to an arbitrarily aligned userspace buffers.
Zero copy can definitely make things complex, and in the current implementations, the value is arguable. (and being argued...) Still, memory copies have an associated cost. While they may be better than COW with explicit notification, it is still a performance hack, and represents a non-optimal way of dealing with data transfers. (It could be the easiest and best hack to be made, I can't say. In any case, Linus is acting like a git with his name calling here.)
Perhaps more consideration should be given to the API instead. Using zero copy is obviously a good goal, and it is primarily hindered by the ancient API and protocols. Something where the buffer management is explicit, and the devices themselves actually own the them. (After all, they are the only entities which know what the buffer requirements are.) Arranging it so that the user applications have access to the actual network buffers would be far preferable to playing any of these "games".
Unfortunately, Ethernet and the IP protocols are not particularly conducive to such an optimal implementation. With enough intelligence in the network adapters though, many of the issues should be manageable, and allow for a good zero copy implementation with a suitable API. It may be more trouble for the application, but if you need the performance, it is a small price to pay.
No offense, but the people who consider OSX stable are probably only those coming from Windows. Compared to any of the BSD's, or even Linux, OSX is a toy. It is definitely easier to configure, and that is worth something, but it is far behind in features, performance, and overall stability. (not only OS stability, but the development environment too. Cocoa and Obj-C are excellent, but the endless forced transitions are simply too much. Whatever is said about the x86 transition, the fact is that x86 will be soon obsolete, and then the x86-64 and 64 bit transitions are also in store.)
I had high hopes for Apple a few years ago, but recently their commitment to OSX as anything more than a vehicle for iLife/iTunes has been questionable. The user interface consistency continues to degrade with every release. The UNIX underpinnings also stagnate. Apple has added some great features, but after they become a bullet on a feature list, they seemingly languish eternally. They refuse to further expand upon and refine them, which is arguably worse than not adding them at all. To say that OSX has rough edges is a laughable understatement.
Anyways, this wasn't meant to be a rant, but I did want to make a few concrete points about the famed "stability."
Innumerable panics in the ATIRadeon9700 kext. Perhaps this is an exception, but the graphics drivers in my experience have been terrible.
With heavy NFS traffic, the machine (an iMac G5) completely wedges, not even a panic.
Files on UDF formatted discs start disappearing after the disc has been spun down. They need to be ejected and reinserted each time they become idle.
If I reboot my bridge, I have to manually restart the OSX networking before packets flow again. Networking and Samba/Finder/Beachball are particularly awful.
After a while the system alert sounds stop working, requiring a reboot.
These are only the most severe cases, the mere annoyances are too extensive to even start on.
All that said, OSX is still far preferable to any version of Windows. Unfortunately it lacks the application base of Windows; and if you need to reboot into Windows even sometimes, OSX may not even be worth the effort. After all, just keeping a Windows machine healthy is such a monumental effort, that you may as well use it.
Please Apple, spend some time on polishing the interface, and QA. Promote Cocoa and the Obj-C language beyond the mac platform. If you can't spare the resources to keep Darwin competitive, move the GUI onto Linux, BSD or even Solaris. (Actually, ZFS would be very nice to have...) At the rate things are going, your market will be reduced to those who can afford to use a Mac as an iPod accessory.
Not likely on the Intel side, but IBM has made good progress with the Power6. They have managed to keep the pipeline at 13 stages, while clocking it at 4-5GHz. This is in contrast to the P4 with its 31 stage pipeline and much higher power consumption. It seems that Intel has given up prematurely, or perhaps their process technology/ISA are not as amenable to such optimizations.
Now, frequency isn't everything, but performance scaling is nearly linear if you hold the pipeline depth constant. (And scale the bandwidth, which has also been done..) For more information about Power6, take a look at:
Do most Japanese even use the kana input? I think the romaji input is probably supepior.
There are 46 basic kana characters, but some characters require an additional voice mark. Unfortunately, these are located near the far upper right of the keyboard. Also, the small characters need to be shifted. If you were counting, you would notice that this is a *very* tight fit. With this layout, you don't have easy access to numbers, there is a whole lot of finger travel, and it appears to be rather brutal on your right pinky. (I considered learning it, but it looks to be far from optimal. It is insane that the standard keyboards put the most burden on the weakest fingers.)
That said, with a good romaji layout, you would only need two rows of keys. (Breaking the kana up into vowels + consanants basically requires 20 keys.) This could be made very optimal, and you basically don't need the shifted characters or the separate voicing marks.
Are there any optimized layouts such as this? The reduced travel, and extra keys available would definately be worth it.
On another note, the Windows IME completely sucks compared to the input system on the Mac. (That is when it is working at all; every now and then, it basically stops working until the next reboot. It also offers no method to type romaji in using dvorak, which is extremely obnoxious.)
What is with the VGA port? Are they that much more expensive than DVI? It seems that basically all boards with integrated graphics have this failing, and it is extremely annoying. While a DVI-VGA adapter is about $5, this choice alone excludes a huge chunk of the market.
Another thing which most of these SFF boards lack is dual ethernet, or at least gigE. So much for routers, file servers, and networked DVR's.
Oh well, while I am wishing for the impossible, why not remove the BIOS and add a serial console port as well.
There is actually a better way, and it is being implemented in DragonFlyBSD. Instead of duplicating writes at the device level, VFS operations are logged to a journal descriptor, which may be a file or network pipe. As this is performed in a VFS layer, it is possible to use with any filesystem. However, it is not limited to remotely (or locally) mirroring a filesystem; with the journal available, it will also be possible to rewind the state of the filesystem to any point in time, subject to the journal size.
So what you have is not only a real-time backup, but also the ability to unwind any possibly damage after a break-in or other event. If your backup server is only running a journalling client, it can be made extremely secure, and also provide an excellent auditing tool.
It would also be possible to delay the streams and have arbitrarily old filesystems available. Or to use a local journal as a buffer to smooth out the IO load as it is piped off site. It could also be used to augment a non-journalling filesystem, for crash recovery purposes, assuming your filesystem provides at least some consistency guarantees. In fact Netapp does something similar by logging FS operations to NVRAM, while the filesystem only writes consistentcy points periodically.
Although I haven't read about the NetBSD work, I am sceptical that they could get the error handling to work correctly at that level. With the DragonFly journalling, there is support for transactional consistency, as well as recovering from interrupted network connections. While it is not complete, much of it is in place and functional.
See the mountctl manual page for attaching a journal to a mount, and the jscan manual page for processing the journal.
As others have mentioned, DC is simply not a good alternative as you need very large conductors to make losses reasonable. This being the case, the best alternative would probably be 3-phase power.
3-phase AC is much more easily converted to DC, and also allows for simpler and more efficient motors. (So it is also ideal for things like air conditioners, refrigerators, furnaces, and such.) Overall, I think the advantages far outweigh the cost of an extra conductor, and it is unfortunate that it isn't more common outside of commercial settings.
Except that 64-bit CPUs are not only useful to access more RAM. While 64-bit code is usually slower than 32 bit on well designed architectures--on the register starved x86, the extra registers provided can allow for much improved performance.
Besides that, the extra VM space is very useful, even for machines with less than 4GB. There is usually a 2GB/2GB split between the kernel and user memory map, so 2GB is a more practical limit. As if thats not bad enough, running near that limit, you risk severely fragmenting the memory map.
While probably the least important, 64bit math is still useful in many cases. Now developers can't simply assume it is available.
Last, they now have to support three architectures! There is never any advantage to x86-32, yet they will always have to support it now. The fat binaries will now need to contain x86-64, x86-32, and PPC binaries. Beyond that, they will need to support an extra architecture for the kernel too.
After I experienced the unacceptably slow service that many people mentioned, I decided to cancel my membership. Conveniently, all the movies that I had in my possession were "lost" in the mail on the way back to Netflix. If it were one movie, I *might* believe it, but short of someone driving off with a Mailbox, or the earth swallowing it up, I think this is highly unlikely.
Perhaps this is Netflix policy, I don't know. At the time though, there was absolutely no contact information provided. In any case, return your movies before you cancel!
From what I have read, string theory seems very elegant; we simply lack the math to deal with it in a useful way. That is no fault of string theory, merely a hint that the we need to further our understanding, or that the universe is simply not conducive to modeling in such a naive fashion.
Actually, it really is much better than SSE2, and even SSE3. It is irrelevant how much time Apple on anyone else spends on optimizations, since you simply can't come close to the same FLOPS/cycle with SSEn. SSE is missing FMA and permute instructions, and both are really a huge loss. Best case real world example has Altivec at 35x faster than the scalar equivalent. It is very typical to see speedups of 10-15x with Altivec, but rarely can you even approach 2x with SSE. (Also note that SSE performance scales with HZ, so it is much worse on Yonah than the P4)
If you are interested in the real world implications, see this:
Apparently the iMovie compression/export times were "dramatically slower" on the intel machine. They didn't list the results, stating that it was likely a bug; probably just the lack of Altivec support though. I think the value of Altivec on the PowerPC will only become more apparent over time.
Is it the lawyers that companies keep on staff, actively trying to make themselves seem "useful," or is there really some bonehead at the company in a position of power who really believes that this is in Hasbro's best interests?
The settings for board games and online games are typically completely different, with very little overlap. You don't (typically) sit around at home and play a board game by yourself. Likewise, Hasbro doesn't even have a net capable product to offer. At worst, this would have generated more interest, and hence more sales of the game. Instead, they choose to pursue legal actions which will only anger people, and ensure that they will actively search for alternatives to their products.
While technically this wasn't an online multi-player game, such a version was rumored to be in development. I can't see that enough people would choose to huddle around a computer in this way to be any threat to their business. Certainly, if one likes to play chess, and has people available to play with, 99.9% of them would choose to buy a chess set.
that I have come across are biodiesel production from algae, and more recently the flying electric generator. The latter is only used for producing energy, but effective Hydrogen storage would make it even more useful. (Take a look, it really is an interesting idea, and should be perfectly feasible...)
Even so, in terms of energy density, it is hard to beat hydrocarbons, and the distribution system is already in place. Since the algae consume as much CO2 as is produced by the combustion of the diesel, there is no net increase in greenhouse gasses. It is effectively solar power, with an efficient energy carrier. In addition, the OPOC diesel engine, allows for very small size and high efficiency. (it is ~1lb/HP, or ~0.6g/W;) More details are available here.
Also, when flywheel energy storage matures a bit more, it should allow for some great improvements in electric and hybrid cars. Flywheels have extraordinary power density, and can be charged and dischared in seconds, which allows them to
recapture ~80% of the energy during braking, and provide for decent acceleration. There is some information at AFS Trinity, though the site could be a bit better. The basic ideas behind this flywheel tech are fascinating in themselves, but I've already wandered far enough off topic...
It will work, to some degree, yes. The problem is that with write caching, the data on separate discs can become (more than a little) inconsistent, and there is no way recover from this. After a power loss, you may be left with two very different file systems on each disc, and over time, these inconsistencies will compound, and lead to random crashes. The only way to repair this would be to do a full compare of both discs, as well as a full file system check after any power loss. Even so, this would only leave you with a consistent disc, not necessarily correct. NTFS and HFS+ probably just assume that the discs don't lie, and silently ignore the possibilty of file system corruption.
To ensure that a raid set stays healthy, you really need a journalling file system, and proper acknowledgements from the disc about what has been written. Otherwise, you can't depend on the journal after a crash, and you have no idea how the discs may be out of sync. ATA raid without proper tagged command queueing is just a bad idea--unless you make certain that power can be maintained in all circumstances.
I only bring this up because power loss probably occurs more frequently than discs dying, and most people are completely unaware of these issues. The toy-raid that you get with cheap ATA discs and motherboard controllers is not nearly as safe as the manufacturerts would have you believe. File system corruption should not be taken likely--you may experience data loss and crashes, even with raid.
RAID is dead weight with write caching!
on
Intel and Laptop RAID?
·
· Score: 2, Insightful
Until manufacturers start producing disks that behave well, and the OS supports it properly, RAID is probably a waste. Granted, you are less likely to lose power on a laptop, but it can still happen, and your file system will trash your data for you! Having two sets of data which may easily become incoherent probably makes raid more of a liability than an advantage.
As it stands today, 95% (probably more) of disks are completely unsafe to use if you value your data. While you may take comfort in having a journalling, or otherwise atomic file system, beware, it does not work properly with write caching!
Before this problem is addressed, any sort of ATA raid is laughable. Theoretically, this problem should be solved when all drives and controllers support NCQ, but I'm not holding my breath; there is still an option which allows discs to lie about the completion of commands, and if there is _any_ performance benefit, I'm betting the disc manufacturers will enable it by default instead valuing your data consistency.
Slashdot Mirror
The initial seed ribbon will not support very much, obviously. Beyond that though, even the early ribbons are expected to lift up to 200 tons. This is by no means a limit, merely what is expected to be the safest and most economical course of development. Once the initial ribbon goes up, it is pretty much inevitable that much larger ones will follow.
Moreover, even the first ribbon is expected to have a payload capacity of 13 tons, and a trip to GEO will take about a week. The useable capacity is *far* greater than with any existing means of launch. (The shuttle can deliver less than 4 tons to GEO, and it certain can't launch 50 times a year.)
This is a bit too simplistic however, for two reasons. As things go up the ribbon, they get lighter. In actuality, you can get much more out of the ribbon by sending multiple climbers up at appropriately spaced intervals. Second, many things only need to go to LEO, so the frequency of "launches" could be much greater.
The Integral Fast Reactor is a reactor design which basically addresses all concerns about nuclear power. Not only is it passively safe, the radioactive waste returns to original levels within 300 years.
"This is achieved through a signal implanted within the offscreen range (vertical blanking interval) of the video signal..."
So, of course it is removed--it is not part of the visible picture! Even if you could capture that junk, it would not serve its intended purpose anyway.
XML is a miserable failure on both counts. It may technically be readable, but it is excruciating. Easy to parse, it most certainly is not. About the only thing it has going for it, is that it is an extensible standard.
This is a non-issue. With the typical fuel cycle for a fast reactor, producing weapons grade plutonium is basically impossible. It can be done, but you would need to run a completely different fuel cycle, explicitly for the purpose of producing plutonium. The only way for this to go unnoticed is to build and operate your own private reactor, so there is no more inherent danger.
r
An added benefit though, is that these reactors are capable of burning plutonium. As such, they can be used to dispose of our current stockpile. Actually, they can burn all sorts of stuff which is currently considered waste. After some on-site reprocessing, you continually send most of the material back through. (Current reactors only utilize something like a few % of the fuel and the remainder is the highly dangerous and long-lasting waste that everyone is so terrified of.) The minimal waste that is left over in an IFR, will reach background radiation levels in ~300 years.
Perhaps just as important, they are inherently safe from meltdown; if the cooling system fails, the reaction stops. This has even been tested in practice, and works as expected. Basically, it is a nearly ideal source of power from almost every aspect. All of the dangers and drawbacks of current designs have been addressed--what remains is to educate people about this clean, safe, and abundant source of power.
Below are links to the Wiki, and a sort of FAQ about the IFR. The latter addresses any concerns about proliferation.
http://en.wikipedia.org/wiki/Integral_Fast_Reacto
http://www.nationalcenter.org/NPA378.html
Even so, all of the other features of ZFS are worth much more than this. If Apple is anything more than a consumer widget company now, ZFS should definitely be under consideration.
ZFS is far from "just another filesystem," and comparing it to existing filesystems indicates a lack of understanding. Take a look at this presentation for more information.
I can certainly see the value in explicit notification of page usage, but I have to wonder if this isn't attacking the problem at the wrong level. It seems that these problems are caused by the semantics of read() and write() calls, requiring data to be read/written to an arbitrarily aligned userspace buffers.
Zero copy can definitely make things complex, and in the current implementations, the value is arguable. (and being argued...) Still, memory copies have an associated cost. While they may be better than COW with explicit notification, it is still a performance hack, and represents a non-optimal way of dealing with data transfers. (It could be the easiest and best hack to be made, I can't say. In any case, Linus is acting like a git with his name calling here.)
Perhaps more consideration should be given to the API instead. Using zero copy is obviously a good goal, and it is primarily hindered by the ancient API and protocols. Something where the buffer management is explicit, and the devices themselves actually own the them. (After all, they are the only entities which know what the buffer requirements are.) Arranging it so that the user applications have access to the actual network buffers would be far preferable to playing any of these "games".
Unfortunately, Ethernet and the IP protocols are not particularly conducive to such an optimal implementation. With enough intelligence in the network adapters though, many of the issues should be manageable, and allow for a good zero copy implementation with a suitable API. It may be more trouble for the application, but if you need the performance, it is a small price to pay.
I had high hopes for Apple a few years ago, but recently their commitment to OSX as anything more than a vehicle for iLife/iTunes has been questionable. The user interface consistency continues to degrade with every release. The UNIX underpinnings also stagnate. Apple has added some great features, but after they become a bullet on a feature list, they seemingly languish eternally. They refuse to further expand upon and refine them, which is arguably worse than not adding them at all. To say that OSX has rough edges is a laughable understatement.
Anyways, this wasn't meant to be a rant, but I did want to make a few concrete points about the famed "stability."
All that said, OSX is still far preferable to any version of Windows. Unfortunately it lacks the application base of Windows; and if you need to reboot into Windows even sometimes, OSX may not even be worth the effort. After all, just keeping a Windows machine healthy is such a monumental effort, that you may as well use it.
Please Apple, spend some time on polishing the interface, and QA. Promote Cocoa and the Obj-C language beyond the mac platform. If you can't spare the resources to keep Darwin competitive, move the GUI onto Linux, BSD or even Solaris. (Actually, ZFS would be very nice to have...) At the rate things are going, your market will be reduced to those who can afford to use a Mac as an iPod accessory.
Now, frequency isn't everything, but performance scaling is nearly linear if you hold the pipeline depth constant. (And scale the bandwidth, which has also been done..) For more information about Power6, take a look at:
http://www.serverpipeline.com/showArticle.jhtml?ar ticleId=180200700&pgno=1
There are 46 basic kana characters, but some characters require an additional voice mark. Unfortunately, these are located near the far upper right of the keyboard. Also, the small characters need to be shifted. If you were counting, you would notice that this is a *very* tight fit. With this layout, you don't have easy access to numbers, there is a whole lot of finger travel, and it appears to be rather brutal on your right pinky. (I considered learning it, but it looks to be far from optimal. It is insane that the standard keyboards put the most burden on the weakest fingers.)
That said, with a good romaji layout, you would only need two rows of keys. (Breaking the kana up into vowels + consanants basically requires 20 keys.) This could be made very optimal, and you basically don't need the shifted characters or the separate voicing marks.
Are there any optimized layouts such as this? The reduced travel, and extra keys available would definately be worth it.
On another note, the Windows IME completely sucks compared to the input system on the Mac. (That is when it is working at all; every now and then, it basically stops working until the next reboot. It also offers no method to type romaji in using dvorak, which is extremely obnoxious.)
Another thing which most of these SFF boards lack is dual ethernet, or at least gigE. So much for routers, file servers, and networked DVR's.
Oh well, while I am wishing for the impossible, why not remove the BIOS and add a serial console port as well.
So what you have is not only a real-time backup, but also the ability to unwind any possibly damage after a break-in or other event. If your backup server is only running a journalling client, it can be made extremely secure, and also provide an excellent auditing tool.
It would also be possible to delay the streams and have arbitrarily old filesystems available. Or to use a local journal as a buffer to smooth out the IO load as it is piped off site. It could also be used to augment a non-journalling filesystem, for crash recovery purposes, assuming your filesystem provides at least some consistency guarantees. In fact Netapp does something similar by logging FS operations to NVRAM, while the filesystem only writes consistentcy points periodically.
Although I haven't read about the NetBSD work, I am sceptical that they could get the error handling to work correctly at that level. With the DragonFly journalling, there is support for transactional consistency, as well as recovering from interrupted network connections. While it is not complete, much of it is in place and functional.
See the mountctl manual page for attaching a journal to a mount, and the jscan manual page for processing the journal.
3-phase AC is much more easily converted to DC, and also allows for simpler and more efficient motors. (So it is also ideal for things like air conditioners, refrigerators, furnaces, and such.) Overall, I think the advantages far outweigh the cost of an extra conductor, and it is unfortunate that it isn't more common outside of commercial settings.
Besides that, the extra VM space is very useful, even for machines with less than 4GB. There is usually a 2GB/2GB split between the kernel and user memory map, so 2GB is a more practical limit. As if thats not bad enough, running near that limit, you risk severely fragmenting the memory map.
While probably the least important, 64bit math is still useful in many cases. Now developers can't simply assume it is available.
Last, they now have to support three architectures! There is never any advantage to x86-32, yet they will always have to support it now. The fat binaries will now need to contain x86-64, x86-32, and PPC binaries. Beyond that, they will need to support an extra architecture for the kernel too.
After I experienced the unacceptably slow service that many people mentioned, I decided to cancel my membership. Conveniently, all the movies that I had in my possession were "lost" in the mail on the way back to Netflix. If it were one movie, I *might* believe it, but short of someone driving off with a Mailbox, or the earth swallowing it up, I think this is highly unlikely. Perhaps this is Netflix policy, I don't know. At the time though, there was absolutely no contact information provided. In any case, return your movies before you cancel!
From what I have read, string theory seems very elegant; we simply lack the math to deal with it in a useful way. That is no fault of string theory, merely a hint that the we need to further our understanding, or that the universe is simply not conducive to modeling in such a naive fashion.
Yes, this is true. Don't forget, compiling a single file may recursively read in dozens of includes.
Actually, it really is much better than SSE2, and even SSE3. It is irrelevant how much time Apple on anyone else spends on optimizations, since you simply can't come close to the same FLOPS/cycle with SSEn. SSE is missing FMA and permute instructions, and both are really a huge loss. Best case real world example has Altivec at 35x faster than the scalar equivalent. It is very typical to see speedups of 10-15x with Altivec, but rarely can you even approach 2x with SSE. (Also note that SSE performance scales with HZ, so it is much worse on Yonah than the P4)
n ame=altivec&monthdir=200506&msg=msg00037.html
If you are interested in the real world implications, see this:
http://www.simdtech.org/altivec/archive/msg?list_
Apparently the iMovie compression/export times were "dramatically slower" on the intel machine. They didn't list the results, stating that it was likely a bug; probably just the lack of Altivec support though. I think the value of Altivec on the PowerPC will only become more apparent over time.
Is it the lawyers that companies keep on staff, actively trying to make themselves seem "useful," or is there really some bonehead at the company in a position of power who really believes that this is in Hasbro's best interests?
The settings for board games and online games are typically completely different, with very little overlap. You don't (typically) sit around at home and play a board game by yourself. Likewise, Hasbro doesn't even have a net capable product to offer. At worst, this would have generated more interest, and hence more sales of the game. Instead, they choose to pursue legal actions which will only anger people, and ensure that they will actively search for alternatives to their products.
While technically this wasn't an online multi-player game, such a version was rumored to be in development. I can't see that enough people would choose to huddle around a computer in this way to be any threat to their business. Certainly, if one likes to play chess, and has people available to play with, 99.9% of them would choose to buy a chess set.
Even so, in terms of energy density, it is hard to beat hydrocarbons, and the distribution system is already in place. Since the algae consume as much CO2 as is produced by the combustion of the diesel, there is no net increase in greenhouse gasses. It is effectively solar power, with an efficient energy carrier. In addition, the OPOC diesel engine, allows for very small size and high efficiency. (it is ~1lb/HP, or ~0.6g/W ;) More details are available here.
Also, when flywheel energy storage matures a bit more, it should allow for some great improvements in electric and hybrid cars. Flywheels have extraordinary power density, and can be charged and dischared in seconds, which allows them to recapture ~80% of the energy during braking, and provide for decent acceleration. There is some information at AFS Trinity, though the site could be a bit better. The basic ideas behind this flywheel tech are fascinating in themselves, but I've already wandered far enough off topic...
It will work, to some degree, yes. The problem is that with write caching, the data on separate discs can become (more than a little) inconsistent, and there is no way recover from this. After a power loss, you may be left with two very different file systems on each disc, and over time, these inconsistencies will compound, and lead to random crashes. The only way to repair this would be to do a full compare of both discs, as well as a full file system check after any power loss. Even so, this would only leave you with a consistent disc, not necessarily correct. NTFS and HFS+ probably just assume that the discs don't lie, and silently ignore the possibilty of file system corruption.
To ensure that a raid set stays healthy, you really need a journalling file system, and proper acknowledgements from the disc about what has been written. Otherwise, you can't depend on the journal after a crash, and you have no idea how the discs may be out of sync. ATA raid without proper tagged command queueing is just a bad idea--unless you make certain that power can be maintained in all circumstances.
I only bring this up because power loss probably occurs more frequently than discs dying, and most people are completely unaware of these issues. The toy-raid that you get with cheap ATA discs and motherboard controllers is not nearly as safe as the manufacturerts would have you believe. File system corruption should not be taken likely--you may experience data loss and crashes, even with raid.
Until manufacturers start producing disks that behave well, and the OS supports it properly, RAID is probably a waste. Granted, you are less likely to lose power on a laptop, but it can still happen, and your file system will trash your data for you! Having two sets of data which may easily become incoherent probably makes raid more of a liability than an advantage.
As it stands today, 95% (probably more) of disks are completely unsafe to use if you value your data. While you may take comfort in having a journalling, or otherwise atomic file system, beware, it does not work properly with write caching!
Before this problem is addressed, any sort of ATA raid is laughable. Theoretically, this problem should be solved when all drives and controllers support NCQ, but I'm not holding my breath; there is still an option which allows discs to lie about the completion of commands, and if there is _any_ performance benefit, I'm betting the disc manufacturers will enable it by default instead valuing your data consistency.