It turns out, unix domain sockets can be “abstract” by making the first byte null. If you read “man 7 unix”, it explains it:

       *  abstract: an abstract socket address is distinguished  by  the  fact
          that  sun_path[0] is a null byte ('').  All of the remaining bytes
          in sun_path define the "name" of the socket.   (Null  bytes  in  the
          name have no special significance.)  The name has no connection with
          file system pathnames.  The socket's address in  this  namespace  is
          given  by the rest of the bytes in sun_path.  When the address of an
          abstract socket is returned by getsockname(2),  getpeername(2),  and
          accept(2),  its  length  is sizeof(struct sockaddr_un), and sun_path
          contains the abstract name.  The abstract socket namespace is a non‐
          portable Linux extension.

Rhythmbox:

1. Create a new playlist and add all your songs to it.
2. Right click on the playlist and select “shuffle playlist”.
3. Select all files in your (now shuffled) playlist, and drag them over to your mp3 player.

Command Line:

I used bash with Ubuntu Linux, but this would probably work elsewhere:

find ~/music -name '*.mp3' | shuf | while read line; do cp -v "$line"
/media/sansa/;  done;

This finds all the files in ~/music with .mp3 extension.  It shuffles that list of files, and then copies them over to /media/sansa/.  Of course, you’d have to replace ~/music and /media/sansa with your source and destination.

Quote from the link:

FX5700 first DVI output is working up to 165 Mhz pixel clock and second DVI output can goes only up to 150 Mhz pixel clock. Calculated pixel clock for 1600×1200@60Hz would exceed second output rate as this resolution needs up to 162 Mhz pixel clock : this would be ok for output 1, but problematic for output 2.

Here we are : with 9746 drivers, reduced blanking is automatically applied as we can see “Reduced Blanking enabled to bring Pixel Clock in range.” message in traces. Roughly, this eliminates the dead time needed by a CRT beam to be blanked and to be bring back from the end of the line to the start of the next line. Instead, this time is used for a LCD display to acquire DVI. Thus, the pixel clock can be brought back from 162 to 130 Mhz, which clock is compatible with the 150 Mhz rate of the card’s 2nd DVI output.

169.xx driver’s behaviour is completly different : if a calculated pixel clock exceed the max pixel clock for the output, this mode is directly invalidated, even with 2 LCD monitors.

Also, the dual screen calculated horizontal size (2660) is not consistent with fallback 1280 pixels + 1600 pixels (should be 2880).

I do not see specifically the reason why the monitor is blanked instead of having a 1280×1024 fallback. Maybe this is a double fault. I am letting that to nvidia gurus.

My primary monitor was connected via dvi, my secondary via vga.  My solution was just to enable one monitor at a time.  Since the 2nd monitor is actually a TV, I only needed to use one display at a time.