Miguel de Icaze points us at an article entitled ‘A Cost Analysis of Windows Vista Content Protection’.

In this article, you’ll discover all the wonderful ways Microsoft is making your next video card more expensive and/or less featureful, as well as removing the ability for certain functionality to continue to work in the presence of so-called “premium content”.

I find the whole thing vaguely amusing, considering that Prof. Ed Felton and others pointed out the flaws in HDCP, one of the lynchpins of the whole system. You won’t be able to get at the raw MPEG-encoded video when HDCP is cracked, but you’ll certainly be able to stream it into another high-quality encoder and get a pretty darn good approximation.

So, is this the “longest suicide note in history”?

According to LinuxWorld, the OLPC is going to drop the caps-lock key in favour of a key named “view source”. The purpose of this key is to allow the children to figure out how the current webpage or application is written.

I’m not sure why this key appeals to me so much. Maybe it has something to do with typing in BASIC games on my old computers and being able to edit the source of GORILLA.BAS and other interesting programs to make them do what I wanted. I think it is a fantastic way for the children to get to know how things work. Think of it as a transparent case on an engine or an analog watch.

UPDATE: The author of portaPuTTy has updated his build with the font fix as well. Excellent! I recommend going with his version - it's more likely to be supported.

I rebuilt a portable version of PuTTy using the latest 0.58 release.  It correctly saves font information (a shortcoming of the current portaPuTTy) and has all the updated security and bugfixes of 0.58.

I've also packaged up all the PuTTy executables (paegent, pscp, etc.) so that you can easily use them portably as well.  Note that all of the executables will load configuration files from $EXEPATH\.putty\configuration.

Get it here:

Portable PuTTy 0.58 (binaries)
Portable PuTTy 0.58 (source)

For those who want to know what I changed, here's a quick summary:

• Moved the unix storage backend into the windows storage backend, since it has all the code we need
  
• Added a BSD Win32 "dirent.h" and "dirent.c" implementation
• Changed the code to look in the EXE's path (via GetModuleFilePath(NULL)) instead of $HOME
• Added the Win32 font load/save code
• Hacked the Makefiles manually to add dirent.obj (out of sheer laziness ;))
  

There's no patch available, but those instructions will reproduce the exact build I provided from the latest SVN or source packages.

Looks like NDoc is one of many .NET open-source projects to “bite the big one”, but certainly not the last. I stopped development on NProf a while back because I couldn’t build up any momentum around it. I suppose that it was slightly annoying that I found some of my GPL’d code in Jetbrains’ new profiler. Perhaps they could have contributed something back to NProf at least. ;)

NAnt releases are getting further apart and the mailing list traffic is dwindling. Log4Net seems to be moving so slow I don’t know how they manage to get releases out!

Is there such a fundamental difference between .NET and Java developers that one community can sustain such a great set of open-source projects and one can’t?

The sad thing about the death of open-source projects on the .NET platform is that they end up being replaced by closed-source (or worse – shared-source) projects that you can’t fix bugs in or redistribute without a team of lawyers.

I’m not sure why, but they don’t seem to learn anything from the open-source equivalents that they clone either. Compare NAnt to MSBuild, for instance. MSBuild ends up being a horribly complicated system that doesn’t let you do half the stuff as clean or as elegantly as the equivalent NAnt script.

As the original author of the solution task in NAnt, I can now say that I’m glad that they have to deal with the numerous ideosyncracies in their bizarre world of .NET project building, like reading source files to figure out what the names of embedded resources are.

All I can really say to them is good luck re-implementing all this stuff.

I just released the first beta of the Treo 650 ROM tool over at:

http://grack.com/romtool

Give it a shot!

I got the USB networking layer up and running last night. The secret was determining the correct GPIO for USB cable insertion/removal. Everything else was handled already!

Pinging a device over a USB cable is neat to watch, but Shadowmite is working on getting dropbear ready so that we can SSH over to the phone. This will make it easy to quickly transfer new kernel modules (saving a reboot).

Last night’s hacking progress was targeted at getting the SD/MMC driver up and running. Since the PXA27x platform has built-in SD/MMC support, it’s just a matter of setting up the SD/MMC communication GPIOs (clock, data, command channel) and locating the GPIOs for detecting SD card insertion events and read-only status.

I haven’t managed to get the SD card driver working on my phone, but I think it has something to do with my SD card. One of the testers on the IRC channel got it to mount his 512MB high-speed SD card correctly.

The problem is that the data received from the SD card seems to fail its CRC check. The errata for the PXA platform indicates that there might be trouble with some SD cards at certain speeds. Since the card works fine in PalmOS and the bootloader, I’m guessing that I might just need to add a retry or delay at some point until the SD card is ready to go.

I started reading through Alex Osbourne’s patches for his port of Linux to the Palm LifeDrive and it turns out that a lot of the work for supporting the Palm Hardware has already been done!

This an example of where Open Source shines – each new platform developer writes a couple of new drivers, making it even easier for the next port that comes along!

I just wanted to thank Alex for blazing the path that I’m going to be following here. There’s a lot of work in decoding GPIOs and handling the minor platform differences, but we can certainly share a lot of code.

Using the PXA matrix keypad driver from the LifeDrive Linux port, I managed to get full keyboard support for the Treo 650. It took a lot of manual keyboard matrix decoding, but you can now type into the Busybox shell!

I need to figure out why Busybux isn’t accepting the KP_ENTER key as a proper return. I’ll bet it’s some sort of userspace keyboard mapping, but I’ve never played with that sort of thing.

Get it while it’s hot! I’ve started dumping information to the handhelds.org wiki:

Palm Treo 650 Wiki Page

I also managed to get the LCD properly initialized last night. It turns out that the L_BIAS pin set in pxafb.c is being set, even if the attached display doesn’t require it. This causes the Sony LCD that the Treo uses to go entirely white (as if it were disabled). Commenting this line out fixes it, but I’ll need to add a proper check for display type before submitting a patch to handhelds.org.

Once I have a keyboard driver and some way of communicating with the device (it’ll be either Bluetooth or USB Ethernet) I’ll probably push out a release for early adopters to play with.