Mac OS X writes too much data to disk, or does it?

This is just an observation I made a couple of days ago. I had my new Macbook Air 11″ on for some 13hrs during which all I did was light use of Google Chrome to look up things once in a while, chat with people in Skype and Adium, listen to radio streams in iTunes, work in a terminal, of course, had Mail.app running which is configured not to save anything to disk, and by the end of the day Activity Monitor reported some 5GB worth of disk writes. 5 gigs, really?

Why would I be concerned? Well, I’m generally speaking curious, but also there’s a legitimate concern because SSD drives, which are of MLC type in Macbook Air’s, on average are guaranteed to last 5 years with average 40GB disk writes per day. So, you can see that 5GBs per day in that context isn’t really a small number.

So, I set out to figure out to see distribution of those disk writes but I haven’t found a solution yet. dtrace looks like the tool that could pull out this data but it falls short of showing accumulated values over time. What I’m talking about is Linux equivalent of iotop -o -a, which is just amazing, simple and user-friendly compared to dtrace.

Which reminds me to say that Mac OS X is a funny OS. It makes it really easy to use a computer in GUI department, but Apple seems to have applied their philosophy of radically simplifying things to command line applications as well. Less of output (otherwise useful and detailed) seems to be characteristic of Apple’s version of such tools as iotop and sar, to name a few.

This I find a little frustrating and limiting. By and large, though, I really like Mac OS X and the whole experience of running Macbook Air.

I’d highly recommend it.

Advertisements

On bug resolving and choosing your stance

Today I spent most of the day submitting bug reports and contacting various developers in hope to speed up the work, maybe even make people aware of the present issues which they might not be aware of yet, and to make the resolution of these bugs come sooner.

Among the various bugs I’ve noticed since I began using KDE 4.x there was one both absolutely irritating and just as easy to fix. All it took for this bug to get fixed was approximately 10-15 minutes to register on KDE’s BugZilla and file a new bug report, and just 8 minutes for a responsible developer to reproduce the bug. 30 minutes to see it fixed upstream.

Funny thing is that I’ve been observing this bug for a couple of minor KDE releases and chances are it’s been around for much longer than that.

This situation got me thinking about the benefits of taking pro-active stance on Bug reporting. Drawing on myself as an example I admit I’m not a programming type of powerful user though I can do some trivial bash scripting. It takes 5-10 minutes to create a BugZilla account, just like with any other web-service be it an Internet forum, social-networking web-site or something else. Then how much time you’ll spend filing a bug report is a matter of how difficult to describe your bug is. You may be happily done in under a minute or two but yes you may spend 10-15 minutes just describing one bug as I did today.

Anyway, with the free nature of KDE you don’t have to wait anymore and guess if big corporations consider this or that bug particulalry essential or important enough to resolve asap. You don’t have to be a programmer/developer it is suffice to be computer literate and being able to articulate your thoughts and observations in concise and clear manner.

I mean pondering over the today’s situation with bug 242159 I wonder how much more time would it take for this trivial but important from a user’s standpoint bug to get fixed? A few more minor releases? Or perhaps even more? I was a little surprised that I was the first to “officially complain” about this issue since I figure Pastebin Widget is a very popular one.

I’m making a point that taking 10 minutes pays its way. I spent only 10 minutes to make people aware of the issue and it took approximately 40 minutes in total for a developer to fix the issue (and fix another one that was noticed due to my bug report all during the same time frame of 40 minutes). So, 40 minutes to fix 2 issues against months that this defunct functionality has been around. And we should remember that this wasn’t done for me personally. Thousands of people have actually already benefited from my 10 minutes time investment and 30 something minutes of the developer’s time investment.

Adding information to existing bugs I believe adds important details and puts a good pressure on developers to get around to fixing the issue. Which consequently nears bug resolution pretty fast.

Also, as a side effect, and a good one, going through existing bugs you may find interesting solutions to some problems that haven’t been fixed yet but can be addressed at least temporarily.