Tangled Time

I’ve had a Cordless Optical Trackman now for a couple of months. I originally bought it because I was starting to get a sore left hand: I transferred my mouse to the left a couple of years ago.It took me about a week to get used to it, but once I was comfortable, I found it better than using the mouse with my right hand.

Anyway, back to the Logitech. I bought the Logitech because it looked like the best designed trackball, apart possibly from the Microsoft trackball, which is no longer available.

My hand position is mostly good.  It fits the palm of my hand nicely. It’s got a shelf for the thumb which provides a very comfortable rest.

I’ve had no problems with the cordlessness. I haven’t had to replace the batteries yet. But corded wouldn’t have made any difference either: it sits in one position on the desk, and you don’t tend to need to move it.

Now the annoyances…

Very early on I noticed that the scroll wheel was very clicky, putting up a lot of resistance as I turned it. For someone who uses a mouse a lot, this isn’t a great design. I think that this is standard on Logitech mice, and it’s one of the reasons that I’ve always avoided Logitech devices. So I disassembled it and found that I could remove the little spring that gave the wheel the click. I’ve found this MUCH better.

The next niggle I’ve had: with standard setup, the main button is pressed using the thumb. Now this is quite comfortable, but the mechanism is stiff, and you have to give quite a press. For short usage, this is no problem. But after clicking and dragging all day, I find that my thumb was becoming tired! I took it apart again to see if I could do something to make the click better, but they’ve used a sealed microswitch, and I couldn’t find a way to adjust it. So I switched the main button the the right hand side. This button falls under the ring finger, and the switch that Logitech have used there is much better: it only needs a light touch to click.

However, one negative result of this change is that I find that I’m splaying my fingers to roll the ball, while being able to click. Not good.

[Later: I eventually changed the main button back to the left because my fingers were starting to hurt.]

The Trackman has a lot of buttons. The two main buttons and five others. Six if you count the click on the mousewheel. I think that’s terrific: more buttons make the mouse more useful. But there’s a problem: Logitech don’t support Linux on this device and I’ve found myself using Linux a great deal in the last couple of months. To the extent that it’s become my primary operating system!!

It works fine on Linux and most of the buttons do something, but it would be very nice if there was a dedicated control panel for the mouse. On the other hand: the Windows driver/control panel for the mouse weighs in at 55MB!

Overall impression. Not as good as I’d hoped. I was hoping that I would be converted to trackballs, and while I’ll carry on using it, I’m a bit disappointed; there shouldn’t be this many issues with a product that only does a few things and costs fifty quid.

Would I buy one again? No, probably not. But perhaps I’ll buy one of the other trackballs to see if they are any better. I’m not very keen though to buy another Logitech product: I’d feel like I was rewarding them for not being good enough.

I find that I’m using Linux on the desktop more and more. It’s certainly good enough for techy users, and for some non-techy users too. But I still use Windows on a day to day basis, and I’m likely to for the foreseeable future. On the other hand I don’t trust Windows security: there have been too many unfixed problems.

What I really want is to be able to run Windows on top of Linux. That would isolate Windows to some extent. And if I use a virtualised solution, then I’d be able to run other operating systems alongside Windows whenever I want to test something out. Sounds like a good solution.

But I want it to run at a reasonable (near native) speed, and I want to make proper use of my graphics adapter even in guest operating systems. I should be able to play games in Windows Vista.

I had a look through most of the virtualisation solutions listed on Wikipedia. It turns out no solution can do exactly what I want.

Here’s the state of the art:

• Xen, which is what I use on servers, can’t do 3D graphics. There are suggestions in the mailing list about how 3D graphics might be achieved. More on this below. And there’s an interesting bit of work, called Blink.  This lets you use Dom 0 graphics with panes controlled by other Doms. Neat! Unfortunately the source code for this is no longer available; it seems like the repository went away.
• X11-based guests can use VMGL for 3D graphics. Not for Windows. It works with Xen, but can also work with VMWare.
• VirtualBox has the beginnings of support for 3D graphics. At the moment it’s only
• OpenGL on Windows guests on Windows hosts. The most important bits of OpenGL reportedly work.
• VMWare, both Server and Workstation versions, has experimental 3D support. Interestingly, Jacob Gorm Hansen, who developed Blink now works for VMWare. I wonder whether this is also his work. It looks like Xen slipped up in not hiring him.
• KVM doesn’t yet have 3D support, outside of VMGL, but it’s growing so quickly that you can expect it will before long.

After looking at various mailing lists and the solutions above, several mechanisms for exporting 
3D graphics to guest operating systems become  clear:

• You might be able to export a whole graphics adapter to a guest OS. This requires a PCI pass-through mechanism. A sticking point here appears to be that the graphics drivers expect to be resident at particular absolute addresses. So, for this to work you’d need an address translation scheme. You’d also only be able to see one desktop/guest OS at a time: the OS would gain complete control over the graphics.
• Paravirtual drivers. Which is what VMGL looks like. It’s aware that it’s operating in a virtual environment, and passes data to a common underlying subsystem for rendering. This seems to me to be the best mechanism. But Windows is not all about OpenGL.

But, there’s a viable path for Windows. If you had a paravirtual windows driver, it could take Microsoft Direct3D calls, and translate then into OpenGL. This could then be passed through VMGL. Voila!

For other operating sytems, you’d have to do something similar, where they supported a 3D API.

In fact, this wrapper exists in part already. (As it’s under the MIT licence, and it’s for Direct3D 8, I wonder if this found its way into 
VMWare, which supports Direct3D 8.1.)

What remains is the not inconsiderable task of writing a Windows driver, or two, which use the wrapper.

Then I’ll have the environment I want. Anyone interested in writing this for me?

I’ve never been a fan of Logitech mice because I really don’t like the clickiness of their scroll/thumbwheels. It seems to be a standard part of their design, but when you use a mouse for hours on end, mechanical resistance just isn’t good.

I bought a Logitech trackball a day or two ago, because it seemed like the best design on the market. It’s just been delivered. When I opened the packaging and tried it out, the wheel was clicky. Echh.

It turns out that a little easy surgery will cure it of clicking.

1. Remove the ball. Turn the trackball over, and using a small philips screwdriver, undo the 4 screws that hold it together. On mine were screws were very tight indeed and needed a bit of forceful persuasion.
2. Very carefully pull apart the base and top of the shell. You don’t want to break the cable connectors that run between the top and bottom.
3. Unscrew the small circuit board that holds the scroll wheel in place. It has two screws: one small and one larger. These were also very tight on mine.
4. Lift the circuit board away, being careful not to pull on the cables.
5. Lift the wheel assembly out. It comes out vertically/at right angles to the shell housing it. The scroll wheel is part of the assembly. (You don’t need to try to twist the wheel off while it’s in place in the in the shell.)
6. Now the wheel slides easily off the assembly.
7. Remove the small spring that was sitting against the wheel inner rim. It too simply slides off the assembly. This is the cause of the clicking.
8. Slide the wheel back on to the assembly, replace the assembly in the shell, the circuit board, and then screw the two halves of the shell back together.
9. Enjoy clicky free scrolling!

I’ve been working on addresses and locations in Drupal for the last few days.

Addresses, it turns out, are not as simple as you would think. The OASIS document specifying name and address structures in XML stretches to 67 pages. And the bulk of that is worth reading. (If addresses do it for you.) I won’t give a direct link to the document - it’s part of a zip file containing lots of other stuff. Search on xAL (extensible Address Language), xNL (extensible Name Language), xNAL (guess), xPIL (extensible Party Info(?) Language).

There are lots of resources, but for me, this superb address resource stands out. Thank you Frank.

So good it’s worth repeating!! Woohooo! Boingboing covered my stuff!!!

Want to buy a large, well-equipped overland truck? BoingBoing covered it!

Well, it’s South Africa vs England in the World Cup final next week! Quite a surprise really, considering.

Still, England: 36-0!

Embarrassing.

I’m not a fan of Norman Tebbit, and I think he was wrong because the world is more complex than his Cricket Test supposes, and I definitely have split loyalties here. But 36 Nil!?! I don’t fancy much for the underdog here.

36-0?

I found a good thing a couple of weeks ago for hiding email address from spiders - check out ReCaptcha  which uses captchas to hide email addresses, and uses the captchas to digitise books. Terrific idea! Even better: there’s already a Drupal module which implements it.

I was initially worried that it was a scam to get people to decode captchas so that malware could bypass the walls put up to stop it, but it turns out that it’s an initiative from Carnegie Mellon University, and that gives me confidence that it’s not.

I was looking for a better way to be able to hide email addresses from spiders.

I found these two related useful studies:

• Comparison of obfuscation techniques
  
• Effective methods of hiding addresses

Upshot: Most hiding mechanisms are usesless. The best at the moment is to split email across two lines, something like this:

Person: joe.soap
Location: example.com

Maybe an autogenerated link to a form protected by a captcha would solve the problem.

My friend Scherrit and his wife recently opened a bike shop in Ealing, London. They are absolutely mad about bikes and biking. They’ve just gone live with their website, and no doubt could do with a few inward bound links… If you live near Ealing, or even if you don’t, The Bike Whisperer is the best place in the world for bicycles.

I’m sure I’m not the first person to notice that JavaScript really doesn’t have the server side presence it deserves.

It was amongst one of the first scripting languages, it’s got a standardisation committee, it’s a powerful dynamic language, it’s widely used on the client side. So what’s gone wrong?

I think that there’s no single reason, but a bunch of important ones.

• It doesn’t have mod_javascript. This is a biggie. Yes, there’s Rhino, but this is based on Java. If we wanted Java, we’d just use Java. And I’m sure that Spidermonkey can be used on the server side, but it should be embedded in an Apache module.

• It’s never had a strong central location/destination. PHP has PHP.net for instance.

• Also it helps to have a body or person who is tasked with promoting the language. PHP has Zend. Perl has Larry Wall. C++ Has Bjarne Strousup. JavaScript has ??? Where is the Javascript Foundation? [Update: On reflection, I’m being slightly unfair here - Brendan Eich was JavaScript’s creator. What I’m trying to say is that he’s not very interested in marketing JavaScript.]

• It’s never had a great collection of scripts. Perl has CPAN.[There is now an effort in this direction - JPAN]

• It gained a reputation for difficult-to-use on the client side. That’s to do with all the versions, the incompatibilities between browsers and the fact that objects can be altered.

• The client side problems has given it a bit of a reputation as a security pitfall. Especially true in Microsoft environments.

• It’s never had a really important server side project to show what it’s capable of. See Ruby on Rails to see what this has done for Ruby.

• It’s not quite elegant. The way that Ruby is. But the new spec is moving in that direction.

There’s still a chance for JavaScript. There’s a compelling argument for using the same scripting language on the client and server. However it faces some strong opposition because so many other languages have a stake in serverside development now. If it has a hope of resurrection each of the items in this list need to be tackled.