About SSD hard drive durability

When SSD disks popped up some time ago, many people's main concern was their durability. The claimed 10k write cycles for each block didn't really sound much to most people (including me). Still, I thought I'd risk it, and bought one (an 128GB Crucial/Micron RealSSD m4/C400) about one and a half years ago. The speedup is noticeable, especially for things which need short access times (find, copying large amounds of files, starting applications). Also, it's absolutely silent which is nice too. So from that perspective, I'd say it's definitely worth the money.

But, how about its durability? Of course, I can only really tell about the durability once it breaks, but there is a handy little tool called smartctl which can read various bits of information from the hard drive's self test capabilities. For my device, it reports various things, such as a power-on time of about 5000 hours and a power cycle count of about 2200. The most interesting number, though, is probably the wear levelling count: From what I understand, this is the maximum amount of times a block on the disk has been re-written (you know, of the 10k times it is supposed to survive). Interestingly, after 18 months of daily usage, this is a whopping 53 (sic!) times for the worst-case block. Thus, the controller seems to do an excellent job at wear levelling (if it would be perfect, this 53 would mean an average disk write of 1.3GB per power-on hour, which seems ok; I do quite some IO-heavy tasks and you also have to take the wear levelling overhead into account). Quite impressive, I think!

So: From the block wearout perspective, I don't think there's anything at all to worry about for SSD disks. Mine would survive another 100 years if it's about up to its spec. I guess the controller or something will fail much earlier than the actual memory blocks. And remember: The larger your disk, the better wear levelling is going to work, so this problem will be even less severe.

Busting KDevelop myths

For every KDevelop release, announcements are made by various people on various news sites, and there's plenty of comments. Depending on the news site, those comments are more or less accurate, but generally, comments on KDE applications outside of the "KDE world" (planet, developer blogs, ...) are often alarmingly mis-informed and are spreading a lot of FUD. I'm sure most projects have similar issues, but I feel it's especially bad for KDE, and for KDevelop in particular. I have no idea why, but I'd like to collect and clarify a few common misunderstandings and wrong things said about KDevelop.

kdev-python 1.5 rc1 -- please test!

Hi!

Five months have passed since the release of kdev-python 1.4.1, and it's about time for the next release! The 1.5 release will contain various new features and bug fixes, and also will work with KDevelop 4.5, which is to be released soon.

One of the new features in kdev-python 1.5: initializing properties in class constructors via code completion

Notable Bugs fixed

The following issues were fixed, among others:

• 312275 don't add brackets if importing functions
• 318802 fix quadruple-quotes from causing completion to malfunction
• 317998 issue with function definition ranges causing completion to malfunction
• 317808 correct inheritance completion with member access
• 309817 correctly build uses for declarations in some corner cases
• 309469 include documentation files for PyKDE and the rest of PyQt
• 308986 fix a rare crash with some function definitions
• 1d34b03 fix an infinite loop in the debugger plugin
• 031badc don't reparse files on session restart if not necessary

The numbers are the bug / commit IDs of the change.

Notable new Features

The following new features are worth mentioning:

• 333cf91 sort completion items based on name similarity
• 6dc24ad class attribute initialization completion
• cd03cee PEP8 error checking. Enable it in "configure kdevelop" if you want to use it.
• b3ba512 support adding watches in the debugger plugin

Name-aware variable sorting: Although "the_bar" comes first alphabetically, "the_foo" is sorted first because its name matches the left side of the expression. You can still get an alphabetical list by invoking full completion.

Features that didn't make it into 1.5 yet

Two things that I wanted in 1.5 but which are not there are Python 3 support, and GHNS support. The latter is just not ready yet (might be in 1.5.1 or 1.5.2, but probably 1.6), the former can only be released in Q1 2014, as explained here.

Get it

kdev-python 1.5 is to be used with kdevplatform 1.5, and only 1.5 (so, kdevplatform with version numbers >= 1.4.60 and < 1.5.40). It's not going to work with kdevplatform master, or kdevplatform 1.4.
Please test this RC thoroughly and report any issues you find to the bugtracker, so the final 1.5 release can be as nice as possible! Get the tarball from download.kde.org. The sha256sum of the tarball is
441f675baddbfb9832a49458cc3c9a17daac4db55e7312c7a85d184bc0f4c776
Have fun with it! (not with the checksum, with the program I meant... you know)

Collaborative editing in KTE (prototype)

I had a bit of spare time, so I decided I'd try to implement collaborative editing in KTextEditor, and see how far I can get in a week. That week is over now -- and this is how far I got:


(If your browser doesn't support HTML5 video, here's a direct link)