Loud ramblings of a Software Artisan

The kernel developers have decided to add a really important system call. Here is detail of the man page that describe the corresponding libc call:

int is_computer_on(void)

It will return 1 of the computer is on. Otherwise the result is undetermined. Return -1 in case of error and set errno appropriately. Possible errno values are:

ENOPARSE impossible to parse the hardware status subsystem data. Happen usuall when your system is on crack

ENOFOOL can't be fooled by the value returned

EAGAIN sorry the system is busy doing something more important

This system call conforms to the AFOS 2006 release 1 specification.

Kernel developers expect helping developers of power management software such as gnome-power-manager. The kernel symbol is marked as GPL only to prevent proprietary device driver to link against it.

Off course ressemblance with an existing system call of a now defunct operating system would be pure coincidence.

STL, Standard Template Library is probably the most frightening component of C++. It is not required to use it for C++ programing, but it actually provides lot of base algorithms and containers.

When AbiWord started around 1998, the state of C++ compilers was not that great. Since AbiWord was supposed to be cross-platform, it was decided of a limited set of C++ features allowed to be used: no template, no exceptions, no multiple inheritence. That made the STL inappropriate, so base classes where written: vectors, hash tables, etc. Actually some containers like hash tables are in triplicate, including one that it barely used.

In 2004, after having lot of issues with our vector class using void* as a container type when storing integer values on 64-bits platform we decided to go with some templated classes. In fact I just templated one of the hash classes, the vector class and the stack class. Only simple template, no template function, in order to avoid possible pain with non conformant compilers, even if at the moment we only build using either gcc, or for Windows, Visual C++.

Now, I'm work on wrapping UT_Vector around a std::vector, and I will do so for some other classes. The idea is to switch to the STL (Standard C++ Library) and avoid the burdain of maintaining our libraries. At the moment everything compiles fine, but with a few glitches at run time. I'll post some benches once I have done some, including memory usage and binary size.

No comment:

• French struggle for us visas (the Register)
• Passport fiasco (Times Online)

And my passport does not meet the expectations required by only ONE country.

Update: Since questions were asked, here are the regulations about Visa Waiver Program and where it differs for France and a couple of other countries.

Q-FUNK provide us with thought about using prioprietary technologies to defend open source and open standards.

I have myself some other examples:

• willing to sell a webmail solution that requires IE/Windows to use when the whole engineering of the Linux based product runs Linux...
• or providing valuable information to engineering using Flash (and we all know how flash support is broken on Linux because of the proprietary nature of the technology).

But that is just internal business of privately held companies providing proprietary software solutions based on Linux (remember, you don't need open source your application if it runs on Linux), even if they pretend to be open source friendly.

Whenever you make business based on Open Source software, you should also think longterm about the Open Source ecosystem. These examples of bad management (yes they are bad management, but one of the options was not taken).

It like w3quebec meetings that requires Flash to be viewed online. One of their goal is to defend the w3c standard for the web, and to get the recordings of their proceeding you have to use the technology that hurt the most the open principile of the Web: platform independence and openness. There is a large debate in the FACIL mailing list on that matter.

Maybe I should just stop ranting and return to my code. (some STL crack)

Note: this only represent a personal view and does not represent the view of the AbiWord project.

I asked myself a question: shall we focus on one true Open Source platform, or shall will disperse the effort, trying to compete with the two other OS vendors, and waste lot of resources on that with more flexibility by maintaining AbiWord on Win32 (using Win32 APIs) and on MacOS X (using Cocoa)?

One of the "selling point" of AbiWord was that it was multiplatform, and unlike OpenOffice, it was using the native toolkit of each platform, ie Win32 on Windows, Gtk+ on UNIX and Cocoa on MacOS X. But this advantage is in fact being a real constrain, slowing us down in our developments. Writing a cross-platform UI is no picnic. It actually requires a lot of efforts and compromises, and these compromises are sometime really hard. For example there is still no support for SVG in AbiWord because one of the issues is printing them. To print them you need to provide these vectors to each and every printing backend, which is not an easy task: just rastering as a bitmap is not enough, so you need to have a SVG rendering in the native vector system (GDI on Windows, CoreGraphics on Cocoa, and so on). Another example is object embedding: we still don't do it, at least not in a standard way. Jean Brefort is doing some work with libgoffice to integrate the various GNOME-Office programs (mainly Gnumeric) to AbiWord, but the feature GNOME only. This is quite unfair to the other platforms, but it is still better than nothing. And this provide more credibility towards GNOME-Office, a project that only a fistfull hand of developers believe in. And AbiWord is depending more and more on GNOME technologies. Dom has started work to require libgsf for AbiWord, that create a glib dependency for all platform, depency already there for the OpenDocument filter.

Now lets go with the maintenance burden. So far the Gtk/GNOME version is the most complete and reliable. Why? Because it is the one where most of the developers put the work there, second being Windows. MacOS X is sort of lagging behind (I plead guilty for that), and Win32 still has issues.

It is time to pick a direction. Freedom has a price. We wanted to give users the freedom to use their platform of choice but today we pay the price as it slow us down to provide the best application possible, with the most complete feature set. With the Win32 and Cocoa ports of Gtk+, it might be viable to just use that toolkit on Windows and MacOS, sacrifying a bit of platform integration for a lot of features. A big tradeoff, but after all, users are happy with OpenOffice that do brings its own toolkit to provide features, so why not AbiWord?

The definite advantages I see are:

• easy SVG support, the dirty work being done with Cairo (actually that can be done now)
• object embedding with the rest of GNOME-Office. Jean Brefort has done some dirty work for that, but it is Gtk only. Since Gnumeric is Gtk-only it sort of make sense.
• platform equality

Shall we or shall we not? Proceding so would have us to require what Gtk+ requires. On Mac, it is MacOS X 10.4 (I was targetting 10.3 at that time, but who cares. I don't even run 10.4 anyway), while AbiWord currently targets 10.2. On Windows, I think it is Win98 and NT as a minimum, while AbiWord still works on Win95 (11 year old!).

This question hasn't been really discussed with the other developers.

Take a feature that have to be used with care (by the programmer) and make fun of the language by showing a misuse of it.

• C++ template recursivity
• C #include recursivity

And guess what? One is done by someone on planet gnome and the other by someone on planet KDE to reply to the first one. Any one to do it for C#, Python, Java, etc.? And Unix sucks because you can do:

while(1) fork();

and bring down your machine on the knees...

Canon recently announced a new DSLR, the 30D, to replace the 20D. Apparently Canon marketing has a really special technique to find product names (satire warning). As a result this 30D camera has a name similar to the D30, the first Canon produced DSLR camera, released in 2000. How long before some ebay sellers tries to send a D30 "confusing" it with a 30D.

Off course, the few extra features of the 30D could be found on the 20D with a software upgrade, and there is still no documentation for the RAW files which seems to have changed a bit, once again.

Everybody dreamt of it, Matthew did it

The gory details of unsupported hardware: Broadcom on PCI-E slot and ATI video card without drivers, but the firmware is kind enough to provide a linear framebuffer. Note that ATI still hasn't released any driver for unfreedom lovers customer.

Still willing to buy one of these (MacBookPro or iMac) to run Linux? I would think again if I were you.

The more I see things going the more I think that a new project should be founded to create a unified Digital Audio Player access library. See my previous post about it.

Reading Aaron DAP probes post to provide better support of DAP to Banshee and why it must be universal, as well as James call for help for Rhythmbox real give the facts.

So here is my idea. Let's create a library that will provide a unique API to connect copy music to a Digital Audio Player. Given the various nature of the devices, it should be modular with different backends so that the maximum device number are supported. The requirement are as follow:

• LGPL licensed. As converting to "non-free" format like MP3 or AAC can be required at one point higher in the stack (like the CD ripping software), the LGPL licence allow to have such "non-free" encoder being used by the client application. That might be a problem for existing code as some are GPL licensed.
• Modular: player backends should be dynamically loaded and developped thru an API. Let's not redo the same mistakes as the Linux kernel, that API should not change (or at least minimally) in the long term as maintaining driver for hardware that gets harder to get is becoming painful. libgphoto2 quite succeeded with that, but some camera that the less modular gphoto did support are no longer in libgphoto2 for these reasons.
• Platform independent: The library should not rely on any specific UI widget set, so that any dekstop project, GNOME, KDE or whatever can use it.
• Written in C: its API shoud be language neutral and that is at the moment the best way to achieve it. C++ is not to be excluded for specific driver, but shouldn't be part of the API.
• Code reuse: whenever possible re-use existing code. This would shorten the time to produce a functionnal version of the API. And developers of such libs should unite to that project to merge all the work here.
• No kernel module dependency should be required. Only exception is Mass Storage device, but in fact there should be no reason to expose the implementation details beside obtaining the mount point from the device... which HAL and other existing pieces would provide.

I wish I had time to devote to this project, but it is not the case.