Scriptfu: background a process and display spinner

I’m not sure why I’m particularly proud of this script snippet but since I couldn’t find anything similar on the web, I’ll post it here for posterity sake.

The snippet below runs a long running process (in this case a maven build) in the background while displaying a “spinner” animation to the user.

#!/usr/bin/env bash
build_async() {
	# checks if a pid is still running
	is_running() {
		kill -n 0 $1 &>/dev/null
		echo $?
	}
	retval() {
		wait $1
		echo $?
	}
	
	echo "Building "
	SPINNER='|/-\'
	echo -n "Running background build  "
	mvn -Dmaven.test.skip=true assembly:assembly &>/tmp/build.txt &
	PID=$!
	RUNNING=0
	
	# drawing the spinner:
	while [ $RUNNING == 0 ] 
	do
		SPINNER="${SPINNER#?}${SPINNER%???}"
		printf '\b%.1s' "$SPINNER"
		sleep 1
		RUNNING=$(is_running $PID)
	done
	# making sure the background process worked
	if [[ $(retval $PID) == 1 ]]; then
		echo "ERROR: build failed, check /tmp/build.txt"
		exit 2
	fi
			
}

Microsoft admits: it costs less to run Linux

Buried in today’s news of Microsoft’s pricing scheme for their cloud service, aka Azures, is some amazing insight into their own IT infrastructure costs.

Before we continue, I suggest you go here and become vaguely familiar with Azure’s pricing structure.

Now that you are back, the most important number to look for in their pricing scheme is the overall cost of a running a CPU for a full hour (commonly known as cpu/hr) which, in the cloud age in we live in, is the common currency of all providers. Microsoft clocks in at 12 cents per cpu/hr. That is very important since it gives you a fair ratio by which to compare providers and how efficiently they are at running their IT departments.

For instance, Amazon Web Services (AWS) – undoubtedly the market leader and Microsoft’s real competition – is able charge $0.10 per cpu/hr (http://aws.amazon.com/ec2/#pricing) which, besides being 20% cheaper, also conveys that they are able to run their IT infrastructure 20% more efficiently than Microsoft. But why should you care?

Amazon is not in the business of selling enterprise IT software (at least not their own software) and services, much less operating systems expertise. However, buried in their cost structure is the idea that they are able to deliver an internal (and external) IT infrastructure that is 20% cheaper running Linux than the best Windows IT infrastructure in the world – assuming that Microsoft employs the best Windows engineers in the world. That is truly mind blowing especially if you factor in that in both cases you can cross out the cost of licensing (assuming that Microsoft’s IT doesn’t pay Microsoft for licensing of their software and that Amazon does not pay to run Linux).

An astute reader at this point of the post is either asleep or noticing that I’m overlooking a basic rule of pricing: it’s not just cost but cost + margin and maybe Microsoft’s margins are just much bigger? This is really unlikely, especially if you keep in mind that to Amazon, AWS was always intended to be a revenue generating engagement (otherwise why bother?) meanwhile to Microsoft, which feels pressure to embark in the cloud hype, this is more of an attempt to remain relevant which would require a much lower return, maybe even revenue neutral.

Again, why does this matter? I believe it matters a lot, especially if you are in charge of running a large “enterprise” IT infrastructure in which you benchmark your “cpu/hr” cost against others to assess overall company efficiency. If you are building your infrastructure around Microsoft products you can expect to hit a theoretical limit of $0.12 cpu/hr, meanwhile, on a Linux deployment modeled by Amazon, the bar is much lower at $0.10 or less (since we don’t know Amazon margins).

Lastly, the question that remains to be answered is how many MBAs worked on coming up with the proper pricing structure for Azure without foreseeing its market implications?

Getting to know Ida

Just finished watching the History Channel’s special on Ida, our 47,000,000 years old common ancestor. All I can say is that it will leave you breathless!

I particularly enjoyed how they explain this discovery in relation to Lucy and I was also pleasantly surprised that Donald Johanson is a professor at Arizona State.

Check it out:

http://www.history.com/content/the-link

Also worth mentioning is the discussion of the role of evolution in all of this (towards the end of the show). Professor Johanson does a remarkable job of presenting a candid take on the fabricated “controversy” surrounding evolution.

Why Python should adopt the mono runtime

So I thought about this on my drive back from the gym today. What I believe Python needs for world domination is to drop its C runtime and adopt the mono runtime as the new “blessed by Guido” implementation. Why you may ask? It would bring together one of the best languages ever developed with one of the best runtimes in the world.

To put it differently, it gets the python guys to focus on the core language (which they are amazing at) and gets them away from being runtime developers (which they are not so good at) but, instead, Miguel and company are.

Think about it, Python users would get instant access to all of the CLI libraries (and vice versa), a fairly sane way to port C libraries to the CLR and instantaneous ass-kicking performance. For the mono guys, it would give it a jazzy new language to kick start the next generation of apps.
Don’t get me wrong, I’m not saying that there’s anything particularly bad about C# but, just like Java, in this day and age, it makes you feel like you are developing in 90′s technology.


Why forks don’t matter:

Before I get flooded with emails about IronPython, Jython, PyPy to IL compilation and all other nonsensical edgy stuff being done by people with too much free time, I’ll give you my “forks don’t matter” speech.

Let’s say If you and I were friends and I came to you and said…

Me:

You won’t believe it… I just bought last weekend’s Cards vs Eagles football on ebay, it’s freaking awesome!”

You:

Well, I have a football too, got it at WalMart and it is works just like yours

[Me punching you in the face]

But that’s the point, a functional copy of what I have, is not what I have. (IronP|J)ython is not Python, it’s something that behaves like Python but, fundamentally, it will never be the original. In practical terms, that’s how Linus can manage thousands of forks on the linux kernel and still hold the “one true” branch of the kernel – the forks don’t matter.