FOSS.in is over
I'm not going to write any more about FOSS.in,
since everyone else has already written about anything that there is to say. If you want to read all of it, go to planet.foss.in.
One fact that hasn't very much publicized [yet?] though, is the financial
trouble that the event formerly known as Linux Bangalore is going through this
year. This apparently is almost exclusively to blame at the sponsors (or lack
Apparently in India it's quite normal that even if you start talking with
Sponsors more than half a year in advance, they will not commit until a few
days before the event starts. This is also the reason why the conference
programme is announced before the sponsors show up on the website (if you
checked it before the event, all the sponsor banners were empty).
Due to this strange culture, it could happen that a large Indian IT company
dropped their sponsoring commitment almost immediately before the event - that
is _after_ the organizers having committed to all the expenses. I don't think
that given those conditions, any organizer could have managed without a big
large gaping hole in the budget :(
In addition to that, it is is a pity that none of the internationally recognized
(and also locally quite present) "open source" companies Novell/SuSE and RedHat
didn't show up on the sponsors list at all.
libusb > 1.0.7 broken
Sometimes I really feel like I don't understand what's going on with some
projects and/or developers. The last time I looked at libusb source code, it
was the 1.0.7 release - and everything was working as expected. When you
submit a bulk/interrupt read request, then it would do a blocking read until
the user-specified timeout has expired.
When recently strace()ing a program using libusb, I found out that with my
currently-installed version (1.0.10a), it actually does a non-blocking read
(REAPNDELAY), then uses select to implement a 1ms sleep, and starts all over
again until the user-specified timeout has expired.
This is really bad. Not only clutters it your strace output with lots of
noise, but it actually uses CPU, wastes cache lines, and probably most
importantly: eats battery on notebooks!
I'll ask the libusb folks what kind of madness this is. Probably it's time to
publicize libausb at some point (the libusb-wrapper that I implemented for
async URB handling in the ctapi-cyberjack drivers) - and which now uses a copy
of the libusb-1.0.7 functions for blocking bulk read/write, too.
New userspace-only driver for cyberjack e-com (0x100)
I've just checked in a userspace-only version of the cyberjack e-com (0x100) driver.
This means that we'll finally be able to work around the many broken old
(drivers/usb/serial/cyberjack.c) cyberjack drivers that almost all the
distributions ship. Apparently almost none of them seem to bother merging
upstream fixes into their trees.
One minor problem though is that both cyberjacks need asynchronous delivery of
interrupt URB's, a feature that is not available by libusb. The libausb
wrapper library that I developed for this purpose is specific to Linux
usbdevio, so the userspace driver won't be working on other libusb supported
platforms such as *BSD :(
This is in response to Oh my, this was from running yum update on a 2.6.13 FC3 system and had reached the transaction test but got OOM killed.:
I've seen this numerous times on FC3 (probably even older FC) systems, and no
matter how large you make swap, it never really works. The only workaround I
found is to manually split the update into tiny chunks, and then update those
tiny chunks each itself rather than a full system-wide update.