I am reminded of longfellow's lines:
Art is long, and time is fleeting,
And our hearts, though stout and brave,
Still, like muffled drums, are beating
Funeral marches to the grave.
No one really has enough time, we all swim in the same complex ocean of time and space; and we need to set our directions and our priorities right. I hope to promise less and offer more and not get sucked into this spiral of "overpromising and underdelivering" both in time and space that seems rampant in society around me.
Beyond the poverty, beyond the lack of intellect, this lack of a sense of responsibility is probably what will take India (and many companies, organisations and nations with a mindset likewise) to their graves.
Then came the task of watching and recording Television. I found three applications suitable to my needs, MythTV, tvtime and XawTV. Each come with specific features that are useful. The first two offer postprocessing, recording and Alpha blended OSDs. All three of them provide support for remote controls.
Despite the availability of these applications, I found that the use of non-standard frequency bands by the CATV operator made it difficult to scan for channels. Existing channel scanners from tvtime (tvtime-scanner) and Xawtv (scantv) supported scanning of the entire frequency range, however due to unresolved bugs did not render the scanned output useful. CATV operators multiplex digitally decoded channels into frequency bands convenient for transmission. However this differs from operator to operator and town to town making a simple patch of my favorite tv viewing applications infeasible at present. (I would require to modify them to read xml frequency tables, though tvtime does support this, there are bugs.)
This led me to try and write my own set of scripts to use "mplayer" as my tv player (having used it extensively for video playing prior) and a modified version of "scantv" for scanning frequencies. This took me at least 5 days, and now is available on public domain as tveasy. I must say, that this would not have been possible, without Open Source products, for I ripped off pieces of scantv for my own usage with ease. Having benefited so from "Free Software", I obviously had to give something back, and hence wrote a set of scripts for the same. I love "Free" Software.
I infer two critical points from this heading.
The buck doesn't stop here. Intel is attempting to go the multi-core (multi-microprocessor-per-core) way, but is stepping in rather cautiously without over-doing it. Traditionally, the multi-core trend seems to have evolved from the embedded SoC following. Network processor companies in their eagerness to exploit data/control plane parallelism this way, have made power hungry behemoths (rather toasters).
However, the problems faced here are dissimilar. Bus speed bottle-necks, Higher penalties per error [in both design & fabrication] and fundamental Operating System Software abstractions are a hindrance to go massive multi-core. The STI alliance's 'Cell' that was originally designed to be massively multi-core hasn't turned out so on the first shot. Clearly, Intel's caution in venturing here seems to have given them some time (to probably learn and avoid mistakes.) Even the 'Cell' seems geared on low power CPUs and higher power GPUs which seem to tell the same story. It finally seems (that until some major breakthrough comes up), processors aren't about to rev-up faster. I'm thinking, ain't it time ARM tried their hand on the desktop/laptop market? (with their great track record on power-saving.)
What is to be noticed is that revving down the clocks is something AMD has done already. Dynamic processor clocking (Speedstep for Intel) is also following AMD who could synchronous clock their CPUs without stepping between specific frequencies like the Intel counterparts. The only catch here is that AMD is yet to come up with the power friendly chip. So, can they pull out a rabbit out of the hat?
I believe that this is only a start to a major energy crisis we are all about to face. Attempts at Nuclear Fusion Reactors (though due only in 2016) are on, and alternate sources of energy are vigorously being explored. The world's economy has been anchored on Petro Dollar recycling that we hardly notice its effects. However, with oil production reaching critical levels, this system could have adverse effects on the international macro-economic system.
Roughly put, the economy of many countries who are not self-sufficient in oil production during the fall, will suffer. This would include countries gunning for near 10% growth (think China, India?, the developing world.) Consequentially, the consumer economy that has been driving growth in these developing countries would reach a stand-still.
The production of oil might take another two(2) years to start dropping (the prices during this drop will fluctuate as predicted by markets, with a possible low within this year.) The energy crisis (as any crisis - be it war, famine or natural disaster) presents an opportunity to Techpreneurs. The reason being, the environmental variables are poised for change and opportunity with adaptability will present itself (despite the scale of difficulties that will exist.)
It will also be interesting to observe strategies adopted by various countries to outlast the crisis and move to multiple alternatives. (The bitter lesson has been that we have relied too much on a single source - fossil fuels for energy.) Standard crisis procedures including rationing, socialistic government control of key industries may be a common backdrop.
Any business player who seems to gain a significant market advantage tends to use that advantage (fair or foul) to retain the market. This seems to work as simple as the owner of high ground would rather hold it (in the military sense) no matter what their strengths (numbers, technology or warrant.) I was hoping to see Intel (who labeled themselves 'The Paranoid') brought to trial for antitrust as soon as Microsoft was pulled up. The Wintel alliance, being the one which gave them the high ground in the first place (despite all chance that caused it.)
Reading "Inside Intel" by Tim Jackson, I learnt that AMD were just 9 months behind Intel with a similar business model. The big break into the global market, becoming the "chosen ones" by IBM (like Microsoft.) In the 48 pager (27-Jun-2005) from AMD, you read the usual story: "coercion" on OEMs, retailers, Hardware vendors to retain their higher MDFs and "threats" to refuse to supply on cooperation with the competitor.
Well, this ultimately DENIES the consumer of having 'reasonable' choice and the ability to choose a better performing product. I resorted to a Pentium4HT desktop, coz I couldn't find enough motherboard choices to hold a nice AMD64 (most had been coerced to be 'Intel compatible.')
Thinking of it, Socialism/Communism where the Government runs companies that have all market share and become monopolies operate similarly. They have no need to provide customer service on demand as there's no one else. Capitalism was supposed to provide a competitive environment where the consumer profited by choice, competition and assured growth. Monopolies violating this spirit inside a capitalist world are merely appeasing communism and are against the very spirit that created them.
Being a techie, I notice that Intel's compiler (which comes from an acquired company, Kai?) refuses to perform optimally on non-Intel, yet equally compatible hardware. That is surely taking it too far. I am hoping the gcc gurus (who helped amd64 get an Opensource OS first off), give them a helping hand and get better performance than Intel's (pay for use) compiler that doesn't do it's "promised" work on compatible hardware.
I've earlier jotted down in my journal that Bernie Ecclestone evened the odds for Formula 1 Racing to avoid making it look like a parade. This USGP, he might have failed to do just that.
The Michelin runners had safety problems with their tyres (evident only after practice) and by rules could not change their tyres. (Forget the fact that you can't change your engine or drivers or chassis once the race weekend begins.)
They wanted the stewards to modify the race circuit, so Fourteen(14) [a majority of them] using a specific company's tyre, could race or change the rules so they change their tyres.
The stewards asked the michelin runners to run chicane 13 slow (where cement joins tar) to avoid tyre problems. But 'Michelin' strongly advised all fourteen teams against this to muscle the F1A to change the rules for them. The F1A didn't budge; (and expecting Bernie to budge was waiting for it to rain dogs.)
The Michelin runners (on safety advise) refused to take the race. They could have changed tires and started from the back of the grid and charged at their opponents. Not so. They retired from the race after lap one creating the first F1Asco of the worst proportions of sportsmanship. Whining babies and Temper tantrums. The Bridgestone runners Six(6) of them finished the race, with nobody to race with actually, Ferrari being the most superior.
Now this just points out that everyone using one kind of tyre (like they used bridgestone some time ago) was recipe for disaster and is still. Now blaming FIA or the other Six(6) who ran
Technical Issues: Michelin has always relied on higher track temperatures. There are going to be situations when one portion of the track is going to be colder than the rest of it (like here in Indy where it was because of a different surface causing further problem.) If Michelin can't think of a solution with their existing compound and tyres, Let the French go back to their biking tyres and stop whining.
And point to note: The Ralf Schumacher accident (Ralf running into walls or gravel is not too uncommon in his racing career) occurs on "Friday Morning". Michelin's Analysis is complete on "Sunday Morning" 0630 hrs. Now, how the hell is the FIA supposed to respond after Michelin has outqualified its Bridgestone opponents on Saturday - let them fly? Maybe Michelin should be banned for the next two races (for further fun and frolicking.)
I've noticed several design suggestions in your code.