One day, I saw Suxen drol create a new page on the MultimediaWiki discussing something called the Peak codec. I was about to scold him for not uploading and linking to samples for this codec until I read closer. The Peak codec seems to refer to a theoretical best possible codec. Could such a beast really exist?
Based on everything I’ve read, perhaps On2’s VP8 is the Peak codec of lore: All things to all people.
This past week, the internet picked up — and subsequently sprinted like a cheetah with — an unsourced and highly unsubstantiated rumor that Google will open source the VP8 video codec, recently procured through their On2 acquisition. I wager that the FSF is already working on their press release claiming full credit should this actually come to pass. I still retain my “I’ll believe it when I see it” attitude. However, I thought this would be a good opportunity to consolidate all of the public knowledge regarding On2’s VP8 codec.
The Official VP8 Facts:
Continue reading
So I’m sitting in the tracing discussion at this year’s Linux Foundation Collaboration Summit. One presenter discussed a tracing facility called utrace. This got me thinking of all the different _trace utilities I could name off the top of my head: dtrace, ptrace, strace, and utrace. Then I wondered how many letters of the English alphabet already serve as prefixes to the word ‘trace’ as software utilities. My cursory research indicates 21/26 24/26.
Oh yeah, I looked them all up (and thanks to all who helped me fill in the blanks):
So, if you must make a new tracing utility, atrace, etrace, rtrace, ytrace, and ztrace all seem to be open.
Thanks for sitting through another of my pointless surveys. Oh, and thanks also to Google for providing Summit attendees with free, unlocked Nexus One phones. I haven’t seen many other mentions of this. Maybe Google does this so often that it barely counts as news anymore.
For 2 years, I’ve been wrangling with the overall architecture of the FATE system. Right now, there’s a primary fate-script.py program that manages building and testing on FATE installations that is sorely in need of many upgrades. Then there is fate-client.py which is a somewhat lighter-weight testing program. I have long wanted to merge the 2 scripts but could never settle on how to do it. At the base level, should the script assume that it’s operating in continuous build/test mode (a la fate-script.py) or single-shot test mode (a la fate-client.py) by default? Or neither? Should it force the user to specify a mess of command line options?
I had an epiphany recently while reading the documentation for Python’s standard (as of v2.3) optparse module, specifically the section entitled “What are options for?”
Options are used to provide extra information to tune or customize the execution of a program. In case it wasn’t clear, options are usually optional. A program should be able to run just fine with no options whatsoever… Lots of people want their programs to have ‘required options’. Think about it. If it’s required, then it’s not optional!
This led me to consider the possibility of a FATE script that could do something without any options and then build from there.
Default Operation Continue reading