Linux, meet SO_REUSEPORT

The Linux 3.9 release finally introduced a — at least for a networking geek like me — long awaited extension to the socket model: the SO_REUSEPORT socket option. Not to be confused with the virtually default SO_REUSEADDR POSIX socket option, SO_REUSEPORT has its root in BSD 4.4 and offers the ability for multiple, independent processes to listen on the same port at the same time.

This basically means, that from Linux 3.9 onwards, we no longer need to build our own fork(2) hell-based master/slave watch dog contraptions to have multiple processes handle incoming connections efficiently. Instead, we can now leave this to the kernel and just spin up the listening processes we need. As pointed out on the Free Programmer's Blog, this is especially exciting for programming languages that are, mostly due to implementation specific issues, inherently shitty or incapable of any kind of parallel execution — like Node.js, Python and Ruby.

However, it should probably be kept in mind, that while this is at least in the long run a Godsend in terms of reduced complexity for simple applications that just need some kind of parallel execution, it's still likely that the solution is not necessarily the performance wise most optimal as we approach extremes. This could probably do with a round of benchmarks, but for now I'm just glad that my days of being dragged kicking and screaming through people's optimistic implementations based on complete disregard for documentation about the exact consequences of the forking process model might slowly be coming to an end.

September 1, 2013 | Permalink

A death of distinguishing signifiers for UI elements

Say what you want about the tab hating "king of usability," Jakob Nielsen, but a study released yesterday by his consulting firm, Nielsen Norman Group, on tablet usability concluding that "flat design and improperly rescaled design are the main threats to tablet usability" is absolutely spot on. While some of the points seem like more of an observation of the evolution of user interface paradigms we've seen occur numerous times over, his point about the recent "design" (or "undesign"?) trends can be applied far more universally than to the limited scope of big touch devices:

Why not allow users to easily see what they can do? We need a golden middle ground between skeuomorphism and a death of distinguishing signifiers for UI elements.

I, for one, dread the release of iOS 7. Not only because it will make my everyday experience worse, but mostly because less tech savvy people will likely hit a solid wall, and, like in the Windows days, we're left to clean up the mess.

August 6, 2013 | Permalink

More encryption is not the solution

Poul-Henning Kamp of many fames published an interesting article in his ACM column earlier this month. The article, "More Encryption Is Not the Solution" comes in the wake of the recent NSA revelations of Big Brother being quite real and watching intensely, a revelation that has prompted a lot of people — myself included — to start embracing ever stronger security measures in our daily communications such as encrypted e-mails and OTR based chat. Kamp however argues in a semi-conspiratory way, that this is a pointless as the political deck is somewhat stacked against privacy of the individual.

While somewhat extreme in cases, parts are scarily thought provoking and as a whole it's well worth a read, although one should keep in mind that the base of Kamp's reasoning seems to be commercially enabled "secure communications," which is not entirely unreasonable when considering the broad public, but certainly oversimplifies the problem. However, no matter what, it's hard to argue with his conclusion:

[...] But for Mr. and Mrs. Smith, the solution can only come from politics that respect a basic human right to privacy—an encryption arms race will not work.

July 31, 2013 | Permalink

Why mobile web apps are slow

Drew Crawford has done an extremely well researched analysis of exactly why even well supported JIT compiled code written in dynamic languages — especially on mobile devices — still and basically always will fall short of writing the equivalent as compiled code, no matter how many script kid fallacies you throw at the problem. For people not used to reading well researched work, it's quite long, but if you read only one piece of such work this year, make it this one. Essentially, Drew Crawford does a good job of hammering the points of why compiled languages like C, C++ and similar derivatives will always beat your favourite JIT compiled dynamic language. And, guess what? It's not religion. It's something as simple as design tradeoffs made by the language designers offering you productivity niceties at a cost.

However, despite how interesting the article is in itself, the best part about it is the fact that it's a self-reinforcing call for developers to start employing at least a modicum of scientific methodology in their work:

If we are going to make any progress on the mobile web, or on native apps, or really on anything at all–we need to have conversations that at least appear to have a plausible basis in facts of some kind–benchmarks, journals, quotes from compiler authors, whatever. There have been enough HN comments about “I wrote a web app one time and it was fine”. There has been enough bikeshedding about whether Facebook was right or wrong to choose HTML5 or native apps knowing what they would have known then what they could have known now.

The task that remains for us is to quantify specifically how both the mobile web and the native ecosystem can get better, and then, you know, do something about it. You know–what software developers do.

I couldn't agree more.

July 22, 2013 | Permalink

Apollo 11 launch at 500 frames per second

As a kid, very few things fascinated me more than space flight (I clearly remember yapping my dad's ears off about the different stages of the Saturn V launch vehicle's flight cycle.) To this date, that fascination has stayed with me, and possibly only grown greater as I've started to grasp the true extent of the space programmes. Maybe young me would have loved it, but videos like this one by Spacecraft Films from the launch umbilical tower of the Apollo 11 flight from 5 seconds before liftoff at 500 frames per seconds leave me in absolute awe:

July 21, 2013 | Permalink