Author Archives: Multimedia Mike

Alphabet of Tracing

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):

  • atrace: astrange’s raytracer
  • btrace: Tracing for Java
  • ctrace: multi-threaded trace/debug library
  • dtrace: Sun’s comprehensive framework
  • etrace: The Embedded ELF tracer
  • ftrace: Fast traceroute for Win32; also ftrace: function tracer
  • gtrace: Graphical front-end to traceroute
  • htrace: apparently an extension to windbg
  • itrace: not Apple-related (see ktrace); this stands for instruction strace
  • jtrace: Java rewrite of a speech recognition technique called TRACE
  • ktrace: Kernel tracing for certain BSDs including Mac OS X
  • ltrace: Linux utility to monitor library calls
  • mtrace: Memory debugger in the GNU C library
  • ntrace: Tracing for .NET applications
  • otrace: Oracle database tracing
  • ptrace: Process tracing in Linux
  • qtrace: Another traceroute utility
  • rtrace: Ruby-Trace almost qualifies
  • strace: Tracing system calls
  • ttrace: Tracing facility for multithreaded processes
  • utrace: Linux tracing
  • vtrace: System-wide profiling of WinNT or Win2K
  • wtrace: Provides information to debug methods (pertains to Tivoli?)
  • xtrace: Tracing for X servers
  • ytrace: Nothing
  • ztrace: Win32 tracing utility

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.

FATE Building Blocks

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 →

Google Funding VP3 On ARM

Some news is making the rounds that Google is funding ARM improvements for the Theora video decoder. It gives the free software faithful renewed hope. However, reading this news makes me wonder: Doesn’t FFmpeg already have ARM optimizations for Theora? In fact, it does, as indicated by the existence of the file libavcodec/arm/vp3dsp_neon.S. This has optimized IDCT transform/get/put and loop filter functions for NEON instruction sets. I know there are several different types of SIMD for ARM chips and I don’t know if NEON is the most common variety.

The most pressing reason for funding this effort is, of course, license purity.

Intentional Time-Consuming Work

A woman sat down across from me on the train, pulled out her knitting needles and went to work on what appeared to be a scarf. I briefly pondered the fact that she chose to busy herself with constructing a scarf the hard way when it’s obviously faster and cheaper to buy a scarf off the shelf.



Then I immediately pondered how many of my personal programming projects fall into this same category of wheels that don’t need to be reinvented. There are still plenty of projects I want to take on that would surely serve no practical purpose in the grand scheme of things, particularly when evaluated against what I could be spending my time on.

Video game console programming springs immediately to mind. I was interested in Sega Dreamcast programming long after the system had become obsolete. For that matter, I’m still interested in Sony PlayStation 3 programming, even though that community is about to be driven underground. I have long been interested in the technical aspects of the 8-bit Nintendo Entertainment System (NES) and have always wanted to write software for that console as well. A few years ago, I even purchased RetroUSB’s PowerPak, a CompactFlash-based game cartridge, probably the easiest method for testing code on an actual system. Mercifully, I recently gave away that item (and the console, an SNES-style top loader), so that’s one less area on which I can waste my spare dev time. I still have the DC and the PS3, though.

My FFmpeg colleagues should be pleased to hear that I do try to make my FATE work a priority above these arguably more frivolous pursuits.