So open-sourcing might make it possible to re-implement the horrible part, while leaving the user-interface intact, and hopefully also allowing backwards-compatibility.
The problem discussed was wear leveling, and the whole point was to avoid disk writes.
% man 2 sync
% man 8 update
You can stop reading when you start to realize the connection between file system caching and avoiding disk writes. It's kindof the whole point, you see.
Speaking of which, the single best thing you could do to prolong the life of the SSD -or- improve the performance of the hard drive is to switch to a better version control system, like Mercurial for instance. Subversion stores about 8 files average per file you have version controlled. It also updates these files a lot. It's really a pig.
Mercurial is really the way to go here, whether on SSD or not.
Mercurial stores the full project history on disk, so it may be a bit expensive.
However, mercurial also operates in fashion where it only appends to repo files (?), which should be pretty close to ideal operation in flash environment.
If you make insertions or deletions, the following data will be shifted.
My point was that no editor does insertions or deletions. They always write out the whole file. Editors really have no idea how a file was "edited" unless they do a diff vs. the old file, which I don't think is used in practice.
Some editors may open, truncate and write out the same file (which is a bit unsafe), while some create & write a new file, move over the old one and rename the new file as the old one.
Can't you just instruct your compiler to place temporary files in/tmp, and make that a tmpfs?
There is no catch-all way to do this. For example, often the object files are "fixed" to appear at certain place by whatever build system is being used.
If build descriptions were just a list of "compile these files, producing these target files", there would be more leevay to easily tweak the details. Unfortunately, build systems are a mess.
Actually now I'm thinking that you were saying you'd have to overwrite the block containing modified bytes. However, there's still no advantage to using multiple files in that case: the entire flash block has to be overwritten anyway to change any part of it.
The good side about multiple files (over a database) is that you can just keep appending to the files if it makes sense for your application. If a file has its own block, you don't need to erase at all, but just append data to the block. This minimizes the amount of erase cycles.
The database is often in one (compact) file, and if you are editing just one byte of it you will have to erase & rewrite an entire flash block when you commit your data.
Only if you buy a crappy flash drive with a crappy controller. The good ones are worth the extra money.
Not so compact as you seem to think. Delete a record from the top of a multi-gigabyte database and I guarantee you the database won't be completely overwritten to collapse the gap.
Of course not. Nothing does that. I meant that the database file format is rather compact compared to sparse ways of storing the data (e.g. different files on a file system). You will see integer fields next to each other, etc.
That way it'll encourage them to write efficient implementations.
Actually, the opposite is true.
If development is painful (which it is, if your workflow is hampered by slow builds), you will produce crappier code. It's all about retaining focus & flow. Sad thing is, compilation still takes too long; you can still check your gmail or refresh slashdot.
How many of you are reading this article while automake is checking the version of your fortran compiler in order to run gcc on a.c file?
Database edits don't propagate through the database the way a code edit propagates through the files in your project.
The database is often in one (compact) file, and if you are editing just one byte of it you will have to erase & rewrite an entire flash block when you commit your data.
To my mind, database seems like a horrible application for flash write patterns. Anything that can work by just appending & creating files is a much friendlier environment.
Does anyone know if any existing database optimizes for flash write patterns? Do the commit journals take care of this problem?
In addition to the source code itself, object files, dlls, and executables will probably have to be re-written if you change a source code file.
Object code is pretty small & tight. The entire linux kernel w/ initrd image is 8 megs...
It's not as simple as that. Make a small change (insertion or deletion) near the beginning of a large source code file, and the entire file – from the edit onward – must be written over.
It's not like any normal editor actually opens the file in edit mode and only patches in bytes that have been modified. They all rely on the simple solution of actually writing the whole file at once.
Sometimes I wonder whether it would make sense to optimize the disk usage for flash drives by writing transient files to ramdisk instead of hard disk. E.g. in compilation, intermediate files could well reside on ramdisk. If you rely on "make clean" a lot (e.g. when you are rebuilding "clean".debs all the time), you won't have that much attachment to your object files.
Of course this may require more work than what it's really worth, but it's a thought.
He accused me of being an imbecile, that wasn't a legitimate MAC address. I asked him why he hadn't brought this up in any of the weekly meetings for a month, since it was there all along. Hung up on me. I took some time to creat some interesting LAAs for the various minor servers we had, especially the Internet gateway/proxy, and the email server. He was not amused, but his boss was. And told me to stop annoying him.
Lound like a real-life BOFH story. Not that there is necessarily anything wrong with that;-).
"Voting" is a rather hilarious newspeak term for acceptance of a pay cut.
Not that I see anything particularly wrong with this approach. I find it pretty absurd that a company should be "stuck" with the contract rates it offers. And considering how big salaries in USA are, it's a small miracle that they still manage to make a profit.
Let the techies choose technology, not the bureaucrats.
The bureaucrats and managers almost always make the major strategic technical decisions. And that's the way it's supposed to be, since they are accountable for the money spent now and in the future.
Government is using taxpayer money, which makes the issue even more important. Incompetent techies can easily overspend, merely on grounds of being familiar with some technology or attending a corruption lunch.
My point is that I would be happyest if some LINUX company would lead that kind of lobby effort and not some guy that only wants his company to come back from the dead.
I smell treachery.
Huh? Widespread use of open technologies benefits Sun, and the open source community. It's not like Sun's self-interest in this wasn't obvious, but as long as we are sharing the same interests, it's all good.
I tried your updated kernel, but still had connection problems on ath5k. Overall performance of the computer was better than with ndiswrapper, but wlan was again very slow. I reverted back to ndiswrapper (with the new kernel though).
I don't wanna sound like a queer or nothing, but Steven J. Vaughan-Nichols, Cyber Cynic, has striking green eyes. I wonder if he did that with Photoshop?
Offtopic? The article was written by Steven J. Vaughan-Nichols, Cyber Cynic! Did you even RTFA, mods? I didn't think so.
Now you're giving me a headache!
That's because there is no "-1, gay" moderation option (I know, I had the points today and checked).
At least on eee pc 900 you still need to use ndiswrapper for wlan - even if it would appear that the native drivers work, they don't. The connection is slower and breaks easier with them.
However, for many of us who require better-than-average data security, the matter of SSD's read/write behaviour makes the devices extremely vulnerable to analyses and discovery of data the owner/author of which believes to be inaccessible to others: 'secure wiping', or lack thereof, is the issue.
Obviously you should be encrypting your sensitive data.
Also, it should be no problem to write a bootable cd/usb that does a complete wipe. Just write over the whole disk, erase, repeat. No wear leveling will get around that.
Apple's strict control is what makes so user friendly. Forcing developers to work with in strict guide lines keeps the quality of the software up there, but limits the amount of software available. Apple's control extends to the hardware. Even their BIOS is proprietary. By controlling the hardware everything works. Microsoft can only dream of having this kind of control over their product. Opening Apple's products will only degrade them.
Yeah, we have already seen what kind of damage an open software ecosystem creates. Multiple applications doing the same thing, multiple libraries and (god fordib) programming languages are being used in haphazard fashion.
Slashdot Mirror
So open-sourcing might make it possible to re-implement the horrible part, while leaving the user-interface intact, and hopefully also allowing backwards-compatibility.
This is what Nokia is doing with Qt for S60.
Yes, descriptors take a while to get used to, but perhaps you should read up about why they are there in the first place before writing them off?
Descriptors are there because Symbian wanted to provide a string class with bounds checking and unicode support.
Woohey. It wouldn't have been necessary to make them suck so much.
Google for the different types of ROM memory phones use and the performance characteristics of each.
Care to enlighten us how these things are related in any way to Symbian OS?
% man 2 sync
% man 8 update
You can stop reading when you start to realize the connection between file system caching and avoiding disk writes. It's kindof the whole point, you see.
Have you ever kissed a girl?
Speaking of which, the single best thing you could do to prolong the life of the SSD -or- improve the performance of the hard drive is to switch to a better version control system, like Mercurial for instance. Subversion stores about 8 files average per file you have version controlled. It also updates these files a lot. It's really a pig.
Mercurial is really the way to go here, whether on SSD or not.
Mercurial stores the full project history on disk, so it may be a bit expensive.
However, mercurial also operates in fashion where it only appends to repo files (?), which should be pretty close to ideal operation in flash environment.
How about writing it to a ramdisk, and additionally writing transparently storing it to disc, just in case the power gets turned of.
I will call this complex scheme "caching".
Your sarcasm would be appreciated if it was related to discussion at hand.
The problem discussed was wear leveling, and the whole point was to avoid disk writes.
If you make insertions or deletions, the following data will be shifted.
My point was that no editor does insertions or deletions. They always write out the whole file. Editors really have no idea how a file was "edited" unless they do a diff vs. the old file, which I don't think is used in practice.
Some editors may open, truncate and write out the same file (which is a bit unsafe), while some create & write a new file, move over the old one and rename the new file as the old one.
Can't you just instruct your compiler to place temporary files in /tmp, and make that a tmpfs?
There is no catch-all way to do this. For example, often the object files are "fixed" to appear at certain place by whatever build system is being used.
If build descriptions were just a list of "compile these files, producing these target files", there would be more leevay to easily tweak the details. Unfortunately, build systems are a mess.
Actually now I'm thinking that you were saying you'd have to overwrite the block containing modified bytes. However, there's still no advantage to using multiple files in that case: the entire flash block has to be overwritten anyway to change any part of it.
The good side about multiple files (over a database) is that you can just keep appending to the files if it makes sense for your application. If a file has its own block, you don't need to erase at all, but just append data to the block. This minimizes the amount of erase cycles.
The database is often in one (compact) file, and if you are editing just one byte of it you will have to erase & rewrite an entire flash block when you commit your data.
Only if you buy a crappy flash drive with a crappy controller. The good ones are worth the extra money.
Care to explain how they do it? Any good links?
Not so compact as you seem to think. Delete a record from the top of a multi-gigabyte database and I guarantee you the database won't be completely overwritten to collapse the gap.
Of course not. Nothing does that. I meant that the database file format is rather compact compared to sparse ways of storing the data (e.g. different files on a file system). You will see integer fields next to each other, etc.
That way it'll encourage them to write efficient implementations.
Actually, the opposite is true.
If development is painful (which it is, if your workflow is hampered by slow builds), you will produce crappier code. It's all about retaining focus & flow. Sad thing is, compilation still takes too long; you can still check your gmail or refresh slashdot.
How many of you are reading this article while automake is checking the version of your fortran compiler in order to run gcc on a .c file?
Database edits don't propagate through the database the way a code edit propagates through the files in your project.
The database is often in one (compact) file, and if you are editing just one byte of it you will have to erase & rewrite an entire flash block when you commit your data.
To my mind, database seems like a horrible application for flash write patterns. Anything that can work by just appending & creating files is a much friendlier environment.
Does anyone know if any existing database optimizes for flash write patterns? Do the commit journals take care of this problem?
In addition to the source code itself, object files, dlls, and executables will probably have to be re-written if you change a source code file.
Object code is pretty small & tight. The entire linux kernel w/ initrd image is 8 megs...
It's not as simple as that. Make a small change (insertion or deletion) near the beginning of a large source code file, and the entire file – from the edit onward – must be written over.
It's not like any normal editor actually opens the file in edit mode and only patches in bytes that have been modified. They all rely on the simple solution of actually writing the whole file at once.
Sometimes I wonder whether it would make sense to optimize the disk usage for flash drives by writing transient files to ramdisk instead of hard disk. E.g. in compilation, intermediate files could well reside on ramdisk. If you rely on "make clean" a lot (e.g. when you are rebuilding "clean" .debs all the time), you won't have that much attachment to your object files.
Of course this may require more work than what it's really worth, but it's a thought.
Imagine how much *spam* you could send using this approach.
No, wait...
If developers choose to use a MS only product, that's not MS's fault.
Yeah, and it's the developers that mostly get the blame anyway.
C.f. all the flaming around mono.
He accused me of being an imbecile, that wasn't a legitimate MAC address. I asked him why he hadn't brought this up in any of the weekly meetings for a month, since it was there all along. Hung up on me. I took some time to creat some interesting LAAs for the various minor servers we had, especially the Internet gateway/proxy, and the email server. He was not amused, but his boss was. And told me to stop annoying him.
Lound like a real-life BOFH story. Not that there is necessarily anything wrong with that ;-).
"Voting" is a rather hilarious newspeak term for acceptance of a pay cut.
Not that I see anything particularly wrong with this approach. I find it pretty absurd that a company should be "stuck" with the contract rates it offers. And considering how big salaries in USA are, it's a small miracle that they still manage to make a profit.
Let the techies choose technology, not the bureaucrats.
The bureaucrats and managers almost always make the major strategic technical decisions. And that's the way it's supposed to be, since they are accountable for the money spent now and in the future.
Government is using taxpayer money, which makes the issue even more important. Incompetent techies can easily overspend, merely on grounds of being familiar with some technology or attending a corruption lunch.
My point is that I would be happyest if some LINUX company would lead that kind of lobby effort and not some guy that only wants his company to come back from the dead.
I smell treachery.
Huh? Widespread use of open technologies benefits Sun, and the open source community. It's not like Sun's self-interest in this wasn't obvious, but as long as we are sharing the same interests, it's all good.
With my 900, i've had no issues using the ath5k drivers compared to the ndiswrapper method or the older madwifi drivers.
I've posted an update to the repository from the upstream ath5k developers. This is currently available as 2.6.27-11-eeepc
You may install this version by hand to test, as its not being pushed out automatically yet.
$ sudo apt-get install linux-image-2.6.27-11-eeepc
-Adam
Belated response:
I tried your updated kernel, but still had connection problems on ath5k. Overall performance of the computer was better than with ndiswrapper, but wlan was again very slow. I reverted back to ndiswrapper (with the new kernel though).
I don't wanna sound like a queer or nothing, but Steven J. Vaughan-Nichols, Cyber Cynic, has striking green eyes. I wonder if he did that with Photoshop?
Offtopic? The article was written by Steven J. Vaughan-Nichols, Cyber Cynic! Did you even RTFA, mods? I didn't think so.
Now you're giving me a headache!
That's because there is no "-1, gay" moderation option (I know, I had the points today and checked).
Ubuntu 8.10 + array.org kernel is just fine.
At least on eee pc 900 you still need to use ndiswrapper for wlan - even if it would appear that the native drivers work, they don't. The connection is slower and breaks easier with them.
However, for
many of us who require better-than-average data security, the matter of SSD's read/write behaviour makes the devices extremely vulnerable to analyses and discovery of data the owner/author of which believes to be inaccessible to others: 'secure wiping', or lack thereof, is the issue.
Obviously you should be encrypting your sensitive data.
Also, it should be no problem to write a bootable cd/usb that does a complete wipe. Just write over the whole disk, erase, repeat. No wear leveling will get around that.
Apple's strict control is what makes so user friendly. Forcing developers to work with in strict guide lines keeps the quality of the software up there, but limits the amount of software available. Apple's control extends to the hardware. Even their BIOS is proprietary. By controlling the hardware everything works. Microsoft can only dream of having this kind of control over their product. Opening Apple's products will only degrade them.
Yeah, we have already seen what kind of damage an open software ecosystem creates. Multiple applications doing the same thing, multiple libraries and (god fordib) programming languages are being used in haphazard fashion.