• Full mode setting driver for ATI Radeon R5xx and R6xx capable of driving multiple monitors.
• Full RandR 1.2 support (with early RandR 1.3 property support).
• Full libpciaccess support.
• Supported subsystem:
  
• Outputs: DVI-A, DVI-D, DVI-I, VGA.
• Hardware cursor.
• I2C for DDC.
• Shadow framebuffer.
• AtomBIOS support for initialization, data tables.
• Backward compatibility to at least X.Org R6.9.
  

•  Starting afresh gives the opportunity to cleanly. The Radeon driver has largely been rewritten for RandR 1.2 support but it supports a long list of chipset generations of which the earlier ones have not much in common with the latest one.
  There will always be some overlap in subsystems between chipset generations but one should think twice to use this argument to add more and more generations of chipsets to the same driver module.
• The step from R4xx to R5xx provided a good opportunity to start with a new driver module:
  The mode setting interface has changed with R5xx hardware compared to earlier hardware. As mentioned above the video overlay engine of earlier chipset generations is gone.
  The 2D and 3D engines are pretty much identical to earlier hardware. However 3D is only relevant to the extent as it is used for 2D acceleration in the X.Org driver anyway.
  Core components of the code for 2D acceleration could well be shared between the two drivers if this is desirable. 
  
• Libpciaccess should offer support to automatically identify and load the correct driver module using the PCI vendor and device IDs from the drivers - pretty much as done already in the kernel. Therefore having one driver module per hardware vendor to simplify configuration for the user is an argument that becomes pretty much irrelevant in the near future.
  I don't think we will be opposed to put the RadeonHD driver under a common umbrella with the other drivers for ATI hardware.
  There has been a wrapper that probes for the hardware and loads the appropriate module which may be interesting to use if libpciaccess doesn't perform this job already. This loader module needs some serious cleanup before though.
  

•  2D acceleration (XAA/EXA). For R5xx this should be rather easy to implement as it is rather similar to earlier chipset generations and is actually on our TODO list.
  XAA will be required for backward compatibility. At least until the very recent Xserver releases EXA still had issues so it was not enabled by default.
• 3D support (DRI/DRM). Here again R5xx is not much different from earlier Radeon chipset generations thus support for this should be easy to do.
  This is not so much the concern of the X.Org driver as this is only involved in subsystem initialization.
• Video overlays
  Also video hardware overlay support as known in earlier hardware does not exist any more. In fact the video scaler is not available any more, only overlay support and some limited color space conversion is still available where the latter is rather irrelevant as these operations can be performed by modern CPUs at almost no cost.
  Full video overlay support requires some 3D support to perform the scaling of the video to the size of the window.
• TV Output.
  This is actually something what is on our todo list.
• Power management.
  This will require some more documentation also.
  

• It is claimed that AtomBIOS code will provide support for new generations of hardware without the need to adapt the driver. This is true to some extent - however new generations of hardware may require an extension to the API of the table so the driver will still need to be fixed.
  Furthermore we have found several cases where the API of the AtomBIOS call tables has changed between different BIOS generations in a way not reflected in the header.
• We have found cases where code in the call tables contained bugs. We assume that AtomBIOS code has been tested to the extent the ATI Catalyst driver uses it. 
• Several call tables are not sufficiently atomic. Thus subsystems that should be treated independently cannot be handled this way.
  For instance SetPixelClock which programs the PLL parameters to the pixel clock also calls EnableCRTC. This functionality should clearly be left to the component handling the CRTC subsystem.
• AtomBIOS does not provide save/restore functionality. Since it is unknown which registers are touched by an AtomBIOS table it is hard to save and restore the text mode.
• Using AtomBIOS will probably work in the majority of cases but numerous users might run into problems which are hard to control as control over a released BIOS is very limited.
  Thus we expect that using AtomBIOS - although very compelling from a distance - may lead into a workaround nightmare.

Last Monday I submitted lot of changes into Strigi’s trunk. I’ve heavily refactored some classes in order to obtain a more flexible file system notification infrastructure. Thanks to this work now it will be easier to add support for new file system notification facilities. For example, in order to add File Alteration Monitor (aka FAM) support I had to write only 576 loc (including license and documentation stuff).

So, by now, Strigi supports the following file system monitoring facilities:

• polling: used when nothing else is available
• inotify: available only on linux platform with kernel >= 2.6.13
• FAM: available on most of the *nix systems, I recommend to use Gamin instead of FAM (most linux distributions already use it by default)

Maybe someone has already experimented this situation:

You’re hacking on your local working copy and you want to keep it up-to-date but, since you have some uncommitted changes, git-svn rebase cannot be executed

I was just thinking to write something about_ _this problem when I read a post on digikam blog.

In this post Marcel proposes a workaround using a bash function. In fact there’s a “cleaner” solution, if you’re interested read the last part of my git-svn howto.

Last days I saw a lot of warnings in /var/log/messages, that my hard disk will die soon, thanks smartd. I used this disk only as a storage, to backup my work, my notebooks, movie, music, .... I don't want to lose all these things, so, I decided that is the time to buy a new hard disk. There are many options here, I can buy an internal hdd and put it in my desktop, buy a dedicated NAS, for home use, use a old computer and install FreeNAS on it, or just take an USB external hard disk. I would stay away from the NAS the reason being the cost, and flexibility reasons. I am looking for an external storage, and I am not interested in sharing files off computers.

The best option would be to take two external USB drives, which are simpler, so they are generally less expensive, much less expensive than NASs. I said two drives, because every hard drive will fail and I will need one as a backup. It's cheaper to buy two external drives and using one as a backup than purchasing a NAS and setting up the RAID. Also after, you still don't have a stand alone backup.

Finally, I decided to buy a Buffalo, DriveStation TurboUSB.

The drive enclosure contains a 500GB, SATA disk, 7200 RPM. More details about this nice external drive here. It is quiet and uses a heat sink for heat dissipation, but also has a connector to use an optional fan that Buffalo sells as well. This drive contains Buffalo's TurboUSB technology, which seems to be a software method to allow increased data transfer speeds of up to 37% faster than those of standard USB hard drives. It comes with FAT32 preformated file system, ready to be used:

*vioan:\~ \# fdisk -l /dev/sdc*

*Disk /dev/sdc: 500.1 GB, 500107862016 bytes  
255 heads, 63 sectors/track, 60801 cylinders  
Units = cylinders of 16065 \* 512 = 8225280 bytes  
Disk identifier: 0x00000000*

*Device Boot Start End Blocks Id System  
/dev/sdc1 1 60801 488384001 c W95 FAT32 (LBA)*

Also, on cd, there is Memeo™ AutoBackup software (Download Memeo™ AutoBackup), and the disk comes with SecureLockWare™ technology. I was surprised to see in the box also an plug adapter for UK (they have three pins, not two as in germany).

Because, I don't have many files larger than 4G, and I would like to use this external hdd also on unix/linux machines, not only on windows, I decided to keep fat32 as file system. Finally, I copied all my files from the old hard drive on the new external drive. For moment my files are safe. I am planning to buy a second one, in the near future, but I am still not sure when :). This was my story, I am waiting for your comments, and, also please fell free to share it.