I’ve been using Linux for most of my life now, and I’ve tried several distros over the years. I enjoyed trying out new variants as I learned about them, and after a specially intense year using Gentoo, I decided I wanted to try an easy, working out-of-the-box distribution for a change.

And so, I met Ubuntu. Since that day, I’ve never been able to stay away from it for long. Fast, elegant, well-thought. Solid software choices, vast repositories, a fast and stable release cycle. For several years, Ubuntu seemed to do everything right.

You know what I liked the most, though? I liked that I could look forward to the next Ubuntu release. I liked the fact that I just knew that the next one would bring great software improvements, better hardware support and extensive up-to-date repositories. Installing new releases was not an effort, but a pleasure. And, until today, Ubuntu had never let me down.

Now, for the first time in my life as an Ubuntu user, my new installation works notoriously worse than the previous one.

After two hours of work, Wi-fi still doesn’t work. The subwoofer makes no sound. And this one, I don’t even know how to title: a while ago, my laptop decided the fully charged battery was critically low and NEEDED to sleep/hibernate.

The switch to the Unity interface (which I strongly dislike, on top of everything) seems to be monopolizing the efforts and depriving other areas of necessary time and dedication. It’s making Ubuntu look unique, but at the cost of what already made it unique.

Why is Unity being pushed so hard? It’s nowhere near mature enough to be the only interface shipped with the system. Do they want Unity netbooks, or Unity tablets? Do they think they’re late to the tablet party, and are trying to catch up?

Whatever the reason, the spell of Ubuntu seems to have faded. I will not tell anyone to install this version, specially non-tech people that need their systems to just work; and rather than looking forward to the next release, I’m thinking of Fedora.

int main(int argc, char** argv) {
    printf("Goodbye, World!");

Dennis Ritchie

“It is impossible – absolutely impossible – to overstate the debt my profession owes to Dennis Ritchie. I’ve been living in a world he helped invent for over thirty years.”

– Tim Bray

“Even in his modest way, I believe Dennis was very proud of his legacy. And rightfully so: few achieve a fraction as much. So long, Dennis, and thanks for all the magic.”

– Rob Pike

Descanse en paz, maestro.

A friend of mine pointed me to this article, a well-written guide that describes the process of creating an x86 VM that can run Android, in an attempt to provide a faster execution environment for development.

While the title of the article, How to speed up the Android Emulator, is somewhat misleading, the author does dedicate a section to explain why an x86 VM easily outperforms the de-facto Android Emulator:

…[The] Android Emulator emulates a real ARM processor on top of an x86 processor. This is a lot of overhead.

At least for quick test and demonstration purposes, I don’t need to emulate an ARM processor, I just need to be able to run Android and my application.

He makes a good point: emulating a full ARM-based machine on top of an x86 architecture is certainly expensive, and the performance loss is immediately evident to anyone that uses the emulator.

However, it’s important to understand that, by using this approach, we’re not actually speeding up the emulator, we’re replacing it with a simulator. It is not the same. The execution environment will behave similary, but it won’t be a ground-up sandboxed reproduction of the actual thing. It’s impossible (to my knowledge, at least) to predict if and where differences will emerge during the development of an application, but the risk does exist. You may end up fixing something that is not really broken, or satisfied at the look and feel of something that will behave differently when deployed.

It all boils down to a classic emulation dilemma: performance vs. fidelity. As long as you can afford the performance loss, it’s always good for the emulation to reproduce the real environment as accurately as possible.

The choice is, I think, entirely personal. I don’t feel the Android Emulator is slow enough to justify the introduction of this additional concern, but that’s just me. The day may come when I really need an extra performance boost to test out a feature, but for now, I’ll stick with the emulator. If you choose instead to use an x86 VM for development, however, do keep in mind that you’re not speeding up the emulator, you’re eliminating one of the abstraction layers, and loosing accuracy in the process.

Summing up, both choices have merits and flaws. The decision is personal. Just make sure you understand it.