Although this bug should have been caught faster it seems that it is possible to update the firmware without any data loss (fortunately I have put it in a laptop, power outages are no problem). I've looked at the Intel site and the flash utility seems to be simply bootable from CD - if this is the last bug I'll be a very happy punter indeed.
My 80 GB G2 SSD replaced a not too fast laptop drive. I'm now trying Linux, but I'll try Vista as well just for fun - I'll just write my 80 GB to an external drive using Gparted. These drives come highly recommended even if they would slow down to 50% of performance (which, it seems, they don't). I unzipped Eclipse to it and JavaDoc and I could see that the archiver that unzipped the.zip has some performance issues reading the index. It took longer than the unzipping and gunzipping and untarring (the Eclipse gunzipping/untarring took less than 2 seconds - yikes). The only thing faster is the tmpfs in RAM which I used to compile the OpenJDK in on my "workstation". Starting Eclipse takes now less time on my laptop than on my workstation even though it got twice as few cycles.
If you still have a 1024x786 resolution your IT is criminally bad. At least our developers all have 2 screens with 1280x 1024 resolution. When I'm working at home my single screen (1680x1050) already seems small. And since I develop on both, I can see that the time won by a second monitor is really large (estimates on the internet are about 10% increase in productivity - mine is probably higher). So that little monitor of yours is costing the company hundreds of dollars each *month*. Add up some saved paper to that (some dollars) and you could pay for about 6 monitors *a year*. I'm only printing out a few pages a month now.
Collect some figures and show them to your boss. But don't bitch about it since that won't work to your advantage.
Gods, if we would go and post all Word annoyances; I've written 4 pages in 30 minutes. All out of the top of my head. But if we are talking about i18n (internationalization):
A header is a header is a header is a header. If you type a document in a German version of Word and edit it in a Dutch version and edit it in an English language version you should *not* have all your formatting duplicated three times. You don't want to see the formatting that we got when our Dutch company hired a German firm that had a Australian consultant.
Oh well, at least I understand both languages. Now the parent company is French...4 languages. Now this is going to be "fun".
So now I haven't written about. Bookmark handling, crashes, the related "document recovery", variables that don't update, the logging of each small change in formatting, the lack of paste special -> unformatted unicode key, impossible to find print settings, table management, image handling, missing version management, missing file formats, missing table import, handling of headers and page breaks, the inconsistency with the delete and backspace keys, mis-formatting of lists, incorrect print previews, missing visio interaction, blocking pop-ups, page redraw while scrolling, text block handling, tables and page breaks and anything involving page breaks in general. For starters.
I'll have to look into the code for that, but having done a bit of C++ work myself, libraries are the main reason why you do this. Current applications are starting to be very large collections of libraries plus some control logic and possibly a GUI. This means that your libraries need to be secure as well and that the interface to those libraries should be consistent. Generally, you can't say that for C++ applications since they tend to use C-libraries. It's very nice to have boost and other "standardized" C++ libraries, but their usefulness is limited by having to use C, MFC libraries and the Windows API. I've had to juggle between char*, wchar*, basic_string templates and - eh - CString (I'm trying to forget) quite often.
Because the base types used in Java are pretty well defined, and since Java byte-code cannot modify things that should not be modified, Java is suffering less from this problem. Then again, Java programmers seem to be less aware of using e.g. byte[] access and the vulnerabilities of the JVM may be hard to deal with. Java also lacks some const constructs - Java 7 might alleviate that a bit. But I still think the situation for managed languages with well defined API's is much better in this respect.
And I presume that there is quite a bit of legacy code in Firefox as well, which may make all the difference.
PS please replace Java by Python or C# at your leisure, I'm drawing from experience here.
Absolutely true. However, it does make a statement about the validness for using such a language today, especially for security related applications. How long should we keep such languages and libraries around?
Meh, with the number of bytes we have lying around on the computer: just make it 64 bits. If anybody ever creates a string of 18446744073709551616 characters or higher, we'll give him a cookie. You could also use variable length encoding such as DER. In that case you can go up to a number that is much higher than 2^128 you run out of particles in the universe pretty quickly. DER uses one byte encoding up to 7Fh. After that you get 8180h, up to 81FFh, then you get 820100h up to 82FFFF up to FExx where xx is repeated 7Fh times.
Note that this is a C/C++ construct that has been - uh - deprecated by languages like pascal ages ago. Nobody says that a 00h character has to end a string, and you can do much better than that. Truly, I've seen many issues with 0 terminated strings in the last 8 years - many of them in important libraries. 0 terminated strings suck. Control characters without any textual meaning suck. Get rid of them.
If he gets it standardized and included in standard implementations of cryptographic software and hardware - he would definitely have something there. But I would take opt for SHA-2 instead. It's well defined and present in more devices that having MD5 and SHA-1 work together. Of course that does not mean it cannot be included in proprietary or closed protocols, but for those anything goes. I agree that I may have put that a bit too strong though. But pretty please (with sugar on top) don't opt for these kind of combinations.
Anyway, the paper you pointed to seems to be for using two signatures each with a different hash method, which is different form just concatenating the two. I've just browsed over it (and it is quite late) but if it doesn't mean that than the paper is pretty unclear.
I *know*, it has given me endless nightmares getting it work with various hardware devices. That's exactly why it should not be used. Use SHA-2 instead.
I've got more than 8 years of experience with security around HSM's and smart cards.
Well just letting them sit at home is not an option either. What would be a good idea is to let them stay on benefits if they do voluntary work. The planet gets better and they are at least keeping busy (making sure that they will have less of a distance to go when getting a payed job as well).
There is one thing that should not be happening: private companies should not have to pay less than minimum wage unless they agree to hire at least a number of these people for a regular job. IMHO picking asparagus is something entirely different from adding more people to keep a city clean.
Of course, an unmarried mother with 3 kids should not have to do anything like this. It also depends on the situation.
What would happen if we let these people have society funded jobs? You could put these people to work just to create a better society. Currently there are issues with the availability of jobs to care for the elderly and handicapped people (at least in the Netherlands). Many jobs that are now taken care of by volunteers should really be payed jobs. And some things like cleaning up the waste are not taken care of at all - or at the least very sub-optimal.
Looking around me I don't see a problem with there being enough work to do, it's just that the funding does not fit in the current world. And that will become maybe one of the biggest problems with the current capitalist world in the end. I'm very afraid that the capitalist economy needs to be retrofitted to the new world we are living in.
Unfortunately that kind of change probably requires a very large catastrophe for it to happen. And that will come either from us making a mess of the earth, or - more probably - public unrest.
[yes, this is a bit of a brainstorm, hope you don't mind]planet
There are two major problems with this analysis though. The first is that it presumes SSD will be large enough for the sorts of workloads people with RAID controllers encounter. While there are certainly people using such controllers to accelerate small data sets, you'll find just as many people who are using RAID to handle large amounts of data. Right now, if you've got terabytes of stuff, it's just not practical to use SSD yet. For example, I do database work for living, and the only place we're using SSD right now is for holding indexes.
That's probably true for your databases, but are databases that measure in terabytes really the norm?
None of the data can fit, and the data growth volume is such that I don't even expect SSDs to ever catch up--hard drives are just keeping up with the pace of data growth.
The latest SSD drives of Intel already has room for 320 GB. These are low end consumer disks. Once these things get popular you'll see a sharp increase in production volume. The growth *rate* of flash SSD is very, very high. They haven't caught up yet but I'm quite sure that they will, if only because the hard disks only seem to have these three advantages (size, price and many years of experience with them).
The problem with the volatile write caches seems to be debunked as well, so I'm not so sure about your comment.
For my personal use, the Intel G2 SSD that I ordered does 80 MB/s writes continuously. For me this means that if my PC shuts down suddenly, the chances of there being any dirty data in the cache is really low - much better than with a hard-disk anyway. But in my home environment it's likely that 99% of the time, there is no data to be written, which is totally different than in a high volume DB environment.
There have been a few AES based candidates for SHA-3. Basically they improve on Whirlpool. So the ideas of Whirlpool were taken and enhanced for the competition.
Using AES certainly has advantages. It may be possible to use current hardware acceleration and a lot is known of the algorithm. Newer hardware may combine the two. The disadvantages are also numerous.
AES was never designed with hashing in mind and may have unknown vulnerabilities. Current hardware may not be resistant against some attacks that are particular to hash methods. That is, if it can be used efficiently at all in hashing mode - most of the time the candidates use part of the AES method, not the block encrypt in its totality.
Of course Skein uses Threefish. It can also be used for encryption and decryption, but it has not been standardized for those uses.
Hmm, please do not read the last part of that article.
If you do, I'll offer my opinion on it.
Basically if MD6 is withdrawn it will not have too much value left for the immediate future. It will only live on in the minds of crypto-analysts for their next algorithms. It won't be adopted in any cryptographic products (both the all important libraries and hardware).
Nobody in their right mind is using both MD5 and SHA-1 together, and even if they do they are both standardized hash methods. Combining hash methods is dangerous at least and should not be done haphazardly. It would be much better to use SHA-2 256 instead, if only because it is a standardized hash and not some weird combination of two.
OK, this may make a bit of a dent in MS market share for browsers. But the government sponsored radio stations and television broadcasters are still requiring windows media player to view anything online. Communications between companies and the government is still using.doc/.xdoc format. Nowadays you can get mac and linux tax applications, but before that it was Windows only. Nowadays many services are provided by government related companies and services. So even if the government itself does allow other OS, media players and browsers, you won't get some services.
As long as the government itself is making sure that MS is required there won't be any change in the market share. Instead of asking MS they should be reforming themselves. But of course fining MS is an easier thing to do. Now they need to take action themselves as well.
Yeah, like the OEM's will have that option. MS will immediately make sure that the first one to do that doesn't get any rebates. Of course, they won't state it as the real reason, but as long as they can make price arrangements with OEM's instead of using a fixed price, your option does not make sense.
Is this true? I understood that a mark & sweep GC as default in Java leaves some memory allocated, but a GC does not have to be mark and sweep. Especially if performance is less of a burden you could do GC for 24/7. You would loose some performance but you would gain memory. And then you could go and sit somewhere in the middle and use the G1 gc in Java, which trades in processor time in another thread. Besides, even compiled languages won't leave each and every piece of memory usable. Without anything to "collect the holes" a compiled language may be more of a memory burden when it is used as a service.
If anything I think the meta-information used by the managed languages and scripts is much more of a memory burden than the garbage collection (although the Java implementation certainly leaves some things to be desired). You can strip a lot of that out of your Java application by removing all debugging information (and renaming all classes and methods), but your exception stack will look horrible without any line numbers etc. And Java is more about easy maintenance than anything else.
Because if the PC itself does not have time to properly shut down, your data will be cut in half anyway. A proper journaling FS would take care of any FS problems at least. The only thing you would gain is 32 MB of data saved. But if that data would be the start of a file write instead of a read, you might be off worse. You might consider ZFS if you are really paranoid, so you can roll back.
If the flash drive is not busy it might be hard to catch it when there is data in the cache. These things have such insane access times that small writes take less than an ms. You would not be very lucky if you managed to remove power just as one of those was happening. Compare that to an HDD that might want to spin up, unpark the drive head and at least search for the right track before writing your important 1 KB of data. I'd like some statistics on how much time the cache is empty compared to a hard drive when not in full use. I would not be surprised if the cache is completely empty of (dirty) pages almost all of the time on the SSD.
I could imagine a 1 GB buffer in the future that is backed up by a super-capacitor. You could use that to write data to and consider it saved without writing it to the SSD at all. If a power failure would happen the drive could save the 1 GB in a continuous 1GB flash portion of the SSD (pre-cleared of course). Advantage would be that the most often written data could stay in the RAM virtually forever. As flash is much less power hungry than a hard drive you would need much less power stored in the capacitor. It would be very hard to get the capacitor linked up correctly, I assume.
My most used data is OS + applications. An SSD is big enough to hold both. Data, especially MM can be kept on a HDD. Backups can be made to HDD. You would need special chips and such to put everything together. There were some hybrid drives (ok, with a minimum of slower flash with less leveling) but they failed. If it is ever really required, I expect people would be able to do it in the OS.
There seem to be some defragmentation applications that say they can change some of the characteristics of the writing. I would be very wary of using these kind of applications - it's uncertain that they'll do any good.
For the Vertex drive there is an application that can perform the TRIM command for unused sectors. It's quite new so I would look up if it fits your OS - and only if there is no native TRIM support in the OS of course.
For these kind of Intel drives (especially the latest): unless you do very very heavy writes, just ignore the issue (see the reviews - write is at a constant 80 MB/s).
Otherwise, e.g. for heavy use DB applications, ghost to that 1 GB green hard drive, use a SATA command to clear the drive and ghost the stuff back in. You'll probably manage at least 60 MB/s doing that, so in total it would be something like 2 hours to do this - for a 160 GB drive (and so no time at all for a vertex 30 GB drive, come to think of it).
Oh, and you know all the algorithms that are on your hard drive controller out of the top of your head, do you? Or those on your motherboard? Or your OS? Or the applications you run on them?
Especially with Intel, I do trust the market place to have some influence in them testing their drives really well before supplying them to customers. If these drives start failing in large numbers they'll have serious problems.
Slashdot Mirror
Although this bug should have been caught faster it seems that it is possible to update the firmware without any data loss (fortunately I have put it in a laptop, power outages are no problem). I've looked at the Intel site and the flash utility seems to be simply bootable from CD - if this is the last bug I'll be a very happy punter indeed.
My 80 GB G2 SSD replaced a not too fast laptop drive. I'm now trying Linux, but I'll try Vista as well just for fun - I'll just write my 80 GB to an external drive using Gparted. These drives come highly recommended even if they would slow down to 50% of performance (which, it seems, they don't). I unzipped Eclipse to it and JavaDoc and I could see that the archiver that unzipped the .zip has some performance issues reading the index. It took longer than the unzipping and gunzipping and untarring (the Eclipse gunzipping/untarring took less than 2 seconds - yikes). The only thing faster is the tmpfs in RAM which I used to compile the OpenJDK in on my "workstation". Starting Eclipse takes now less time on my laptop than on my workstation even though it got twice as few cycles.
If you still have a 1024x786 resolution your IT is criminally bad. At least our developers all have 2 screens with 1280x 1024 resolution. When I'm working at home my single screen (1680x1050) already seems small. And since I develop on both, I can see that the time won by a second monitor is really large (estimates on the internet are about 10% increase in productivity - mine is probably higher). So that little monitor of yours is costing the company hundreds of dollars each *month*. Add up some saved paper to that (some dollars) and you could pay for about 6 monitors *a year*. I'm only printing out a few pages a month now.
Collect some figures and show them to your boss. But don't bitch about it since that won't work to your advantage.
Do you mean the old "glacially" which is slow or the new "glacially" which is fast?
Gods, if we would go and post all Word annoyances; I've written 4 pages in 30 minutes. All out of the top of my head. But if we are talking about i18n (internationalization):
A header is a header is a header is a header. If you type a document in a German version of Word and edit it in a Dutch version and edit it in an English language version you should *not* have all your formatting duplicated three times. You don't want to see the formatting that we got when our Dutch company hired a German firm that had a Australian consultant.
Oh well, at least I understand both languages. Now the parent company is French...4 languages. Now this is going to be "fun".
So now I haven't written about.
Bookmark handling, crashes, the related "document recovery", variables that don't update, the logging of each small change in formatting, the lack of paste special -> unformatted unicode key, impossible to find print settings, table management, image handling, missing version management, missing file formats, missing table import, handling of headers and page breaks, the inconsistency with the delete and backspace keys, mis-formatting of lists, incorrect print previews, missing visio interaction, blocking pop-ups, page redraw while scrolling, text block handling, tables and page breaks and anything involving page breaks in general. For starters.
I'll have to look into the code for that, but having done a bit of C++ work myself, libraries are the main reason why you do this. Current applications are starting to be very large collections of libraries plus some control logic and possibly a GUI. This means that your libraries need to be secure as well and that the interface to those libraries should be consistent. Generally, you can't say that for C++ applications since they tend to use C-libraries. It's very nice to have boost and other "standardized" C++ libraries, but their usefulness is limited by having to use C, MFC libraries and the Windows API. I've had to juggle between char*, wchar*, basic_string templates and - eh - CString (I'm trying to forget) quite often.
Because the base types used in Java are pretty well defined, and since Java byte-code cannot modify things that should not be modified, Java is suffering less from this problem. Then again, Java programmers seem to be less aware of using e.g. byte[] access and the vulnerabilities of the JVM may be hard to deal with. Java also lacks some const constructs - Java 7 might alleviate that a bit. But I still think the situation for managed languages with well defined API's is much better in this respect.
And I presume that there is quite a bit of legacy code in Firefox as well, which may make all the difference.
PS please replace Java by Python or C# at your leisure, I'm drawing from experience here.
Yeah, in the same kind of reasoning no cars should ever crash since you should drive safely.
Absolutely true. However, it does make a statement about the validness for using such a language today, especially for security related applications. How long should we keep such languages and libraries around?
That won't be someone in the SSL related code I guess. It's more like a language/library problem.
Meh, with the number of bytes we have lying around on the computer: just make it 64 bits. If anybody ever creates a string of 18446744073709551616 characters or higher, we'll give him a cookie. You could also use variable length encoding such as DER. In that case you can go up to a number that is much higher than 2^128 you run out of particles in the universe pretty quickly. DER uses one byte encoding up to 7Fh. After that you get 8180h, up to 81FFh, then you get 820100h up to 82FFFF up to FExx where xx is repeated 7Fh times.
Note that this is a C/C++ construct that has been - uh - deprecated by languages like pascal ages ago. Nobody says that a 00h character has to end a string, and you can do much better than that. Truly, I've seen many issues with 0 terminated strings in the last 8 years - many of them in important libraries. 0 terminated strings suck. Control characters without any textual meaning suck. Get rid of them.
It was a mistake but it was probably a personal mistake, not a technical one. You've got something to learn if you don't understand this.
If he gets it standardized and included in standard implementations of cryptographic software and hardware - he would definitely have something there. But I would take opt for SHA-2 instead. It's well defined and present in more devices that having MD5 and SHA-1 work together. Of course that does not mean it cannot be included in proprietary or closed protocols, but for those anything goes. I agree that I may have put that a bit too strong though. But pretty please (with sugar on top) don't opt for these kind of combinations.
Anyway, the paper you pointed to seems to be for using two signatures each with a different hash method, which is different form just concatenating the two. I've just browsed over it (and it is quite late) but if it doesn't mean that than the paper is pretty unclear.
I *know*, it has given me endless nightmares getting it work with various hardware devices. That's exactly why it should not be used. Use SHA-2 instead.
I've got more than 8 years of experience with security around HSM's and smart cards.
Well just letting them sit at home is not an option either. What would be a good idea is to let them stay on benefits if they do voluntary work. The planet gets better and they are at least keeping busy (making sure that they will have less of a distance to go when getting a payed job as well).
There is one thing that should not be happening: private companies should not have to pay less than minimum wage unless they agree to hire at least a number of these people for a regular job. IMHO picking asparagus is something entirely different from adding more people to keep a city clean.
Of course, an unmarried mother with 3 kids should not have to do anything like this. It also depends on the situation.
Hey, I did not know that "disks" lie about that, do you have any more information on that? Sources maybe?
What would happen if we let these people have society funded jobs? You could put these people to work just to create a better society. Currently there are issues with the availability of jobs to care for the elderly and handicapped people (at least in the Netherlands). Many jobs that are now taken care of by volunteers should really be payed jobs. And some things like cleaning up the waste are not taken care of at all - or at the least very sub-optimal.
Looking around me I don't see a problem with there being enough work to do, it's just that the funding does not fit in the current world. And that will become maybe one of the biggest problems with the current capitalist world in the end. I'm very afraid that the capitalist economy needs to be retrofitted to the new world we are living in.
Unfortunately that kind of change probably requires a very large catastrophe for it to happen. And that will come either from us making a mess of the earth, or - more probably - public unrest.
[yes, this is a bit of a brainstorm, hope you don't mind]planet
There are two major problems with this analysis though. The first is that it presumes SSD will be large enough for the sorts of workloads people with RAID controllers encounter. While there are certainly people using such controllers to accelerate small data sets, you'll find just as many people who are using RAID to handle large amounts of data. Right now, if you've got terabytes of stuff, it's just not practical to use SSD yet. For example, I do database work for living, and the only place we're using SSD right now is for holding indexes.
That's probably true for your databases, but are databases that measure in terabytes really the norm?
None of the data can fit, and the data growth volume is such that I don't even expect SSDs to ever catch up--hard drives are just keeping up with the pace of data growth.
The latest SSD drives of Intel already has room for 320 GB. These are low end consumer disks. Once these things get popular you'll see a sharp increase in production volume. The growth *rate* of flash SSD is very, very high. They haven't caught up yet but I'm quite sure that they will, if only because the hard disks only seem to have these three advantages (size, price and many years of experience with them).
The problem with the volatile write caches seems to be debunked as well, so I'm not so sure about your comment.
For my personal use, the Intel G2 SSD that I ordered does 80 MB/s writes continuously. For me this means that if my PC shuts down suddenly, the chances of there being any dirty data in the cache is really low - much better than with a hard-disk anyway. But in my home environment it's likely that 99% of the time, there is no data to be written, which is totally different than in a high volume DB environment.
There have been a few AES based candidates for SHA-3. Basically they improve on Whirlpool. So the ideas of Whirlpool were taken and enhanced for the competition.
Using AES certainly has advantages. It may be possible to use current hardware acceleration and a lot is known of the algorithm. Newer hardware may combine the two. The disadvantages are also numerous.
AES was never designed with hashing in mind and may have unknown vulnerabilities. Current hardware may not be resistant against some attacks that are particular to hash methods. That is, if it can be used efficiently at all in hashing mode - most of the time the candidates use part of the AES method, not the block encrypt in its totality.
Of course Skein uses Threefish. It can also be used for encryption and decryption, but it has not been standardized for those uses.
Hmm, please do not read the last part of that article.
If you do, I'll offer my opinion on it.
Basically if MD6 is withdrawn it will not have too much value left for the immediate future. It will only live on in the minds of crypto-analysts for their next algorithms. It won't be adopted in any cryptographic products (both the all important libraries and hardware).
Nobody in their right mind is using both MD5 and SHA-1 together, and even if they do they are both standardized hash methods. Combining hash methods is dangerous at least and should not be done haphazardly. It would be much better to use SHA-2 256 instead, if only because it is a standardized hash and not some weird combination of two.
OK, this may make a bit of a dent in MS market share for browsers. But the government sponsored radio stations and television broadcasters are still requiring windows media player to view anything online. Communications between companies and the government is still using .doc/.xdoc format. Nowadays you can get mac and linux tax applications, but before that it was Windows only. Nowadays many services are provided by government related companies and services. So even if the government itself does allow other OS, media players and browsers, you won't get some services.
As long as the government itself is making sure that MS is required there won't be any change in the market share. Instead of asking MS they should be reforming themselves. But of course fining MS is an easier thing to do. Now they need to take action themselves as well.
Yeah, like the OEM's will have that option. MS will immediately make sure that the first one to do that doesn't get any rebates. Of course, they won't state it as the real reason, but as long as they can make price arrangements with OEM's instead of using a fixed price, your option does not make sense.
Is this true? I understood that a mark & sweep GC as default in Java leaves some memory allocated, but a GC does not have to be mark and sweep. Especially if performance is less of a burden you could do GC for 24/7. You would loose some performance but you would gain memory. And then you could go and sit somewhere in the middle and use the G1 gc in Java, which trades in processor time in another thread. Besides, even compiled languages won't leave each and every piece of memory usable. Without anything to "collect the holes" a compiled language may be more of a memory burden when it is used as a service.
If anything I think the meta-information used by the managed languages and scripts is much more of a memory burden than the garbage collection (although the Java implementation certainly leaves some things to be desired). You can strip a lot of that out of your Java application by removing all debugging information (and renaming all classes and methods), but your exception stack will look horrible without any line numbers etc. And Java is more about easy maintenance than anything else.
Because if the PC itself does not have time to properly shut down, your data will be cut in half anyway. A proper journaling FS would take care of any FS problems at least. The only thing you would gain is 32 MB of data saved. But if that data would be the start of a file write instead of a read, you might be off worse. You might consider ZFS if you are really paranoid, so you can roll back.
If the flash drive is not busy it might be hard to catch it when there is data in the cache. These things have such insane access times that small writes take less than an ms. You would not be very lucky if you managed to remove power just as one of those was happening. Compare that to an HDD that might want to spin up, unpark the drive head and at least search for the right track before writing your important 1 KB of data. I'd like some statistics on how much time the cache is empty compared to a hard drive when not in full use. I would not be surprised if the cache is completely empty of (dirty) pages almost all of the time on the SSD.
I could imagine a 1 GB buffer in the future that is backed up by a super-capacitor. You could use that to write data to and consider it saved without writing it to the SSD at all. If a power failure would happen the drive could save the 1 GB in a continuous 1GB flash portion of the SSD (pre-cleared of course). Advantage would be that the most often written data could stay in the RAM virtually forever. As flash is much less power hungry than a hard drive you would need much less power stored in the capacitor. It would be very hard to get the capacitor linked up correctly, I assume.
My most used data is OS + applications. An SSD is big enough to hold both. Data, especially MM can be kept on a HDD. Backups can be made to HDD. You would need special chips and such to put everything together. There were some hybrid drives (ok, with a minimum of slower flash with less leveling) but they failed. If it is ever really required, I expect people would be able to do it in the OS.
There seem to be some defragmentation applications that say they can change some of the characteristics of the writing. I would be very wary of using these kind of applications - it's uncertain that they'll do any good.
For the Vertex drive there is an application that can perform the TRIM command for unused sectors. It's quite new so I would look up if it fits your OS - and only if there is no native TRIM support in the OS of course.
For these kind of Intel drives (especially the latest): unless you do very very heavy writes, just ignore the issue (see the reviews - write is at a constant 80 MB/s).
Otherwise, e.g. for heavy use DB applications, ghost to that 1 GB green hard drive, use a SATA command to clear the drive and ghost the stuff back in. You'll probably manage at least 60 MB/s doing that, so in total it would be something like 2 hours to do this - for a 160 GB drive (and so no time at all for a vertex 30 GB drive, come to think of it).
Oh, and you know all the algorithms that are on your hard drive controller out of the top of your head, do you? Or those on your motherboard? Or your OS? Or the applications you run on them? Especially with Intel, I do trust the market place to have some influence in them testing their drives really well before supplying them to customers. If these drives start failing in large numbers they'll have serious problems.