In exactly two months it’ll be one year since the new xine tracker was put up and made operative. This means that the domain, which I registered as a test, is going to expire and I’ll have to renew it first.

Because I have some availability right now and it should make quite sense to do it this way, I decided to make it a five years renewal; it’s a long time but xine should well outlast it, and I think it’s easier to do it once rather than doing it every year with the risk I might be in the hospital and let the renewal time lapse.

Just so that everything is transparent, the renewal will cost around $75, which is about ?50, which will come from the Yamato fund, so thank you to everybody who contributed.

Hopefully in the next future xine-project.org might host more than just the bugtracker, in line with Mike’s FATE testing for FFmpeg, once I’ll have written unit tests for xine and maybe even more complex tests, like making sure the metadata of a file are properly read, and so on to make sure video and audio play in a decent way (it’s going to be difficult as here we might not have exact conversions like FATE does).

I haven’t lost my faith in xine, I think we can do great, we just need to find enough people to help with it though, because alone is not going to work very well.

If you have seen my repositories lately, you’d probably have noticed that I started working more on third-party projects, in particular you can see repositories for libxdg-basedir (which I’ve been using already for a while for xine-lib) and libxr (which is new, recently added to portage by Luca), together with those you can find a bunch of repositories from lscube and some from Lennart .

The reason for this is that I started considering taking a more active stance when I need something fixed, in particular, I’m just making my changes and then sending upstream the repositories, hoping they get merged quickly. This is the nice thing about having repositories available with GIT and all the like. Unfortunately a lot of projects are still managed with Subversion or, even worse, CVS, or other DVCS which I don’t have set up on midas (yet).

At any rate, one of the changes that is tied with all these project is probably the introduction of the -uninstalled variant of pkg-config files. Simon McVittie writes more about it than I could probably write myself.

There are a few interesting notes about this though. The first is that -uninstalled variants of pkg-config files gets often in the way of libtool; for instance you’d have to point them to the .libs/ directory used internally by libtool, or you’d be able to link against them just with libtool (as they’d point to the .la file). The other problem is that, if you’re building with libtool, it will properly set the rpath/runpath to make sure that the resulting binary is executed against the uninstalled version, but this does not happen, by default, outside of libtool. I’m still pondering whether I should change the -uninstalled.pc files to set the runpath by themselves. Unfortunately it would then work only with ld compatible with GNU syntax.

The nice part of building against non-installed libraries is that it makes it much easier to run a series of tests on the project, which is very nice once you set up unit tests .

Now if only I can solve the unit testing problem, I could be focusing on working on unit testing and possibly to extend unit testing coverage in as many software as possible, which I use, so that I don’t have to worry about broken behaviour. But this is work for another day, right now I have enough to do, I should be writing docs and articles, and converting to Glib and writing tests.

And I just came out of the hospital! I hope the games I ordered from Amazon will arrive soon so I can at least relax a bit during the weekends.

For a series of reason, I’m interested in writing unit tests for a few project, one of which will probably be my 1.3 branch of xine-lib (Yes I know 1.2 hasn’t been released yet in beta form either).

While unit tests can be written quite easily without much framework, having at least a basic framework would help to make automated testing possible. Since the project I have to deal with use standard C, I started looking at some basic unit test frameworks.

Unfortunately, it seems like both CUnit and check have last seen a release in 2006, and their respective repositories seem quite calm. In case of CUnit I also have noticed a quite broken buildsystem.

Glib seems to have some basic support for test units, but even they don’t use it so I doubt it’d be a nice choice. There are quite a few unit testing frameworks for particular environments, like Qt or Gnome, but I haven’t found anything generic.

It seems funky that even if people always seems to cheer test-driven development there isn’t a good enough framework for C. I think Ruby, Java, Perl and Python have already their well established frameworks, and most of the software use that, but there is neither a standard nor a widely accepted framework for C.

I could probably write my own framework but that’s not really an option, I don’t have so much free time to my hands, I suppose the less effort would be to contribute to one of the frameworks already out there, so that I can fix whatever I need fixed and have it working as I need. Unfortunately, I’d have to start looking at all of them and find the less problematic before I start doing this, and it is not useful if the original authors have gone MIA or similar, especially since at least CUnit was still developed using CVS.

If somebody have suggestions on how to proceed, they are most welcome. I could probably fork one of them if I have to, although I dislike the idea. Out of what I gathered quite briefly, the presence of XML generation for results in CUnit might be useful to gather up tests’ statistics for an automatic testing facility.

In the past few days I’ve been working to port part of lscube to Glib. The idea is that instead of inventing lists, ways to iterate over them, to find data and so on so forth, using Glib versions should be much easier and also faster as they tend to be optimised.

Interestingly enough, glib does seem to provide almost every feature out there, although I still think the logging facilities lack something.

It is very interesting to finally being able to ditch custom-made data structures for things that were tested already before. Unfortunately, rewriting big parts of the code is, as usual, vulnerable to human mistakes. But it’s fun.

I start to wonder how much duplication of efforts we have in a system, I’m pretty sure there is some at least. xine-lib for instance does not use Glib, and it then re-implements some structures and abstractions that could very well be used from Glib. I’m tempted, once I feel better and I can pay more attention to xine-lib again, to start a new branch and see how it would work to move xine-lib to Glib. Considering that even Qt4 now brings that in, I guess most of the frontends would be already using Glib, so it makes sense.

Actually some of the plugins of xine itself make use of Glib, so it would probably be a good idea to at least try to reduce the duplication by using Glib there too. Things like Glib’s GString would make reply generation for HTTP, RTP/RTSP and MMS quite easier than the current methods, and probably much safer. I would even expect it to be faster but I won’t swear on that just yet.

So this is one more TODO for xine-lib, at this point I guess 1.3 series; it would also be nice to start using Ragel for demuxers and protocol parsers.

I guess I should be playing by now rather than writing blogs about technical stuff or rewriting code to use Glib or ragel, sigh.

I know I’m still convalescing so I should be resting, not thinking about development problems, but this is something that ended up in my mind because I have one thing to absolutely do (scan the release documents from the hospital to send to my GP), and for which I miss an easy interface I could instruct my mother, or my sister, to use.

Don’t get me wrong, I know there are a few SANE frontends, starting from xsane itself, but the problem is that I don’t usually stop at scanimage when I do it from the console. What I usually do is to launch a batch scan to TIFF format, then use tiffcp to join the different TIFF files in a single file with multiple pages, and then use tiff2pdf to convert it to a PDF file, which is opened by any computer I might need to send the data to (and it also is quite smaller than the original TIFF file). Lately, I’ve started trying to add to the chain also unpaper, a tool that removes some of the defects usually found in scanning pages from books (like black borders and similar), which works on PNM (thus requiring a change in the scanning command, and a further conversion later on).

But I don’t want to start fleshing down how to actually write such a tool, or I might actually start writing it right now, which is not what I’m supposed to do while I’m convalescing.

What I want to think about is that here comes one huge debate between writing frontends for command-line tools, which just interfaces with them as process calling, or writing a full-fledged program that interfaces with the low-level libraries to provide similar functionalities.

I already happen to discuss that quite often since xine and mplayer embody the two spirits: xine has its library, frontends interface with that, and a single process is used; mplayer instead has a command interface, and frontends execute a new process for playing videos.

There are of course advantages and disadvantages, one easy to spot disadvantage to xine’s approach is that a crash or freeze in xine results in a crash or freeze of the frontend, which is something Amarok users have been unfortunately familiar with.

In the case of the scanning toolchain, though, I guess it’d be probably easier to use a frontend for the tools, as re-implementing all the different functionalities would be a non-trivial work.

The disadvantages of doing it this way, though, is that you’ll have to make sure that the tools don’t change their parameters between versions, otherwise it’d be a problem to ensure the correct functionality of the tool. Also, the tools need to provide enough options to control with granularity the execution of their task, which is something unpaper actually does, but in turn makes them almost unusable for final users.

I know I’m not going much anywhere with this post, I’m afraid, but I just wanted to reflect on the fact that to have a command line tool designed to be used by frontends, you almost certainly make its syntax so complex that users would fail to grasp the basic concepts, and in turn, you’d need a command line interface to the tool too… which is why there are so many scripts interfacing to ffmpeg for converting videos, I guess.

On the other hand, one can easily write such a frontend using scripting languages, even if it’s graphical, such as with ruby-gtk2 (think RubyRipper).

One regression I have with Yamato is that the BIOS cannot be updated through the BIOS itself, like I could do with my previous ASUS motherboard (and Award BIOS). The AMI bios of the Tyan motherboard doesn’t support that.

But since I don’t want to use my Windows installation to do the job (I use it only for work and to play more recent games that don’t play in Wine), I decided to look up something that could allow me to do the upgrade using only Free Software, my Gentoo Linux install, and the files provided by Tyan.

Caution: I make no warranty that the procedure will work properly, if this post gets published it means I was able to get it working myself but it might not work for you! Please remember that you do this at your risk!

I found an interesting post about FreeDOS and USB drives, which made my life much more easier. But as I’m using Linux and in particular Gentoo, I revised a bit the instructions :)

• first of all, merge the software we’re going to need, this means sys-boot/makebootfat (from my overlay) and app-arch/libarchive (to extract an ISO file later on);
• proceed then to create the directory where to put the files that will go on the virtual floppy, let’s call it “bios-update”;
• download the new BIOS from Tyan’s website, and put the content of the zip archive in “bios-update”;
• download FreeDOS (I suggest you to use the torrent download rather that ibiblio that is so slow!);
• extract the ISO, with bsdtar it’s just the same as extracting a standard tar file: xf and all;
• copy freedos/setup/odin/{command.com,kernel.sys} from the FreeDOS ISO to the “bios-update” directory;
• from freedos/packages/src_base/kernels.zip extract the files source/ukernel/boot/fat{12,16,32lba}.bin.
• run the makebootfat command with a commandline similar to this: makebootfat -o /dev/sde -E 255 -1 fat12.bin -2 fat16.bin -3 fat32lba.bin -m /usr/share/syslinux/mbr.bin bios-update; note that /dev/sde has to be changed to your USB device.

Now just restart your system with the USB drive in it and run the flash utility as provided by your manufacturer.

As an alternative you may rename an eventual batch file provided by your manufacturer to autoexec.bat so that it is ran at boot; I have no idea (yet) how to stop FreeDOS from asking date and time, but whatever, just press enter at them. You don’t usually have to worry about infinite loops of BIOS updates, as once the update is done, I’ve noticed all BIOS, after update, require you to fill in the configuration again.

I’m tempted to streamline this to a script or make the makebootfat ebuild fetch the needed files out of the FreeDOS ISO, or create an ebuild that install the basic FreeDOS files needed to create the boot disk. But maybe another time.

Some time ago I expressed my feelings about C# ; to sum them up, I think it’s a nice language, by itself. It’s near enough C to be understandable by most developers who ever worked with that or C++ and it’s much saner than C++ in my opinion.

But I haven’t said much about Mono, even though I’ve been running GNOME for a while now and of course I’ve been using F-spot and, as Tante suggested, gnome-do.

I’ve been thinking about writing something about this since he also posted about Mono, but I think today is the best day of all, as there has been some interesting news in Java land.

While I do see that Mono has improved hugely since I last tried it (for Beagle), I do still have some reserves against Mono/.NET when compared with Java.

The reason for this is not that I think Mono cannot improve or that Java is technically superior, it’s more that I’m glad Sun finally covered the Java crap. OpenJDK was a very good step further, as it opened most of the important parts of the source code for others. But it also became more interesting in the last few days.

First, Sun accepted the FreeBSD port of their JDK into OpenJDK (which is a very good thing for the Gentoo/FreeBSD project!), and then a Darwin port was merged in OpenJDK. Lovely, Sun is taking the right steps to come out of the crap!

In particular, the porters project is something I would have liked to get involved in, if it wasn’t for last year’s health disaster.

In general, I think Java has now much more chances to become the true high-level multiplatform language and environment, over C# and Mono. This because the main implementation is open, rather than having one (or more) open implementations trying to track down the first and main implementation.

But I’d be seriously interested on a C# compiler that didn’t need Mono runtime, kinda like Vala.

If you don’t know the AGPL-3, it’s the GNU Affero General Public License version 3 . The interesting difference between this license and the more common GPL-3 is that makes the user able to receive the sources of the software used to provide them with a networked service.

Now this is a quite interesting license, because it fills a “loophole” of the GPL: if you provide a service over Internet that makes use of a software released under the GPL, you’re not asked to provide the source for it, even if you modify it, as long as you’re not distributing the software itself.

This “loophole”, as it might be seen by some, was already being considered years ago on the NoX-Wizard project, an Ultima OnLine server emulator that, in addition to the standard GPL-2 license, added an extra restriction of making available the source code of an eventual modified copy that was used as a public server.

I’m sure for many people this is a restriction in freedom, instead of an improvement, as they are no more free to take advantage of Free Software without giving back anything as long as they are keeping the modified version on their own systems.

On the other hand, I think it’s an important edge the one that AGPL provides to users and developers. Beside allowing the code to be available to every user of the service, it also has some interesting side-effects that I’d like to put a bit of light upon.

The first is that it makes it much more important for the people modifying the application to get in touch with upstream to make their changes included in the original repository: it makes sense to be able to just point to the upstream repository rather than having to deal with a different repository per service.

Related to this, it makes it possible for the various upstreams to see what the users are modifying of their code, and make the needed changes in the original codebase so that they can improve the software for all its users.

But even more interesting, AGPL-3 allows a much more powerful approach to services’ security. With the source code available, any security expert can look at the code, and see if there are obvious vulnerabilities. The most basic example is SQL injections or XSS vulnerabilities that might be introduced in an otherwise completely safe codebase by someone touching the code to integrate it in a different setup, or to extend its functionalities.

Of course this last note is not entirely positive, as it also means that any person with a decent knowledge of the language used can find those vulnerabilities too, and it might be a security risk if that person does have malicious intents.

This would give a compltely new meaning and an intersting spin to “beta” release of services, and would introduce, for web services, a peer-review that might actually make web security much tighter; as it is now, it’s vastly a security-through-obscurity approach.

On the other hand, I sincerely doubt that any “big” of the web services would see to start releasing their code as AGPL-3. The reason for this is quite obvious: a lot of services are there, offered “for free”, but have privacy statements that clearly show their primary intent is to harvest information about you; you might not mind, as it might actually help you somehow (like Amazon’s reccomendations) but if you actually knew the extent to which they arrive to gather your information, it might actually discourage you from using their service.

At any rate, I think I finally made up my mind, and once I’ll be back working on my Free Software projects, I’ll finally relicense Gitarella as I was thinking of doing last year. I already licensed my rbot plugins under that license and it seems to be working fine.

Jeff, I think your concerns are pretty well real. The problem here though is not that Debian users should not be suggested not to file bugs upstream, the problem is that Debian should not go out of their way to patch stuff around.

Of course this is not entirely Debian’s fault, there are a few projects for which dealing with upstream is a tremendous waste of time of cosmic proportions, as they ignore distributors, think that their needs are totally bogus and stuff like that. Now, not all projects are like that of course. Projects like Amarok are quite friendly with downstream (to the point all the patches that are in Gentoo, added by me at least, were committed at the same time on the SVN), and most of the projects that you can find not suiting any distribution are most likely not knowing what the distributors need.

I did write about this in the past, and you can find my ideas on the “Distribution-friendly Projects” article, published on LWN (part 1, part 2 and part 3). I do suggest the read of that to anybody who has an upstream project, and would like to know what distributors need.

But the problem here is that Debian is known for patching the blood out of a project to adapt it to their needs. Sometimes this is good, as they take a totally distribution-unfriendly package into a decent one, sometimes it’s very bad.

You can find a few good uses of Debian’s patches in Portage, it’s not uncommon for a patched project to be used. On the other hand, you can think of at least two failures that, at least for me, shown the way Debian can easily fail:

• a not-so-commonly known failure in autotoolising metamail, a dependency of hylafax that I tried to run on FreeBSD before. They did use autoconf and automake, but they made them so that they only work under Linux, proving they don’t know autotools that well;
• the EPIC FAIL of the OpenSSL security bug; where people wanted to fix a problem with Valgrind, not knowing valgrind (if you have ever looked at valgrind docs, there is a good reference about suppression files, rather than patching code you don’t understand either).

Now this of course means nothing, of course even in Gentoo there has been good patches and bad patches; I have yet to see an EPIC FAIL like the OpenSSL debacle, but you never know.

The problem lies in the fact that Debian also seem to keep an “holier than thou” attitude toward any kind of collaboration, as you can easily notice in Marco d’Itri’s statements regarding udev rules (see this LWN article). I know a few Debian developers who are really nice guys whom I love to work with (like Reinhard Tartler who packages xine and Russel Coker whose blog I love to follow, for both technical posts and “green” posts; but not limited to), but for other Debian developers to behave like d’Itri is far from unheard of, and actually not uncommon either.

I’m afraid that the good in Debian is being contaminated by people like these, and by the attitude of trusting no one but themselves in every issue. And I’m sorry to see that because Debian was my distribution of choice when I started using Linux seriously.

If you remember my post from yesterday about xine license being violated, I was able to contact CnM through KMS support contact. They have been very friendly, and are taking the right steps to correct the situation, the answer yesterday came very quickly:

Hi Diego,

Thanks for bringing this to our attention, we will rectify this as soon as possible.

I am waiting for contact details from the manufacturer for anyone wishing to get hold of the source code, which will be via post or download from our site.

We will be adding this information to our web site as soon as possible and making sure that customers are aware of this when they purchase the product.

I will email back when this has been done to check that you are happy that we are complying fully with the GPL Licence.

Regards

Stephen Jones

And then again today, after a request if I could quote them on the blog:

Hi Diego,

Sorry for the late reply, but I wanted to have as much information as possible for you.

We have rectified the licensing information on our site, included an address to request a copy of the source code and will have the code available for download very soon.

The next batch of miniBooks will be shipping with an addition to the welcome letter which includes information about the GPL Licence and how to request a copy of the source code.

I think we have covered all the necessary parts of the GPL by doing this, but if there is anything else that you believe we may have missed please can you email me back with advice on it.

You can put the contents of this email and the previous one on your blog if you would like, it might paint us in a better light because some people have been saying that we were unwilling to comply with the GPL and have been obstructive when contacted. I would like to think this isn’t the case and we have tried to resolve this issue as quickly as possible.

This miniBook might not be the ideal platform for development because there are no applications on it to allow access to the underlying OS, but I know a few developers have already figured a way around this and it is probably a challenge to get it setup the way you want it to be.

Thanks for your pointing out this problem and your help with resolving the issue.

Regards

Stephen Jones

And as they said, the information is available on MiniBook site (in particular, you can see this page). It might not be perfect yet, and the source code is not yet available for download, but it’s the first step, and took less than two days, in August, to come to this point.

I guess CnM made a mistake in good faith, and they are interested in playing by the rules and fix it. It’s nice to see.

The same doesn’t seem to old true for someone else …

Up to a few weeks ago I didn’t own a webcam at all. I bought one, together with a set of headphones and mike, at the lowest price I could find in my local mall. I chosen to do that because the microphone integrated in my laptop isn’t the best quality, and I happen to speak through Skype from time to time, for work too.

The webcam is using a Microdia chip, and seems to be of the worse quality, but the headphones are nice, and they were worth alone the price I paid. The chip on that webcam is currently not supported by the gspca driver that you can find in Portage, but is supported by the development version, hopefully even in the one that has been merged in for 2.6.27.

It wasn’t easy to find it, but I could find the development repository of that version, and built the driver myself. I didn’t find a decent software to try it out. I wanted to try with Skype itself, but the ioctl translation for 32-bit compatibility didn’t work properly yet. Hopefully it will work in the future.

I still haven’t found a good SIP client for Linux though. Not like I’m much interested in that myself, as while I’m at home I have the cordless providing me with up to seven SIP accounts connectivity, and on the go I have the Nokia E61 (until I replace it), but itw ould be nice to be able to suggest a client to someone.

I started trying Empathy too, when I noticed it supports Google Talk’s Jingle extension to XMPP, but there are still a few rough points with XMPP support, maybe I should try to help out with them, if I have some free time.

Ekiga I don’t even want to try, I can understand LDAP integration, but mandatory LDAP integration sounds, to me, just plainly silly.

Maybe now that the kernel is getting a much better support for webcams there will be better support for it in userland, too?

It’s not like my main interest in the IT field is networking hardware. Actually, albeit I like taking care of it on smaller environment, I don’t know much about large scale networking, and I feel “n00b” every time I hear some fellow devs talking about their work in that area.

Unfortunately it seems like lately I need to take care of a few networking issues for myself. Since the kernel 2.6.26 was released I was unable to use madwifi (as I wrote about I admit I haven’t tested in the past weeks so it might be fixed now, I just didn’t have time/will to check again. In the mean time I’m using the ath5k driver, that seems to work but not as much as I’d need, so I cannot use iSCSI via wireless anymore, which sucks quite a bit when using the laptop.

There is then the problem with my router that created me a few problems. As I wrote, the table for mac address access control has only 32 entries. I thought it was just a limitation of the interface, but as it turns out, 3Com advertise all their routers as capable of supporting up to 32 clients. This mean that it’s quite unlikely that there’s a way to get around that limit in the table, and even less likely that the same class of routers would work for me.

At this point, I have to find a solution. The obvious one would be to use a Fonera to handle the Wireless connection; this way I could just leave wifi open and be done with it. The problem here is that I’d rather not use WPA2 (or, as someone also noted on my blog) the Nintendo DS won’t connect to WiFi, and that I’d like to have at least some sort of access control. An alternative would be to use a Linux-based access point. I do have the WRT54GL that I used to use when the office had not just Enterprise bug also Prakesh, Klothos and Farragut. The problem is that I’d have to update OpenWRT on it almost surely, and I have no clue how the support is nowadays.

The Linux support for Wireless networking in the past years has been quite in flux, but it started to become quite interesting in the past months. The b43 drivers that finally made possible to use at least a small subset of Broadcom wireless cards could probably allow OpenWRT to use a 2.6 kernel on the WRT54GL sooner or later, but I wonder how its access point mode support would be with that driver. For what I gathered, the ath5k is far from being an alterantive for the job.

Talking about wireless problems, it seems like there are problems even with identifying the correct region. Luckily the channel I’m using is available on all regions, so I’m fine for now. Hopefully, Atheros drivers improvements will follow soon, and ath5k will be able to work with iSCSI and all the rest, maybe even with AP mode so that Linux-based wireless routers would become much easier to manage. Of course the best would be if I could get one of them to run Gentoo directly.

See, the embedded part of the networking game is something I actually am interested about ;)

In the mean time I’m considering the option of resuming the WRT54GL with the same function it had before, and passing a shielded ethernet cable between my office and my bedroom, so I could get the PS3, the AppleTV and the laptop (while I’m there) to talk with enterprise through ethernet directly, and leaving the WRT54GL to connect them to the Wireless. It would probably also be healthier as it means less radio waves in general. The problem of this solution is that I’m not sure I have enough space in the cabling areas, and that I’d need two gigabit switches to make sure that the PlayStation3 and the laptop can communicate at the highest speed possible (I’d need one switch in the office, to join the “backbone” cable with Enterprise and the WRT54GL… the internal switch of the WRT is 10/100Mbit, so it would block Gigabit, and one in the bedroom to join PS3, AppleTV and the laptop).

It’s something I should consider, at any rate.

As I wrote, I’m improving autotools for some 0pointer projects. Among these there is of course PulseAudio (for which, for a while, I had access to the upstrem Subversion repository). The nice thing about git is that I can easily make a mess, take back a few commits, fix them, and when I’m sure it’s all fine I can push it through.

At any rate, what I want to write about today is the importance of caching the values. As I wrote before, there is a lot of anger toward autotools because running the ./configure script over and over is slow. This is true for a few very good reasons:

• lots of configure scripts check for things they don’t use; this is not always fault of who wrote it, because for instance using libtool caused checks for C++ and Fortran compilers to be emitted even if they are not used at all; this has been fixed in libtool 2.2 and is no more the case on modern packages;
• lots of configure scripts don’t cache their results, rebuilding the same software over and over can benefit from caching tests, especially the ones that involve linking; while confcache is broken by design, as different packages use the same cache value name with different meanings, the cache is very useful during development, applied to the same package;
• some packages require linking test to identify their dependencies, rather than relying on pkg-config, for instance, or the authors of the configure.ac scripts don’t rely on the pkg-config tool even when available; this is often the case for X11 stuff: modular Xorg supports pkg-config for discovery of packages and libraries, but very few configure scripts check that, partly because they were designed before modular Xorg, partly for compatibility with older versions and other vendors.

There are good solutions to tackle all these problems actually, the issue is that they are not widely known.

The first point can be solved by making sure that the configure phase checks for what is needed and just that. This is done by using new enough tools (newer libtool versions dropped checks for many things that are not required, like C++ and Fortran), and making sure that the content of the configure.ac file is not just boilerplate.

A common issue is checking for the presence of 20 different headers that are actually used in the project, and then never using the HAVE_FOOBAR_H macros, similarly for different system-dependent functions.

In a similar fashion, checking for functions and exiting with error if they are not present is not a huge improvement over failing at build time. Okay it might make it faster to notice if the software will not build, but it’s not much of an improvement. Functions and headers check are usually better when you have an alternative. Similarly, if you want to find which header to include for standard integers like uint8_t, between stdint.h, inttypes.h and sys/types.h, knowing some systems have more than one of those, and the priority order is this, it’s better to stop at the first one found, using a construct like:

AC_CHECK_HEADERS([stdint.h inttypes.h sys/types.h], [break;])

so if the system supports C99’s stdint.h, the other two are not tested for at all. Something similar happens for strcasecmp:

AC_CHECK_FUNCS([strcasecmp stricmp], [break;])

will stop at the first working alternative.

For what concerns the caching, one of the best things you can do is making sure that the tests are factored out on their own macros, so that you can easily reuse them between projets. If there was a better understanding of this need, confcache could have worked. Unfortunately it’s near to impossible to handle this correctly right now.

Once they are on their own macros, use AC_CACHE_CHECK rather than doing AC_MSG_CHECKING and AC_MSG_RESULT manually, this way the result will be saved in the cache file, making it available to further configure executions.

The third problem is quite tricky, as it depends on vairous needs of projects. In general, it’s possible to use pkg-config to find something and fallback to a build test if it fails; this is what xine-lib does already to discover X libraries: on a modern system using modular Xorg, the configure takes much less time because it uses pkg-config discovery. If KDE did that to discover Qt dependencies and other things, it would probably have taken quite less time.

There’s also the problem that, to be “consistent”, KDE uses the same build system both for complicated software making use of extended features, and simple data files like icons or similar. The same seems to apply now as cmake is used for everything. The nice thing about autotools is that you can slim them down when you don’t need a huge lot of features, for instance if you look at GNOME’s icon themes, they don’t start checking for gtk+ features that are enabled or not, while KDE’s icon themes using the KDE build system will do that anyway. Now of course this makes it much easier to integrate the icon themes together with the rest of the code, but it would be quite nicer if the icon theme was either available standalone, or if it was possible to install it bypassing most of the complexity of the build system with a simple script.

There is one interesting differnce between Linux and full operating system projects like FreeBSD, the other BSDs and OpenSolaris: Linux historically didn’t have much coordination between kernel and userland.

This becomes a problem for instance when udev and the kernel disagree on how to handle something, or on when you end up with a tool trying to use some old kernel interface.

It looks tremendously bad when you see that even strace fail (which on FreeBSD does not seem to happen, as ktrace is part of the single project). And I don’t know of any strace replacement.. and I relay a lot on that tool!

This gets further interesting when you add in the USB access through /proc (usbfs), that has been deprecated a long time ago, but that most people are probably still enabling in their kernel. The new interface, using /dev is available for quite a while, and libusb is supporting it very well. But as it turns out, VMware does not use libusb for accessing the USB devices, and it does not suppor the new interface.

I wonder how many projects have this problem. I remember net-tools being worked on, iproute2 replacing ifconfig and so on… but how many tools are actually always in sync between kernel and userland, as of now?

ALSA is also a very common problem with this as the drivers in the past often ended up out of sync between kernel and driver, causing subtle and obnoxious problems.

And even counting software tools that are well in sync between the two, how many of these tools are being audited for, for instance, performance improvements? I wonder.

I’m afraid this is a blog post without solution, but I’d like to make people think about this, maybe someone can help finding solutions ;)

… your medical records folder is ten times thicker than the job contracts folder. I was cleaning up through the paperwork yesterday and today, and there are so many things.. Luckily I have most of my CT scans in digital format, beside the last one I did at the ER last week, and a cerebral CT from a few months ago. But the release paperwork I had only in printed form, which I needed to scan and “PDFize” on Tuesday to send to my GP—nice to have one who’s reachable via e-mail.

It’s the scanning that actually made me think a bit. I have the scanner a bit far from my workstation; to scan a five pages document I have to prepare the scanimage command in batch mode on the workstation, then walk all around my desk to get to the scanner, and then get my arm around the monitor to press the return key on the keyboard to start the scan.

The annoying thing is that the scanner has four buttons on it, that should be made just for the task of starting the scan. Unfortunately these buttons don’t work out of the box on Linux at all. There is a package, called scanbuttond that polls for them through libusb and then execute a custom script when they are pressed. But as you can guess, polling means it uses a lot of CPU, and the fact that they run a generic script makes it less integrable in a desktop environment. Of course it would be easy to port scanbuttond to submit the read buttons back into the kerel input subsystem so that they appear as generic events, but… I think this should be a task well suited for a kernel module, hooking them up directly in the input subsystem, so that evdev could pick them up and then a program could just wait for them as shortcuts to have some action.

I tried looking into writing something before, but I ended up stuck in a problem: would a kernel module interfacing with the scanner interfere with libusb access by sane itself? Last time I enquired Greg KH, he asked me to proivde lsusb -vv output but, sorry Greg, work piled up and I forgot about all of it (until yesterday when I had to scan some more documents). Well, if anybody wants to take a look, this is it for my current scanner:

Bus 001 Device 003: ID 04b8:0121 Seiko Epson Corp. Perfection 2480 Photo
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass       255 Vendor Specific Subclass
  bDeviceProtocol       255 Vendor Specific Protocol
  bMaxPacketSize0        64
  idVendor           0x04b8 Seiko Epson Corp.
  idProduct          0x0121 Perfection 2480 Photo
  bcdDevice            0.00
  iManufacturer           1 EPSON
  iProduct                2 EPSON Scanner
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              16
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass       255 Vendor Specific Subclass
  bDeviceProtocol       255 Vendor Specific Protocol
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0001
  Self Powered

Can anybody tell if it would be possible for a kernel module and sane to access it at once? :)

If there is the chance, I might look at it once I feel better. I haven’t written or touched a kernel module in so much time that I’m feeling like doing some work in that regard. And the code to actually get the data out of the scanner should be present in scanbuttond already, it’s just a matter of getting it “pushed in” rather than “polled for”.

Once I could get the buttons working, I’d probably be working on a GTK-based frontend for scanimage with handling of those, so I could just use those rather than having to set it up manually. Although the nice thing of scanimage is that, through that, tiffcp and tiff2pdf, I can quickly create a multi-page PDF of the scan (the first command creates a multi-page TIFF file, the second converts it to PDF), and if I do the scan in lineart (the perfect solution for B/W text) it also is tremendously small in size. I should try to have the same result with my frontend. My idea would be a light frontend written in Ruby, calling the commands directly.

Oh well, at any rate, this will have to wait till I’m feeling really better, or maybe it’s just unfeasible because of the way it’d need to access the scanner from kernel and libusb.