Eventually having connected my amd64 desktop upto a decent internet connection, I decided to wipe the FC3 install on the box and replace it with ubuntu. I left my i686 gentoo install alive and started out on an Ubuntu 6.06 LTS (aka Dapper Drake) install, sometime around 11 PM.
My hardware setup is not what I would call conventional. Inside my monster tower I have four SATA ports - two of them on the motherboard and a couple more on my RAID controller. The first port is occupied by my 10k RPM 80gig drive which is basically my boot drive. The other onboard port has a 120 gig drive, which is my secure (AES256) storage and is hardly ever mounted. There are two 200 gig SATA drives connected to the RAID controller (Promise), which after a couple of abortive attempts with dmaraid, have ended up as discrete SATA disks instead of in RAID-0.
Now, as soon as the Dapper liveCD boots, the disks on the RAID subsystem show up as sda and sdb. The onboard SATA controller gets relegated to sdc and sdd. I thought it was strange, but I picked the renamed partitions and went through a complete install with this setup. The first reboot just froze the machine with a pretty GRUB on the left corner. Modifications of device.map, replacing the hd1 entries in the boot menu did nothing either. Whatever I tried, the machine just threw up a blank GRUB stage1.
As it turns out the BIOS and grub still recognize the onboard SATA channels as the first pair of hard disks, but half-way through stage2 of the boot the kernel takes a flip and then it all goes south for the summer. Faced with the renaming, I tried to connect the boot drive to the RAID controller, just to bring it back to sda. But as it turns out my BIOS can only boot off onboard primaries. Which all left me up shit creek without a paddle.
Now, dapper is not without its advantages. The live CD installer meant that I could do more than just watch the lines scroll while the installer did its magic (anyone remember the caldera tetris games ?). So I still had a functional internet browser even though my machine wasn't booting (grub ensured that I couldn't boot gentoo).
Thanks to the internet, I came to know that I wasn't alone (*play x-files music*). Turns out somebody had run into this Grub of Death before. Also there lay open a launchpad bug in the helpful status called CONFIRMED, which basically meant I had run into something real (like an iceberg). As luck would have it, someone had already sent a patch to work-around the problem in kernel land - and it had been rejected. All this was no help at all, till I discovered magic beyond mere device names.
UUID mounts: /etc/fstab could use other identifiers than raw device names to uniquely identify drives. And the first patch I discovered dates from 2001 - this must've been the *best kept secret* in linux kernel land. As it turns out, both grub and /etc/fstab will accept volume UUIDs, completely transparently. But still the installer couldn't figure out where to put grub or what to put in it. At around 3 AM, I managed to pry open my machine, pull out the off-board SATA and attempt a reinstall.
The system reinstall went almost perfectly. All that was left to do was to replace the device names in the relevant sections with the correct UUID volume names. The unique identifiers can be read easily using the blkid command. A couple of reboots later, I plugged the RAID controller back in and added those partitions similarly.
It all worked out, eventually. But the amount of effort it took to get it working reminded me of those nights in 1999, spent struggling with an X configuration, with some magazine's help section open.--
"First things first -- but not necessarily in that order."
-- Doctor Who
For the past weekend, I've been roaming the corridors of FOSS.in. I've never attended a talk about something I could figure out for myself, but still there were four talks which I sat through - a grand achievement, compared to the meager two talks last year.
But I wasn't in Bangalore for most of last week. I'd gone home to tie up some loose ends and cleanup my act before I dived into the conference. I reached back in Bangalore only early morning of Thursday, just in time to catch up to some sleep. I took a preliminary peek at the venue on thursday itself. The place was hum of activity with the volunteers stuffing delegate kits, falling lampshades and power mayhem.
And then on friday, it all began. As I watched the lines for registration grow, I noticed a general paucity of the number of delegates this year. Since the conference was on a weekend, I had hoped for more students in the crowd, but that was not to be (as far as I could make out). But thanks to the weekend, there was a larger crowd from outside Bangalore and that's always a good thing.
Since I was a care-free delegate, I had planned to do a security BoF at the conference. But when that didn't quite materialize, I gave up on the idea. Backporting a dbus-send shared connection patch was trivial, but was wasted because we couldn't get beryl to flip the windows for the projector display. Except for that random hack, I didn't touch a single line of code during the conference.
The inaugural keynote was by Suparna Bhattacharya, a kernel developer from IBM. As much a fan I'm of minimalistic development, I skipped out early to find a decent cup of coffee instead. My abominable behavior notwithstanding, it is a proud day for the Indian FOSS community to have an Indian on the podium, for a change.
And then I ran into a surprise. One of the dotgnu libjit developers, krokas, had flown in to India and met me in one of the corridors. Even though I'm not a great fan of his business ideas on professional opensource, it was nice to actually meet one of your fellow developers face to face. Met a couple of people from Microsoft too, discussed a bit of C#/.NET technical quirks (GC-able assemblies), dodged the "what'll it take to get you to work at Microsoft" question and kept wading through the crowds.
One of the talks I actually attended, by Andrew Cowie touched up on a few problems the ubquity of mono brings along, especially considering the latest Novell developments. Initially voiced by Seth Nickell, I find it is a valid concern. For instance, I've never suggested dotgnu to anyone who's wanted to write an application from scratch. Anyway, that talk covered all the normal obstacles that developers place in the way of external contributors and in general was interesting enough to keep me from wandering out.
Another one of the talks I dropped into was Get Rich with Php5 talk by Rasmus. I knew from the slides that it featured my work for the last year - APC. But the content of the talk was still interesting, especially the benchmark numbers for each increment.
The BoF tents looked more interesting than last year. But the initial lack of chairs killed a bit of the enthusiasm. Also moving the FOSS Expo area out of the main lobby area made it almost pointless. Before long we had converted the project expo into a live demo for ioquake3 - sweet GPL love from Id. Though Dalfry ruled the roost for the first fragfest, I eventually climbed the levels due to the basic advantage of knowing the maps by heart.
The other couple of talks I dropped into were the panel discussions about 10 years of Linux India and spo0nman's monitoring with nagios talks. The panel discussion was slightly boring, mainly because the panel wasn't split on most of the issues and the crowd lacked the trolls required to make the discussion interesting. And the only question I held in my hands was about the history of PCQLinux, without which half the FOSS folks in India today wouldn't have ever used it - probably the action of greatest consequence in the last 10 years of FOSS in India. But that was skimmed over with a passing reference.
And then there was the cool stuff left - the jokes, the corridor conversations, the conclusions and the arguments. I'll let a few pictures speak for themselves. And maybe this video (mp4, 12.1 Mb).
But let me calm some fears expressed in the discussions. The growth of FOSS in India has been fairly organic for the hobbyist category, while the explosion of user mass worldwide has pulled up the number of programmers getting paid to write FOSS. The community entries in this game has still retained single digit significance in the last year as it has for the past years - but that is not something to get alarmed about, because we've now got employees contributing to FOSS. Things could be a little better - but that's always the case.
All in all, a good conference. But I've got more plans for next year. Rather than mere BoFs, we should be able to run a mini-conf in the middle of a conference with the speakers present. I suspect that it might be possible with a bit of fine-tuning in the event in real time, rather than organizing a whole parallel set of talks. But next year is nearly a year away ;)--
People who go to conferences to talk are the ones who shouldn't.
Today afternoon, Yahoo! will pay for your coffee.
Just make sure you land up at Taj Westend, to listen to eminent Yahoo! speakers like Sumeet B. Mulani, Rasmus Lerdorf, Philip Tellis and Gopalrathnam Venkateshan (not me, the other gopal). The talks will cover the breadth of frontend technology Yahoo! uses, from PHP into the YUI libs, JSON and other fnuk.
Make sure you show up and drink in the talks ... uhhh.--
When we talk of tomorrow, the gods laugh.
T minus 20-odd hours left for FOSS.IN and if you aren't going to show up, you don't know what you're missing. This isn't just one technical conference by itself; it is sort of an excuse to meet up for a couple of un-conferences.
While talks dazzle the audience in the big halls, the crowds milling around in the corridors run their own version of foss.in, swapping stories, discussing the last year's developments. Largely unorganized, a large majority of the indian foss community meet up, touch bases and in general have a lot of fun. And eventually something like this gets discussed.
So prepare ...--
I'm prepared for all emergencies but totally unprepared for everyday life.
I've been playing around with twisted for a while. It is an excellent framework to write protocol servers in python. I was mostly interested in writing a homebrew DNS server with the framework, something which could run plugin modules to add features like statistical analysis of common typos in domain names and eventually writing up something which would fix typos, like what opendns does.
To my surprise, twisted already came with a DNS server - twisted.names. And apparently, this was feature compatible with what I wanted to do - except that there was a distinct lack of documentation to go with it.
7 hours and a few coffees later, I had myself a decent solution. Shouldn't have taken that long, really - but I was lost in all that dynamically typed polymorphism.
from twisted.internet.protocol import Factory, Protocol from twisted.internet import reactor from twisted.protocols import dns from twisted.names import client, server class SpelDnsReolver(client.Resolver): def filterAnswers(self, message): if message.trunc: return self.queryTCP(message.queries).addCallback(self.filterAnswers) else: if(len(message.answers) == 0): query = message.queries # code to do a dns rewrite return self.queryUDP(<alternative>).addCallback(self.filterAnswers) return (message.answers, message.authority, message.additional) verbosity = 0 resolver = SpelDnsReolver(servers=[('18.104.22.168', 53)]) f = server.DNSServerFactory(clients=[resolver], verbose=verbosity) p = dns.DNSDatagramProtocol(f) f.noisy = p.noisy = verbosity reactor.listenUDP(53, p) reactor.listenTCP(53, f) reactor.run()
That's the entire code (well, excluding the rewrite sections). Should I even bother to explain how the code works ? It turned out to be so childishly simple, that I feel beaten to the punch by the twisted framework. To actually run it in server mode, you can start it with twistd -y speldns.py and you have your own DNS server !
In conclusion, I hope I have grossed a few of you out by trying to do soundex checks on dns sub-domains.--
DNS is not a directory service.
-- Paul Vixie
The manifesto ostensibly wants to roll back the clock and go back into the past.
I'm doubtful whether it is possible to achieve this, mainly because
of a few laws of
thermopeople-dynamics. Reducing the head
count by 20% is not going to improve performance and all you might
end up doing is to give the rest a persecution complex and possibly
increase their workload. And all that after admitting to bad decisions in investment
Then the wage strawman is throw in, always available as a convenient reason for low productivity.
Moreover, our compensation systems don't align to our overall success. Weak performers that have been around for years are rewarded. And many of our top performers aren't adequately recognized for their efforts.
Pay packages are generally a function of the years of experience. A 10 year experienced employee churning out run-of-the-mill code will get paid more than a 2+ guy writing top of the line code. The pay parity that the company keeps is indirectly unfair and enocurages you to be as stupid & worthless as you can be, yet earn more than the hard-working junior.
Those are the rules of the game and some of us have come to accept that as inevitable. But when you hear rumours (in Economic Times, no less) that fresh campus recruits are going to be paid at par, maybe a bit more than what you are earning, the quoted paragraph makes no sense.
As a result, the employees that we really need to stay (leaders, risk-takers, innovators, passionate) become discouraged and leave.
Well, duh ! If they didn't leave, they'd hardly qualify as people with initiative. I've put down my take on that, a while back. That bit of wisdom from a senior VP, vindicates my personal feelings (or does it prove that I'm not a risk-taking passionate innovator, because I'm still sticking around ?). And maybe ... just maybe toolz had a point.
All in all, I assume that the author of this Manifesto wrote it out of pure good-will, frustration and naivete, as a last call to turn the company around. For once, I'd like to think the dilbert cartoon above is completely fictional and bears no resemblance to any company, outside of a cartoon.
Either way, que sera, sera.--
Give me the strength to change what I can, the inability to accept what I can't and the incapacity to tell the difference.
-- Calvin prays,
There are no innocents in this war. To not have an opinion is treachery to a greater cause - for it needs nothing more for evil to thrive than good men to stay out of the battle. But when the battlelines are a line in sand, unclear & transient, only a vocal minority survives a twinge dissent in a dystopia which rewards disloyalty with a jingling bag.
The squeaking wheel always gets the grease, but does a wheel squeak for all others bereft of lubricant ? But there are wheels within wheels, connected cogs running this juggernaut that fulfils our needs, wishes and aspirations. This isn't a zero sum game, where everyone else has to lose.
But silence is golden. In fact, it will be bought with gold, spices and precious stones. The turncoats reap the profits of their new found discretion and the immorally inept, failing to curb their conscience, experience a re-run of Mr Carrot meets Mr Stick.
Like in the game in its simplest form, the winners always defect.--
It occurred to me that my speech or my silence, indeed any action of mine, would be a mere futility.
-- Joseph Conrad, "Heart of Darkness"
I've been a great fan of Terry Pratchett ever since the day I started reading the Discworld novels. Rather than raw fiction, it is philosophy, social commentary and a sprinkling of cynicism, which makes his books so enjoyable. The last in the line of books is Thud! (read it to get the Him diamond quote) started to read the Science of Discworld and sort of looking around for Wintersmith. So just out of curiousity, I started counting the Pratchetts I've read and as it turns out, I've read 42 of them. Here's a quick list of what I've read (in no particular order). If you liked Douglas Adams and wanted him to be more Tolkien, while making fun of the modern world - pick up a Pratchett, any one.
Ach, crivens !, wish'e could squiggle a neece ending to all yen tales - ye ken ?.--
[A Human] ... is merely a means for a book to create more books.
-- Daniel Dennet
When Douglas Adams wrote about immortality, he talked about the impossibility of boring yourself to death on sunday afternoons. He wasn't kidding. Right now, I've hit the lowest spot I've hit ever since I left college. Even during the blindingly bright (and hot) summer days in Hyderabad, toiling away at a job I didn't like, did I feel so hopeless and lost.
Personally, financially, career-wise, health-wise or any other way that is obvious to me now, I've never had such a dark time before. I've come to terms to personal failure the moment I stepped out of childhood, the last year has taught me to deal with fall of those giants on whose proverbial shoulders I've stood. But these last few days have taught me that I have nothing left to rely upon - no anchor to hold me steady through the tumultous times ahead. Got nothing to hold on to, nothing left to aspire to, nothing to work with - I got nothing.
All I seem to have retained is my perspicacity.
The fates owes me big, she owes me a big one. Or maybe I should just give up like my old man and go down with captain & all. Quitting is easy ... just stop trying.--
There are worse things in life than death.
Recently, I've seen a lot of serious photographers start to watermark their images. I'm not one of them (yet), but I hacked up a quick script to watermark a photo in gimp without much fuss. Basically the script lets you paste a transparent image on your image and without actually using a UI.
To install, copy the watermark.py to your ~/gimp/plug-ins/ and chmod +x it. And to use in batch mode, you'd probably do something like this :-
gimp -i -b \ '(python-fu-batch-watermark 1 "x.jpg" "watermark.png" "y.jpg" "rb" 33.0)' \ '(gimp-quit 0)'
A more sophisticated invocation would avoid spawning a new gimp instance for every image edit and would truly operate in batch mode.
(for each in images/*.jpg; do NEWNAME="`echo $each | sed "s/\.jpg$/_wm&/"`" echo "(python-fu-batch-watermark 1 \"$each\"" \ "\"watermark.png\"" \ "\"$NEWNAME\" \"rb\" 33.0)" done echo "(gimp-quit 0)") | tee /dev/stderr | gimp -i -b -
Now that truly shows the power of small bits put together, with the odd bug thrown in for good measure.--
Great acts are made up of small deeds.
Very little is known about the Life and Mating Habits of the common Code Monkey. But that should come as no surprise to anyone who has observed a specimen in the cubicles of Asia. But observations from cubesville have often been indicative of a certain flux in the population - a trend to migrate over longer distances. Unlike the famed lemming of the north artic tundra, which takes a downhill (to say the least) approach, this migration is more often in search for higher ground. Is there some herd mentality to it or is it merely an individual moving on ? Join me, as we dig deeper into the mysterious world of the code monkey.
Of late, I've been feeling the urge to leave Yahoo! and go do something else. I couldn't explain exactly why, because I probably have the best job imaginable - work on what I want, from wherever I want, a couple of meetings a month and play pool all afternoon. But the urge was still as strong as ever. It needed a rational explanation and I started to itemize and categorize the possible reasons as objectively as I could. A couple of recent discussions on slashdot and india-gii have added fuel to that fire and then I read this.
Career Phases: In general, the company you work for is really really important for your first couple of jobs. It should come as no surprise that junior engineers want to work with a strong brand. This sets them up to move onto be senior engineers in places which pay better. Experienced engineers are not too desperate to seek out things which look good on their resumes - they're interested in other aspects of the job than how good it will look on their resume in a couple of years.
There's a flip side to the career phases argument too. If you've read the Discworld series by Terry Pratchett, you might remember a class of wizards known as the Sourcerors. Now that nearly all magical spells have been formed out of the raw magic, the discworld needs no more sourcerors.
Now, software companies are like miniature discworlds. There is a phase in the company's life cycle (it is a cycle, it repeats) when the ground is fertile for new ideas. And this age of miracles, attracts the brilliant miracle worker who can shape reality around such ideas. But such proto-geniuses have little to do in the adolescence of the company. As the work force muscle builds up, the concept of a superstar engineer dies and slowly but surely, the emphasis shifts to overall throughput of a team than individual brilliance. When a manager (and his team) can outperform any individual engineer at the same task, the company needs the best managers they can get, rather than a couple more brilliant code monkeys.
People outgrow companies and vice versa.
Wages: Money is like air. A little bit more doesn't do much when you have enough, but you'll know it when you are running short. But there does exist a certain stress level beyond which people do not think it is worth their pay to work - but a large percentage of salaried workers never approach that limit. That is where an interesting economic hypothesis pops up - Efficiency wage hypothesis. Even when you get paid enough, merely the fact that you are paid does not induce any sort of gratitude or loyalty towards your employer - it is money in return for services rendered. But as the shirking model in the theory indicates, often you do get what you pay for.
Pay hikes are often nominal and are significant only when you are promoted. Meanwhile people being freshly hired are being hired at pay scales more in terms with the market demands. Over a period of two or three years, the difference between your hiked pay and your peers being freshly hired climbs to a significant value to prompt you to get back to level. Most companies to refuse to raise the pay of a long standing employee to the levels of a freshly hired of similar level, giving various excuses - the most general of which go - who told you that ? That's not true. And in this world of salary confidentiality, rather than counter that argument, you'd probably try to get a better pay package elsewhere - and you probably will.
Raises don't match lateral entry pay packages.
Vertical Space: Most indian companies don't have a good technical ladder. In an industry where company half lives are measured in years, waiting around for those above to retire is hardly any option. Generally the way to climb the ladder is to move somewhere where you're closer to the top and work towards building the rest of the ladder downwards. In other words, the easiest way to get promoted is to be somewhere small and grow along with it - after all companies don't need to be promoted (*sic*) to grow. But some are unfortunate enough to end up pushed down as the management brings in fresh talent to supplement the growth. This is somewhat in line with the career phases argument where fast growth, high risk approaches are suitable after the initial few years of establishing a brand pedigree.
Last one out is a...: Community is a usually disregarded factor when considering job hopping. But the web of friends can outweigh some of the advantages a job hop might bring. More important would be your relationship with your direct boss. Having to work under a new person and develop the same rapport takes quite some effort and the average asocial code monkey dreads the thought of having to go through that *again*. On the other hand, this explains how much more precious a manager can be, because when he leaves he disturbs the general inertia of his direct reportees.
The moment the community at work starts breaking up, be it due to overwork or attrition, the downsides of leaving start to diminish. Eventually, you'll be able to point out a single departure which snowballed into a mass attrition throughout the company - even if everyone went in their own directions. At some point, a $n people can't be wrong correlation turns into a causation going into a spiral of departures.
Attrition turns into super-attrition when a strong community breaks up.
I've sort of started to understand why people need to switch jobs, about every couple of years - not out of greed or disloyalty - but as suggested by pure common sense. But a closer inspection of the scenario does indeed suggest that status quo is an assumption - a valid assumption for vast majority. That could change, I suppose (or rather, hope).
There's a corollary to all these observations, but I'll leave that as an exercise for the reader.--
The biggest mistake you can make is to believe that you are working for someone else.