Skip to main content

Going Linux, setting things up

And so it was. Burning Ubuntu 12.04 on a blank CD was the last action I performed using the Windows operating system, all Linux from now on.

Without looking back, I rebooted the machine with Ubuntu 12.04's installation CD in, and waited for the worst. I was actually surprised to discover how painless the installation process had actually been. It wasn't long before I logged in into Ubuntu and started poking around.

Turns out Ubuntu has windows as well (the irony), they just look funny with their Minimize/Maximize buttons aligned to the left (wrong side, that is). The general look reminded me of a Window flavored UI, but the really cool thing was that my wireless Microsoft keyboard and mouse worked perfectly right from the get go, who would have guessed?

The next stage was to get my environment up and running, and since I have a laptop and an LCD panel, it seemed natural to first set up a dual display before moving on with my life. Little did I know, that upon deciding to do so, I was actually buying a ticket to Linux land for the better half of my day. Having my laptop's display extended to a standard LCD panel did not seem like too much to ask at the time, in fact I'd had a setting just like that for years on my Windows machine. Just plug in your LCD and "Fn" + "F-Something" your way to victory, I thought to myself naively  Well, that's not how Linux rolls. After googling it for a non-negligible amount of time and asking around for advice the answer finally revealed itself "Yeah, this doesn't work in Ubuntu out of the box", to which I replied with "Say what? Sorry, I must have misheard you, because I thought you said Ubuntu, a modern operating system, doesn't provide me with dual display capabilities out of the box". Guess what? Seems like it doesn't, and since it's an Open Source world, there's about a gazillion scripts claiming to solve this, while most of which do very little in reality. In the end I had to download a package called "disper" to get it done, but it's still buggy, and far from being satisfactory. Unless I'm missing something, one must manually activate and deactivate the dual display settings each item docking or un-docking takes place, medieval style.

Once dual display was in place it was time to install Java. Fun fact #109, Java, which has always been the symbol of free, Open Source software to me, is no longer so free, or at least no longer freely distributed due to license issues, which has made its installation (the details of which I'll spare the reader[s]) both manual and laborious for a newbie like myself. This must be causing some Java classes to turn in their garbage collectors (and community members to turn in their graves, respectively).

Unless I'm the only user on earth to ever need a dual display (or Java), I'm not sure I understand why something so basic was not part of the distribution in the first place. Moreover, downloading packages in order to gain some basic functionality (dual display, UI color schemes, keyboard shortcuts, etc) seems to be the rule rather than the exception. While it may be nice to have alternatives and a way to customize so many aspects of my system, why can't I just have a distribution that works out of the box?

I believe these two cases represent a line of thinking (in addition to serving as a proof for my incompetence with Linux at current times). Ubuntu gives one a raw operating system, unpolished, rigid at the edges and hardly pleasant to use. Some would argue I'm given a raw power I simply haven't learnt to master yet. A power so great, it must be tamed before I can even glimpse at the possibility to enjoy it.
Time will tell, whether it will be me who consumes it, or the other way around...


Popular posts from this blog

Sending out Storm metrics

There are a few posts talking about Storm's metrics mechanism, among which you can find Michael Noll's postJason Trost's post and the storm-metrics-statsd github project, and last but not least (or is it?)  Storm's documentation.

While all of the above provide a decent amount of information, and one is definitely encouraged to read them all before proceeding, it feels like in order to get the full picture one needs to combine them all, and even then a few bits and pieces are left missing. It is these missing bits I'll be rambling about in this post.

Dependency Injection - The good, the bad and the ugly

The Good
Dependency injection (DI, a.k.a IoC - inversion of control) is a well known technique to increase software modularity by reducing coupling between modules. To provide the benefits of DI, numerous DI frameworks have arisen (Spring, Guice, Castle Windsor, etc.) all of which essentially give you "DI capabilities" right out of the box (these frameworks tend to provide a whole lot more than just "DI capabilities", but that's not really relevant to the point I'm about to make). Now, to remove the quotes around "DI capabilities", let's define it as a DI container - a sack of objects you can manipulate using a provided API in order to wire these objects together into an object graph that makes up your application.

I've worked on quite a few projects employing Spring, so it will be my framework of reference throughout the rest of the post, but the principles and morals apply just the same.