It's not that I would expect anything else from someone who is a "community manager" (FOSS' modern-day equivalent to the appendix, in my opinion), but this "personal blog entry" is, of course, a steaming turd. I don't see RMS spreading FUD about Ubuntu, not at all. In fact, he makes it quite clear what they get, in his opinion at least, wrong, and why he sees it that way - and he leaves nothing about that "in doubt" or, in one way or anther, vague. Discrediting this kind of honest and up-front criticism as FUD, whilst he himself is weasling around the true motives (turn desktop users into dollar bills for Canonical's pockets) for the Amazon integration with all that hey-everybody-let's-disregard-that-and-feel-good sidetracking that's going on in that posting really makes me nauseous. "Better user experience", "creating desirable products", yaddah yaddah - yeah, fine and dandy, but trying to sell us this (in my opionion pretty crazy) add-on, that submits all the text I enter - be it to start a new program or open a document I stored - to a web service the users absolutely don't control, as an improvement for the good of the general public is not only ridiculous, but also demeaning to the intelligence of everyone who they expect to fall for the kind of "argument" Jono Bacon is trying to make on his blog. It's the FOSS-equivalent to the Ask.com toolbar, or Bonzy Buddy "form filling" browser-add on from days of yore, that Windows users get shoved down their collective throats if they miss unchecking a box in popular "freeware" installation wizards these days, and everyone with half a brain can see right through that.

That's one of the very few features that I'd always wanted Firefox to adopt from Chromium, and now it's actually happening - yay for Firefox 20. Can't be longer than a few weeks any more anyway; now can it? ;p

A Google recruiter (from Google Ireland) contacted me a few months ago due to having found my personal website (which is in German, but transported the important information nevertheless, it seems - and yeah, he definitely HAD read my resume. That said, noone cared much about what I did or did not do with my current job, noone asked me to quit it before starting the interviewing process or anything downright crazy like that.), and asked if I was willing to do a phone interview. Sure thing, I said, and after passing the first interview, I did two longer follow-ups on the phone, and finally one just recently on site in Dublin (Google was nice enough to pay for the trip and accommodation, and Dublin is a very nice place that I had always wanted to visit anyway), and last Friday, I've been offered a very attractive position in their Site Reliability Engineering team due to all of this - so I do have first-hand experience with all stages of Google's interviewing process.

Almost everything I had to do in the interviews involved stuff you're supposed to learn when studying Computer Science at a university that deserves its name, and I think that's a very good and reasonable thing. I've always been a fan of the "concepts, not implementations/products"-kind-of-education. I think that's especially important at Google - their infrastructure is so vast and powerful and unlike any other in the industry that the overwhelming majority of people who take a position there won't have seen anything even remotely like it in terms of scale, and they will probably find very little there that's overly "familiar" to them: Most of the software you can get away with running at a small- to medium-sized IT shop, despite any glaring and maybe-no-so-glaring inefficiencies, will fall apart at the scale Google would need to have it work at, so they'll implement something on their own and run that to do that job. Read the GFS paper for one such (albeit a bit dated) example. That's where all that "bachelor's level computer science stuff", a nuisance that apparently, in the eyes of some, only inhabitants of ivory towers should be allowed to care about, comes in again. So I think it's perfectly reasonable and in their best interest to test for that kind of knowledge and skills in their interviewing process.

"A number of HTML5 code has been 'unprefixed,' which means that Mozilla has decided it has matured enough to run in the browser without causing instability." - come on, how dumb is that? If there were a vendor-sanctioned CSS attribute or "HTML5 code" (or whatever, really) that was known to cause "instability" in one of the world's most widely-deployed and -used applications, trolls and/or crackers would make ABUNDANT use of that inherent weakness, prefixed or not.

Now, I don't know for sure how HTML5 "standardization" (if you can stomach calling it that...) actually works, but what I happen to have picked up is this: In reality, that kind of "prefixing" (extending the name of a soon-to-be-"standardized" identifier with a vendor-specific keyword) takes place because the vendor probably still works out implementation details, or isn't 100% sure if he wants to really do whatever the feature/thing is doing right now the way it is doing right now forever. It's some kind of "this is just a draft"-hint, like, for example, "X-"-prefixed HTTP and SMTP header data (used to be - they're abused for other, this-aint-in-the-official-standard-but-we-need-it-anyway-things today, of course). If using any of this causes the browser that implements it to crash or be otherwise unstable (and therefore potentially exploitable), that's a _grave_ bug, and certainly not something that any of the industry heavyweights (well, except for Apple and Microsoft maybe... hehe) would tolerate to occur in the wild for more than a few hours, until an appropriate patch is released.

I was not suggesting "crappy, low-end, unmaintained and undocumented piles of OSS whitebox dogshit" (torrents of foul language like that make me raise an eyebrow or two btw., esp. when you advocate the road to the mythical "stable", "proven" and "enterprise-ready" alternative in the next sentence...). But there ARE offerings that strike a sane balance between being based on standards that a multitude of vendors can implement and actually support, and come with enough handholding to get you off the ground without hickups. Check out the astersik appliances sold by elastix, for example.

If you're not going to research the offer you're buying into, you are going to have a bad time, period. You might as well spend two or three hours more to take stuff into account that isn't sold by gold-diggers who found their way into Cisco's sales channels in your area, and save boatloads of money when the first upgrade is imminent.

What I also find amusing is the notion that this kind of "OSS software" tends to become unmaintained and outdated, whilst you seem to suggest that proprietary software and solutions of that kind don't. The majority of large(-ish)-scale phone systems I know still rely on a Windows 2000 or even NT 4 server somewhere in a rack that noone wants to touch any more (or that, if you are lucky, has undergone P2V-surgery) that never receives any kind of updates or maintenance, but is of critical importance for call management, authentication, configuration, or any combination of all of the above. Yeah, that sounds super-sane to me.

That kind of thinking is what leads to the very finest of vendor lock-in you could imagine down the road - and it's total bullshit. Investing a few hours of research and setup effort in a standards-based, transparent and reusable technical foundation for what is going to be the backbone of your company's communication both on the in- and outside for many years is definitely something to worry about - unless you have no problem whatsoever with buying your whole frickin' phone system all over again once you pick up the 11th employee, because the (cheap but proprietary) license and hardware you acquired when you started out "does not support more clients", or some such crap.

We just paid a few grand to extend our phone system from supporting <=50 clients to supporting 54 (and possibly more; even up to 70!!1!) clients. That's what you get from choosing the wrong solution in the first place, and if you let it become a vital component of your infrastructure - you'll have to stick with it and it will cost you dearly, because outright replacing it with a saner choice is always the more expensive one _in the short term_. Typically until the next forced upgrade cycle comes around.

...that was (meant to be?) called Beyond the Red Line, or a different approach to making the BSG universe into an awesome space combat game?

(Downloading the source tarball right now, let's see how we get this into an unofficial Debian package...)

The hub of our communication at work is a really beefy machine running Debian GNU/Linux. Communication within the tech dept. is done mostly via IRC (our CEO is a really techy person), and email. Even some guys and gals from the Customer Relations/Editoral Staff, and the head of the Legal Department, are available via IRC at all times, which is neat. We also have a web-based issue tracker (that's controllable by email; developed in-house many years ago) that helps us keep track of things. It's pretty awesome - that kind of infrastructure is INCREDIBLY less frustrating than what we've had at companies I worked before (mainly Atlassian webapps that are all shiny and stuff, oh yay!!1!). Not as colourful and web-2.0-y perhaps, but it is fast and very much to the point. And very hackable, in the good, true meaning of the word. :)

...under "absolutely clueless" a few years ago. Can't remember the specifics as to why exactly I did right now - I think it was related to some inflammatory bullshit "articles" about GNU/Linux on CNet or something, but I have no reason to believe I misjudged him back then. So I'll pass.

... because THAT story title quite obviously is not in compliance with Adobe's Permissions and trademark guidelines!

Next time, better talk about images being "GIMPed". Just to be safe and all that ;)

Agreed! With the last part of your posting, that is: emacs, hands down. :)

Intel is doing the very same thing on their most recent "enthusiast" desktop chipsets.

For systems using the Linux kernel, there are software implementations of the very same block-level-caching-concept available - one I stumbled over is http://bcache.evilpiepirate.org/