I grabbed my camera with the 17-85mm lens and managed to get a few shots before he wandered off again.

I put a bigger lens on and managed to get a few more snaps before he disappeared again. About 100mm focal length on a 1.6x crop camera, so about 160mm.

Before soon he wandered off again.

More pics.

However,  it can be done.

Configuring the Speedtouch is a real pain for Be, as the Speedtouch only supports PPPoA or PPPoE as standard. However, Be use RFC 1483 bridging (aka EthoA). The 516 can support RFC 1483 bridging, but you need to upload a template to add the configuration options to the Speedtouch’s web interface. That, or figure ou the magic CLI runes which can be entered over telnet, but that is left as an excercise to the reader.

Thankfully, the nice people at another LLU ISP, ADSL24, have provided a  template which works perfectly with the Speedtouch and Be.

Just follow the instructions here to download the template, upload it to the Speedtouch, enter your Be IP, netmask and gateway, and away you sh
ould go :)

I do not know which models of Gigabyte motherboards are affected but the Gigabyte GA-MA74GM-S2H certainly is; according to this post on opensolaris.org, the GA-G31M-S2L is also affected. If anybody else has experienced this, please post a comment.

The Host Protected Area means that a certain area of the disk is reserved. That’s not too bad on a disk that has never been used in another system. You lose a few tens of megabytes, which isn’t too significant on disks of hundreds of gigabytes. However, if the system has already been used in another system, and contains a partition table or is part of a RAID array, or LVM volume, your data will not be accessible and will essentially be lost.

I unfortunately discovered this problem myself when I upgraded my home Linux-based home fileserver. I upgraded from an Asus motherboard. I had four 300GB IDE disks that had been part of a RAID 0 array (yes, I know about the data loss implications of RAID 0; they’re acceptable for my use). I discovered that Linux’s md could not reassemble two of the disks back into the RAID array. The other two were fine — these were connected to a Promise IDE controller. As the disks were around four years old and had been on 24×7 for that time, I came to the conclusion — although unlikely — that both of the disks had died simultaneously.

Hindsight is a wonderful thing. Unfortunately I had never had any prior experience of Host Protected Areas. However, whilst debugging, I should have noticed the following:

hde: max request size: 512KiB
hde: Host Protected Area detected.
 current capacity is 586070255 sectors (300067 MB)
 native  capacity is 586072368 sectors (300069 MB)
hde: Host Protected Area disabled.
hde: 586072368 sectors (300069 MB) w/8192KiB Cache, CHS=36481/255/63, UDMA(100)
hde: cache flushes supported
 hde: hde1 hde2
hdg: max request size: 512KiB
hdg: Host Protected Area detected.
 current capacity is 586112591 sectors (300089 MB)
 native  capacity is 586114704 sectors (300090 MB)
hdg: Host Protected Area disabled.
hdg: 586114704 sectors (300090 MB) w/16384KiB Cache, CHS=36483/255/63, UDMA(100)
hdg: cache flushes supported
 hdg: hdg1 hdg2

Unfortunately the motherboard, without my permission, was denying md access to part of the disk, meaning that md could not assemble it into the RAID array. Data loss bugs are some of the the worst kind of bugs and I find this behaviour of this motherboard rude and entirely unacceptable.

For me, this wasn’t terrible. Most of the data was backed up to tape, and thus restorable, and what wasn’t, was easily replaceable. But I hope that this post helps someone that thinks that they have lost their data, and encourages Gigabyte to change the unacceptable behaviour of their motherboards.

[1] Sure, using RAID 0 dramatically increases the risk of data loss, and that was acceptable to me as it was personal use, not business critical, and I was happy with the possiblity of a disk dieing. I’m not happy with the fact that Gigabyte hardware behaves in unexpected and totally different ways to all of the (considerable quantity of) other hardware that I’ve used.

French police use police van to block exit of car park in Arromanches, Normandy, to prevent anyone going home, exit is blocked for nearly 2.5 hours while Brown and Sarkozy make themselves look important making speeches in town

Can’t Gordon Brown do anything right? As a result of the security arrangements for Gordon Brown and Nicholas Sarkozy, and the complete incompetence of the French police, hundreds of people, including D-day veterans themselves were trapped in a car park in Arromanches, Normandy, for nearly two-and-a-half hours, without toilets, food, drink, and any idea about when they would be able to get out.

I am currently visiting Normandy for the 65h Anniversary of D-Day. Today — being the 6th of June — marks the exact day that it happened 65 years ago. I decided to spend the day in Arromanches, a town that bears the marks of the invasion to this very day, with the remains of the Mulberry harbours punctuating the horizon across the open sea of the English Channel.

As I drove from the campsite this morning to Arromanches, a distance of around 60 miles, I was struck by the huge number of police everyday, on all of the motorway bridges. After an utterly fantastic day in Arromanches seeing the veterans, and looking at a British Army landing craft on the beach, and a vast number of army vehicles including Jeeps and trucks, the time came to go home.

I returned to my car at 5pm, but just as I went to leave, the entrances to the car park were suddenly closed, without warning, by the French police (Gendarmerie). We were initially told that this would be for around 20 minutes whilst the convoys of Gordon Brown and Nicholas Sarkozy went past into the town. Very annoying, but tolerable.

What actually happened was that the road was closed, road blocks were implemented, and hundreds of vehicles (including modern cars, camper vans as well as veteran military vehicles) and hundreds, if not thousands of people were trapped in the car park, a field, a short distance from the beach at Arromanches. For just short of two-and-a-half hours. This was for the time that it took the convoys to get to Arromanches, Brown and Sarkozy to make themselves look important, and to finally leave.

After being trapped for over an hour, a D-Day veteran had to beg the police to be allowed out as he was likely to miss his ferry from Cherbourg. I have no idea whether he managed to catch it in the end

Not only were there those interested in history, like myself, but also D-Day veterans themselves. I was absolutely disgusted when I witnessed an elderly gentlemen, a D-Day veteran, begging the French police to be allowed out because he would miss his ferry from Cherbourg. After about 20 minutes he was allowed out, I have no idea whether he caught his ferry. But it made me extremely sad about the disgusting way that people were treated by the French police.

Whilst Sarkozy and Brown were making themselves look important in the town by giving speeches, an elderly veteran — as well as hundreds of others of all nationalities — were being kept hostage in a car park.

After an hour a police van arrived as reinforcements, and it was positioned by the French police to block the exit. For some bizarre reason, some time later, a tannoy announced that only British cars would be allowed to leave. A handful of British cars left; I couldn’t as I was some way back and blocked in.

People were absolutely mad with the French police and could not understand what was going on. On their way out the convoys of Brown and Sarkozy were heckled: furious people shouted, booed, and blew their horns.

All kinds of vehicles are trapped, from vintage military vehicles to cars and camper van

I am very sad that a wonderful day was ruined by appalling planning and implementation.

Configuring Qt with -static is the easy bit, I built Qt with the following options:


chris@thinky:~/qt-embedded-linux-opensource-src-4.4.3$ ./configure -embedded x86 -static -fast -no-exceptions -no-stl -no-accessibility -no-qt3support -no-xmlpatterns -no-phonon -no-phonon-backend -no-svg -no-webkit -no-sse -no-3dnow -no-sse2 -qt-zlib -qt-gif -qt-libtiff -qt-libpng -no-libmng -qt-libjpeg -no-openssl -no-nis -no-cups -no-iconv -no-dbus -no-freetype -qt-gfx-linuxfb -no-glib


Then as I already have Qt 4 installed on my system due to KDE, need to set $PATH to run the correct tools:


export PATH=/home/chris/qt-embedded-linux-opensource-src-4.4.3/bin:$PATH


I decided to modify the t1 example as a test, so I modified the t1.pro file, by adding ’static’ to the CONFIG line


chris@thinky:~/qt-embedded-linux-opensource-src-4.4.3/examples/tutorials/tutorial/t1$ cat t1.pro
TEMPLATE = app
CONFIG += qt warn_on static
HEADERS =
SOURCES = main.cpp
TARGET = t1

chris@thinky:~/qt-embedded-linux-opensource-src-4.4.3/examples/tutorials/tutorial/t1$ qmake -config release
chris@thinky:~/qt-embedded-linux-opensource-src-4.4.3/examples/tutorials/tutorial/t1$ make clean && make
rm -f .obj/release-static-emb-x86/main.o
rm -f *~ core *.core
g++ -c -pipe -fno-exceptions -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../../../mkspecs/qws/linux-x86-g++ -I. -I../../../../include/QtCore -I../../../../include/QtCore -I../../../../include/QtNetwork -I../../../../include/QtNetwork -I../../../../include/QtGui -I../../../../include/QtGui -I../../../../include -I.moc/release-static-emb-x86 -I.uic/release-static-emb-x86 -o .obj/release-static-emb-x86/main.o main.cpp
g++ -fno-exceptions -Wl,-rpath,/usr/local/Trolltech/QtEmbedded-4.4.3/lib -Wl,-rpath,/usr/local/Trolltech/QtEmbedded-4.4.3/lib -o t1 .obj/release-static-emb-x86/main.o -L/home/chris/qt-embedded-linux-opensource-src-4.4.3/lib -lQtGui -L/home/chris/qt-embedded-linux-opensource-src-4.4.3/lib -lQtNetwork -lQtCore -lm -lrt -lpthread -ldl


However, the binary is still dynamically linked:


chris@thinky:~/qt-embedded-linux-opensource-src-4.4.3/examples/tutorials/tutorial/t1$ file t1
t1: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), not stripped
chris@thinky:~/qt-embedded-linux-opensource-src-4.4.3/examples/tutorials/tutorial/t1$ ldd t1
linux-gate.so.1 => (0xffffe000)
librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7fb5000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7f9d000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7f98000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7ea5000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7e80000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7e75000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d2b000)
/lib/ld-linux.so.2 (0xb7fdc000)


Google seems to be out of results, and I appear to be out of ideas, as does the official Qt documentation.

Speaking to a Qt developer (who shall rename nameless to preserve his sanity, although I appreciate his help :), you can configure qmake to make a fully static app by adding the following line to the qmake config:


QMAKE_LFLAGS += -static


After running qmake again, this leads to the following:


chris@thinky:~/qt-embedded-linux-opensource-src-4.4.3/examples/tutorials/tutorial/t1$ make
g++ -c -pipe -fno-exceptions -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../../../mkspecs/qws/linux-x86-g++ -I. -I../../../../include/QtCore -I../../../../include/QtCore -I../../../../include/QtNetwork -I../../../../include/QtNetwork -I../../../../include/QtGui -I../../../../include/QtGui -I../../../../include -I.moc/release-static-emb-x86 -I.uic/release-static-emb-x86 -o .obj/release-static-emb-x86/main.o main.cpp
g++ -fno-exceptions -static -Wl,-rpath,/usr/local/Trolltech/QtEmbedded-4.4.3/lib -Wl,-rpath,/usr/local/Trolltech/QtEmbedded-4.4.3/lib -o t1 .obj/release-static-emb-x86/main.o -L/home/chris/qt-embedded-linux-opensource-src-4.4.3/lib -lQtGui -L/home/chris/qt-embedded-linux-opensource-src-4.4.3/lib -lQtNetwork -lQtCore -lm -lrt -lpthread -ldl
/home/chris/qt-embedded-linux-opensource-src-4.4.3/lib/libQtCore.a(qlibrary_unix.o): In function `QLibraryPrivate::load_sys()':
qlibrary_unix.cpp:(.text+0x307): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/home/chris/qt-embedded-linux-opensource-src-4.4.3/lib/libQtCore.a(qfsfileengine_unix.o): In function `QFSFileEngine::owner(QAbstractFileEngine::FileOwner) const':
qfsfileengine_unix.cpp:(.text+0x838): warning: Using 'getgrgid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
qfsfileengine_unix.cpp:(.text+0x736): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/home/chris/qt-embedded-linux-opensource-src-4.4.3/lib/libQtNetwork.a(qhostinfo_unix.o): In function `QHostInfoAgent::fromName(QString const&)':
qhostinfo_unix.cpp:(.text+0x30e): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking


Not good. It turns out that linking statically to glibc is hard, because getXXbyYY such as getpwuid_r require NSS, which is a loadable module….

Next step is to try compiling Qt against uClibc.

Canon EOS 20D, 100-400mm L, 10 second exposure, f/10.

(click for larger version)

One of those that I found was Ikea’s “Ask Anna”, which is prominently advertised on their home page.

I was curious as to how they handled input validation, so I tested with some potentially objectionable words.

One of the “inappropriate” terms I tested was “dumb”. Unfortunately Anna’s interpretation of this word could be improved, as it’s not appropriate to equate “dumb” with “disabled people” or their carers.

After installation, I installed the NVidia drivers from Windows Update, as well as a couple of other things like Lightroom, DVB Viewer, and the Technotrend drivers. After rebooting the result was a blue screen of death.

The familiar BSOD STOP error: “A problem has been detected and Windows has been shut down to prevent damage to your computer”. “Attempt to reset the display driver and recover from timeout failed.” The error is in nvlddmkm.sys.

This results in the familiar “Safe mode or not” on the next boot…

Update:  9th Feb 2009. WD released a new source code package some time ago (WDTV_GPL_Code.zip version 1.01.02), but it’s still a GPL violation. See below.

Disclaimer: I Am Not A Lawyer, nor do I have expert knowledge of GPL enforcement. I am merely a free software enthusiast and *nix sysadmin.

Unfortunately the WD TV product, by the well known hard disk manufacturer Western Digital, appears to be violating the copyright of various free software projects, including those of the GNU and mtd-tools projects.

Of most concern to the GNU project is that a “toolchain” consisting of a binary-only version of gcc is provided. Of concern to mtd-tools is that the firmware contains a binary version of mtd-tools, but no source code appears to be provided.

Personally I think that it is unacceptable that WD is making money out of violating the GPL, and effectively distributing pirated software. There would be an uproar if WD was using pirated Microsoft software, for instance.

Information

The firmware and “source code” is available from
http://support.wdc.com/product/download.asp?groupid=1001&sid=112〈=en

The first problem is that the “source code” is only for version 1.00.01, while the binary version is 1.01.01.

If you download the firmware and unzip it, you will find the following file:

release-1.01.01/wdtv.bin

This is a cramfs image which can be mounted and examined using the following command:

sudo mount -t cramfs -o loop wdtv.bin -o offset=32 /mnt

(The first 32 bytes are an md5 checksum of the remainder of the rest of the wdtv.bin file).

Findings

* I do not own the product; as such I am uncertain whether it contains a written offer to provide the source code, as required by the GPL

* There are no suggestions or further offerings in WDTV_GPL_Code.zip to obtain the remainder of the source code

* The source code (WDTV_GPL_Code.zip) is incomplete and missing the scripts needed to build the product, which Western Digital are obligated to provide per section 3 of the GPL v2: “For an executable work, complete source code means [...] the scripts used to control compilation and installation of the executable”. There is no way that anyone could turn the source code that WD provide into something that can be installed on the device.

The source code package contains toolchain-89.tgz, which appears to be binary only release of gcc in the form of an ARM cross compiler.

chris@host:~/dock/TVDOCK_GPL_code_package.2008.9.25/toolchain-89$
arm-elf/bin/gcc -v
Using builtin specs.
gcc version 2.95.3 20010315 (release)

Incidentally, I believe that this is NOT the correct compiler at all. The hardware contains the Sigma SMP8635LF, which is MIPS-based, not ARM at all. Additionally, from examining the firmware image as described above, the software appears to have been compiled using gcc 3.0, not 2.95 at all:

chris@thinky:/mnt/bin$ strings ntfs-3g | grep -i gcc
libgcc_s.so.1
GCC_3.0

* The binary firmware contains the utelnetd daemon, licensed under the GPL v2, but source code for this does not seem to be provided

* The binary firmware contains the mtd-tools (mkfs.jffs2 etc), licensed under the GPL v2, but source code for this does not seem to be provided

* I’m not too sure if this is a GPL violation, but the product is supplied with various proprietary kernel modules, which are essential for the functioning of the device.

I believe that there could well be patches to the kernel, but these are not supplied either. Running modinfo on one of the proprietary kernel modules reveals the following:
chris@thinky:/mnt/lib/modules$ modinfo llad.ko
filename: llad.ko
license: LGPL
author: Mambo standalone team
description: llad kernel module for standalone configuration
depends:
vermagic: 2.6.15-TvDock preempt MIPS32_R2 32BIT gcc-4.0
parm: max_dmapool_memory_size:Sets the maximum amount of memory shared by the all dmapools (i)
parm: max_dmabuffer_log2_size:Sets the dmapool buffers maximum size (ex: set 15 for 32kB) (i)
parm: major:Sets the major number (i)
This means that the module expects to load against a kernel called 2.6.15-TvDock, however searching for the string TvDock in the supplied kernel source produces no results. To my knowledge, building a kernel to report itself as “2.6.15-TvDock” would require patching the top level kernel Makefile (e.g. linux_kernel_2.6.15/Makefile), and changing the “EXTRAVERSION” line, yet the string “TvDock” is not mentioned in the entire source code package.
chris@host:~/dock/TVDOCK_GPL_code_package.2008.9.25$ tar xzzf linux_kernel_2.6.15.tar.gz
chris@host:~/dock/TVDOCK_GPL_code_package.2008.9.25$ cd linux_kernel_2.6.15
chris@host:~/dock/TVDOCK_GPL_code_package.2008.9.25/linux_kernel_2.6.15$ grep -ir tvdock *
chris@host:~/dock/TVDOCK_GPL_code_package.2008.9.25/linux_kernel_2.6.15$

I have diff’ed the kernel to a vanilla 2.6.15 from kernel.org and the diff is extensive (18k lines, 664KB) : you can grab it here.

There are various patches mentioned in the top level of the unpacked kernel.
chris@host:~/dock/TVDOCK_GPL_code_package.2008.9.25/linux_kernel_2.6.15$ ls | grep patch
README.0000.shared.patch
README.1000.tangox.patch
README.1001.pci.patch
README.1002.gpio.patch
README.1003.mbus.patch
README.1004.ide.patch
README.1005.tango2enet.patch
README.1006.usb.patch
README.1007.mtd.patch
README.1008.ir.patch
README.1009.fip.patch
README.1010.scard.patch
README.1011.udf.patch
README.1012.fb.patch
README.1013.frequency.patch
README.1014.ipfilter.patch
README.1015.cpucache.patch
README.1016.kmalloc.patch
README.1017.satasil.patch
README.1018.multirecv.patch
README.1019.zbf.patch
README.1020.binary-identity.patch
README.1021.rootfs-integration.patch
README.1022.cacheflush.patch
README.1024.bug.patch
README.1025.ddma.patch
README.1026.gcc41x.patch
README.1028.embeddedrd.patch
README.1032.net.patch
README.1034.ck7.patch
I’m not sure if these patches are in the above diff, determining if that is the case will take a while. Presumably they are in the compiled kernel, so if they aren’t, it may be violating the kernel developers’ copyright too. (One of the authors mentioned in the above files is Craig Qu, who appears to be a Sigma employee.)

Analysis of WDTV_GPL_Code.zip version 1.01.02

The updated released of WDTV_GPL_Code.zip was made in January 2009. It consists of three files: GPL.tgz, TVDOCK_GPL_code_package.2008.9.25.tar and TVDOCK_Project_Source_Code_License_List.doc.

Not much appears to have changed since the previous “source code” release, other than the addition of GPL.tgz.

The appear to have taken onboard my previous comments, and included the source code to utelnetd and mdtools.

It’s interesting to note that there is a smp86xx_toolchain_2.8.2.0, which includes a mipsel uClibc cross compiler. It looks like this could well be the correct compiler, but there is still no source code for gcc. So not only are WD violating the GPL of gcc once, they are now doing it twice, as they are still distributing the binary only arm cross compiler as well.

There are several shell scripts including make_ntfs-3g.sh, make_ntfsprogs.sh, make_utelnetd.sh, make_busybox.sh, make_dosfstools.sh, make_mkfs.jffs2.sh which could be construed as an attempt to distribute the scripts used to build it, but frankly they are an absolute joke.


chris@host:~/GPL/GPL$ cat make_busybox.sh
cd busybox-1.10.0
make clean
make
cd ..


Yes, even this four line script is broken. There is no shebang, and it won’t work if the current directory is elsewhere in the filesystem.

In Summary

WDTV is an amateruish product, and still in breach of copyright law. It’s hard to understand how this passed their legal department.

1. WD are distributing a arm cross compiler without distributing the gcc source code, and the scripts used to build it
2. WD are distributing an mipsel cross compiler without distributing the gcc source code, and the scripts used to build it
3. The scripts to build the project as a whole are still missing
4. It’s impossible to determine what else may be missing/incorrect, due to points 1-3, point 3 in particular

Once the above has been resolved, it should be possible to take the source code and compile the project in its entirety. This should be an exact copy of what is installed on the device, minus the propreitary components. If it isn’t, then something has gone wrong.