I journeyed to the bookstore today in search of an O’Reilly pocket-sized Python reference, in an effort to tip the balance toward the positive in my newfound love/hate relationship with the Python programming language. I found what I was after, and on prominent display. I had not perused the computer book aisle in quite some time so I took a moment to look around. Every current and trendy computer language and development fad was well-represented, including a few of which I was previously unaware. That’s when it dawned on me how hard it is to find a simple book on the C programming language in these sections.
Maybe C just isn’t good for selling books.
This episode reminded me of the difference I observed long ago about the differences in computer book selections at bookstores vs. academic libraries vs. public libraries. A bookstore will stock thick, vastly expensive tomes covering whatever the latest hot computing fad or language happens to be (wait for the fad to blow over and in 6 months the book will be less than $10 on the clearance table). Rewind 10 years to 1996 when Java was taking off in a big way. I think the local Barnes & Noble shop had an entire section devoted to the language. And I seem to remember that every one of the books was essentially the same: A few chapters discussing the basics of the language, with the remaining 4/5 of the book devoted to a verbatim reprint of the official Java language and API reference that was freely available online.
An academic library, such as the one found at your local technical university, will stock a few of the fad books about specialized skills but will feature far more texts on fundamental and advanced computer science theory (think “general theory of fishing” vs. “learn bass fishing in 3 days!”). A community public library, in my experience, will have a decent mix of both types of books.
I finally got something semi-useful accomplished on the Hachoir project: A RealMedia (.rm) file parser. Here is a screenshot of the hachoir-urwid frontend (one of several frontends available for the project):
I have long held an interest in thoroughly and usefully documenting the rm format which has always struck me as one of the most ad-hoc multimedia formats available, at least in terms of the support available in open source programs. I was eager to write this parser to help me study the format and write down all of the things that are present in various open source demuxers but are currently missing from any public documentation (that I am aware of). The parser I have written so far is the easy stuff; I want to move on to documenting that type-specific data field highlighted in the screenshot, which is the really interesting and useful part of the format.
But hey, if you would like to help, the code is now in the Hachoir Subversion repository.
So the Free Software Foundation has launched badvista.org, ostensibly a clearinghouse for informing computer consumers just how harmful Microsoft’s impending Windows Vista is for their digital and online health. To be honest, I haven’t really examined the literature too thoroughly, mostly because I just don’t personally care about Vista (“Yadda yadda, Microsoft bad, proprietary software implicitly wrong and evil, ad nauseum”). Though it did finally get me to thinking about the multimedia-related implications of the new OS upgrade. Per my reading, there will be no new actual multimedia container formats, video codecs, or audio codecs. But there are supposed to be layers upon layers of new DRM and associated rules encapsulating the existing formats and determining where/when/how a user can consume a particular piece of media.
Strange, but with my experiences using Linux over the last year, and particularly in the last week, I could set up a similar site about various shortcomings of Linux (as if that hasn’t been done to death already). But I notice that badlinux.org does not appear to be taken as of this writing.
Sometimes, while using the the Xv hardware YUV interface with xine, the program briefly displays the ghost of some other image momentarily as it creates a new video window. Typically, the ghost depicts images that were recently shown in my Firefox web browser. So memory isn’t zeroed out somewhere along the line. That all makes sense.
What puzzles me is something I saw last week: I was working in Linux, rebooted into Windows and worked for a little while, then rebooted back into Linux. When I started xine, I saw an image that I had previously brought up in my web browser before I had rebooted into Windows. That image had staying power.
I realized that, though all of this, I had never actually cut power to the machine, only did warm reboots. Thus, I suspect the data was left over in an area of video RAM that Windows never had occasion to touch.