Doesn't the MultiProcessing package permit you to work around the GIL issue by using processes instead of threads? I maintain a Python application that does just that.

It makes communication between parts of the program difficult, but otherwise seems to work fine. And it's part of 2.6 -
not a non-standard, native module.

I haven't decided. The intent is actually to map network traffic (i.e., one part captures traffic, stores the packets locally, and sends summary information to a server where another part of the app can access it to develop interactive maps and charts to evaluate the information). It currently has no concept of routers, switches, etc. but is focused on the traffic itself.

I have a SourceForge page for it (search Google for Flower NFA), but haven't updated the code there in many months. The code I have locally works well to generate flow maps and volume histograms.

It's a bit fragile, and still needs a lot of work, but it's coming together. If you'd like to try it out, e-mail me at email@justinthomas.name. You'll need a Debian box for the capture portion (it's written in Python) and a Glassfish v3 server for the Analysis and Visualization components (Java). I run all portions virtualized in two servers (Debian and Windows 2008) on a single XenServer.

I've tested with an application that I'm developing that generates complex SVG network maps (that validate as SVG 1.1 with the W3C validator with no errors).

Linear gradients don't work at all, stroke and fill colors appear to be sporadic. JavaScript doesn't work (but I didn't expect it to as it's targeted to Chrome and Safari primarily right now).

I expect that MS will add more functionality as the preview progresses. They have a lot of work to do, regardless.

Ah. My bad.

You're doing something very wrong. I use an iMac and a Macbook Pro (both far weaker than the machine you're using) and routinely copy around gigabytes of data without the types of delays you're talking about.

I just did a quick test with dd and copy:

imac:~ justin$ date
Mon Feb 1 11:46:09 PST 2010
imac:~ justin$ dd if=/dev/zero of=./test bs=2048k count=20
20+0 records in
20+0 records out
41943040 bytes transferred in 0.562810 secs (74524341 bytes/sec)
imac:~ justin$ date
Mon Feb 1 11:46:19 PST 2010
imac:~ justin$ sudo cp test /
Password:
imac:~ justin$ date
Mon Feb 1 11:46:39 PST 2010
imac:~ justin$ ls -lah /test
-rw-r--r-- 1 root admin 40M Feb 1 11:46 /test
imac:~ justin$

Even with pausing to think about what I was typing and to enter my sudo password, it took 30 seconds to create a 40MiB file and move it to another folder. Honestly, it was probably more like 10 seconds, considering that most of that time was me being slow and mis-typing.

Some folks prefer to separate the tasks - rip on Windows, convert on Linux.

I haven't looked at megui in a while, but most windows apps I've seen integrate different utilities by passing command line parameters. As I understand it, HandBrake tries to avoid that by linking the libraries directly. As a result, the HB package comes with all of the necessary parts (for what it does) and compiles those dependent tools into the overall package.

Different strokes, I guess. My experience with other Windows utilities has always involved installing dubious codec packages and frontends that may or may not actually work with the versions of other tools that you have to install separately. I gave up on that nonsense a long time ago, though, so I suppose it could be better now.

eac3to breaks open the EVO and splits in to elementary streams. Tsremux allows you to recombine the streams into a m2ts file. Handbrake converts the intermediate m2ts to an h.264/ac3 file in an mp4 container.

Tsremux can also do some of this conversion without eac3to.

AnyDVD HD handles the HDDVD and Blu-Ray decryption.

Despite the Troll rating on my above comment, I'm sticking by my statement. H.264 blows DivX away. I wasted too many years on DivX, XviD, etc. Once you move away from it (for encoding and playback) you absolutely will not miss it.

Heck, h.264 is what's used on many Blu-Ray disks (VC-1 on some).

Maybe. It'll also convert from m2ts files (e.g., files remuxed from a Blu-Ray or HDDVD disk).

That's the extent of my knowledge as it's all I've seen it used for, but it could be more flexible than I realize.

Urk. I replied to the wrong comment - see my post to the grandparent.

From my perspective, I use it solely on Linux from the CLI. My main computer is a Mac, but I have more power in my Linux server (four cores, 8Gb RAM), I've used other programs, but none handle the task as simply as HandBrake. The developers can be a little snarky, but you take the good with the bad.

I do use it for Apple products (mainly Apple TV). But having used both DivX (in my pre-Mac days and for a bit into them) and h.264, I can't imagine switching back to DivX.

True enough. I've never tried using x264 and ffmpeg by themselves. HB makes using a bunch of different programs to accomplish a single task pretty easy.

HandBrake is the de-facto standard for creating h.264 files on Mac, Linux and Windows systems. You should get to know it; you won't miss that crappy, proprietary DivX.

And humble, to boot!

"Or how about showing me an image that I picked out but will soon ignore after seeing that it never changes?"

That's kind of the point. If it changes, then that's an indication that someone might be trying to scam you.

Regardless, it's a weak mechanism.