René Rebe

So Microsoft finally got some TV advertisements out of the door that does not suck completely.

However, I like to add: you get what you pay for. Of course a Ferrari is no Mercedes is no Tata Nano (Indian) car. One usually get what one is paying for. And in case of this el-cheapo PC’s it’s a irregularly shaped plastic case, full of least cost hardware, with usually some design glitches (such as at least noisy audio output, up to a just-VGA external video output to the worst case: system bus noise or overheating problems causing medium to long term system stability issues). And you still pay the Microsoft Windows OS software tax, anyway.

On the other hand I even brought PowerPC based Apple computer back in the days, not even to run Mac OS - no, I just required reliable hardware, with superb battery life for my Linux needs. Back in the days the Mac OS (9 and early OS X) discs went into the trash immediately. But bug free, solidly built hardware with suspending to RAM capabilities and up to 5 hours battery life even under Linux was just outstanding back in the days.

And this technical matters aside, I really wonder if another price race to the bottom is in Microsoft’s (and the remaining “PC”/IT industries) interest after the NetB..k and NetTop inflation, …

Today Aaron Plattner from NVidia stated on the X.org mailing list when asked:

if there will be XVideo support for G90 cards to the nvidia free 2D driver

just:

XV on those GPUs requires the 3D engine, and setting that up is too complicated to be within the scope of that driver.

This let me to make some harsh notes what is “in the scope” of a driver and what’s not. Whether the closed source NVidia driver for U*ix-like systems is a favorable way to support (this) class of operating systems, or whether it has problems.

For me the Intel and ATi driver (or for that matter even the superb Matrox driver 10 years ago) always worked well. Of course the latest greatest drivers might have uncovered some compositing performance (or the like) regressions. But that’s the fast lane of the open source way of life. However, at least the availability of source allows to choose a suitable, working one, and also to fix such issues as they appear and invent in this area.

The quality is influenced by many factors, for me the source availability is one of the most important ones - without it many other factors (such as security among others) are hard to determine anyway. And on another side the NVidia driver rarely worked at all. Mostly because due to the sheer lack of x86 hardware on my side in the past (I stuck to PowerPC and SPARC for multiple reasons), and for the few AMD/Intel boxes other ABI incompatibility with the latest X.org server and/or OS kernel on the other side often came in between.

For me this boils down to a near zero usability of the binary-only nvidia drivers.

Let’s compare the GPU situation with classic CPUs:

If the vendors in the CPU-land would act like some of the vendors in the GPU-world still behave today, we would still not now how to enable the i386 protected mode, nor how-to use vector instructions or other new features of modern CPUs. If all programming material for CPUs would be hidden by the manufacturers, we also would only have very few operating systems, like Windows and Mac OS X, for example. Nothing like Linux or the BSDs - simply because few would know how to utilize the real power. And all programs would be limited to just utilitze what the vendor devices to expose to some form of driver API. Like the PC BIOS. Oh yeah - the VGA / VEAS BIOS. What a lovely dream.

It is no wonder GPGPU did not yet really take off and is not in wider use today: When utilizing it means calling into a VESA BIOS sort-of-thing and no-one knows what’s going on behind, how to debug or if it works tomorrow or the next computer nearby. And when innovators in operating system design have no access to proper register level documentation.

Just my 2 € cents on the matter, any why I’ll continue to strictly purchase only, what has open specs available. For drivers I can write, debug, review and improve. For hardware I can utilize in my OS and tomorrow, even when the vendor wants to phase it out.

Today I catched some neat exception / assertion trace of an [NSString drawAtPoint: withAttributes:] while drawing with an invalid context. So this is is the calling sequence how Mac OS X 10.5(.6) draws an NSString internally:

CGContextSetFillColorWithColor
CGContextSetStrokeColorWithColor
CGContextSetTextMatrix
CGContextSetFont
CGContextSetFontSize
CGContextGetShouldSmoothFonts
CGContextSetFontRenderingStyle
CGContextSetTextPosition
CGContextShowGlyphsWithAdvances
CGContextSetTextPosition
CGContextShowGlyphsWithAdvances

Well, yesterday night I finally updated my 3G iPhone to the 2.2.1 firmware - mostly because I have bug reports pending over at Apple, where some are said to be fixed in the latest 2.2.1 FW update.

So after the usually too lengthy backup, update and restore cycle (why can’t they just send delta updates over-the-air as they do for regular, real Macs?) I was left with my iPhone not wanting to lock on a provider in Germany, and no - I’m not running it unlocked or jail-broken but with the regular T-Mobile contract here in Germany (sigh!).

Anyway, as the “reset network preferences” and googling was not of help I decided to restore without replaying the backup, and voila: it worked, locked to the all expensive T-Mobile cellular network again. Though this left me with all of my preferences and particularly my not yet downloaded photos missing. Thanks god others already created some nifty iPhone backup decoder!

Update: Now with PCX support!

As three people already left comments in my earlier note that I was working on some ExactImage based Quick Look plug-in for Mac OS X, Leopard, I finally took the time to clean it up and get it out. And as I had some initial testers for the 1.0 version I already got an 1.1 update with some PNM compatibility fixed.

To install it, just move the QuickLookEI.qlgenerator bundle into either /Library/QuickLook/ or into your users’s home folder: /Users/…/Library/QuickLook/ - just as you prefer.

Oh, and before I forget: If you have another image format you like to preview on the Mac just let me know and I’ll see how quickly I can add support for it!

ExactImage had digital still camera RAW loading (aka decoding) support for over 2 years now, already.

While “RAW” images differ from manufacturer to manufacturer, from model to model and sometimes are even obfuscated by the vendor to prevent loading and creating solutions by third parties, ExactImage supported a wide range of RAW formats thanks to the embedded dcraw copy. Copy, because the orignal project is only available as a command line program and not in form of a library - and ExactImage needs to have some more control about how the image data is passed around, e.g. coming in from a database, network or are just keapt in memory and not to be processed fragilily thru sub-processes and pipes. We wrapped the plain ANSI dcraw C code with some macros to transform the ordinary C FILE* access to C++ std::iostreams and get rid of it’s main() function and call into the code from our library flow of execution. So we also had to update our support glue in order to update the aging dcraw copy.

But aside vastly increasing the number of supported models, we also added support code to allow extracting thumbnails via the ExactImage library and thus allow creating an overview / gallery of a bunch of RAW images in just the time you need to snip your fingers:

econvert –decompress thumb -i dcraw:img_0123.cr2 …

If batch image processing is something you where looking for or already performing maybe just give it a try, some distributions are alreaady including it and apparently it’s also on the way into Debian.

Of course the functinoality is not only available thru the command line frontend “econvert”, but also thru the external library interface, also wrapped by SWIG to Lua, Perl, PHP, Python, etc.

ExactImage 0.6 now comes with an revamped PDF writer and hocr2pdf front-end. Together with a patch to cuneiform to annotate each recognized glyph with a hOCR-like bounding box, it allows the creation of pretty exactly positioned, searchable PDF files with open source software!
Basically hocr2pdf accepts the input from STDIN (we could also add a -h/–html option to read it from a file) and the image from the filename passed with -i/–input. The resulting PDF filename is specified with -o/–output.

Additionally -s/–sloppy-text allows grouping of words on a line for sometimes improved search and cut’n paste results with older PDF viewers. The -n/–no-image option allows to skip the image - normally shadowing the text - to either save storage space or take a look how exactly the glyphs are positioned. Basically the short introductionary usage boils down to:

cuneiform -f hocr -o test.hocrl ocr-test.tif
hocr2pdf -i ocr-test.tif -o test.pdf < test.hoc

And the searchable PDF is there. The cuneiform hocr patch is now in the Launchpad’s cuneiform Bazaar HEAD/TIP.

It’s also already in use on the Archivista Box - a complete and open source long term archiving solution.

On days like this, I wonder what the heck the authors think - changing their software again and again in incompatible ways. Case in point this time: u/dev (or just udev, as you like).

If it would just be some random tool, tiny utility or whatever, I could not care less, but with tightly coupled pieces, wired into the system boot, low-level device management and the Linux kernel in many ways, I really have my problems with breaking existing installations due incompatible changes.
In the past, already, they renamed the system init programs, such as udevstart to udevtrigger as well as the format and keywords of the configuration files (rules) changed multiple times.

And now, with hundreds of thousand deployed Linux systems in the wild, someone decides “well, we do not like this multiple single tools anymore” and refactored the code to some combined “udevadm” in udev-121.

And we (the people using Linux, the “Linux” vendors, system integrators, and other individual users) can go update the init and system start-up scripts just for the fun of it.

Oh my.

Sure, one can argue the vendor should care and just get it right. But still: Multiple vendors now have to adapt multiple distributions (and embedded systems) and probably many many users will run into problems during updates of single packages to a new major release of their distribution of choice.

A +1 vote from me for less incompatible, random changes. Would saves coders and system admins a great deal of time.

Though I’m using Qemu for some time, now - I recently installed an old T2 flavour from 2 CD’s and thus had to exchange Qemu’s cdrom image at run-time. It came to my suprise that some random googling brought up mostly stuff that did not work anymore - maybe because I have to use a Qemu SVN version due a newer GCC (4.x).

change cdrom
device not found

With “info block” in the Qemu monitor (Ctrl-Alt-2) one cane get a list of currently attached block devices:

info block
ide0-cd1: type=cdrom removeable=1 locked=1 file=/home/rene/…
ide0-hd0: type=hd removable=0 file=/home/rene/…

…

So for exchange the attached cdrom at run-time the commands are:

eject ide0-cd1
change ide0-cd1 /home/rene/some-other-file…

And finally the switch back from the monitor to the VGA output screen with Ctrl-Alt-0.

Up until recently no sophisticated barcode recognition was available as open source. There where some attempts to handle barcodes among an otherwise character recognizing project, as well as a “just code39″ recognition tool. ExactCODE now made a whole family of barcode recognizers for all common 1D codes (UPC, EAN, CODE25, CODE39, CODE128 to name a few) available within the modern, C++ imaging framework ExactImage under the terms of the GPL.

For commercial licensing options, for distributions in classic binary-only applications as well as more advanced features and 2D recognition, just contact us.

We’re looking forward to hearing from you!