Loud ramblings of a Software Artisan

Friday 3 March 2006

Linux on Intel iMac

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.

Digital Audio Player access, take 2

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.