DVB-T transmit in pure PC software

I recently discovered this paper about Soft-DVB, a full PC-software DVB-T transmitter, it apparently is now possible on a 1.8GHz Celeron M based system to do a full software encode/modulation of a MPEG2 transport stream onto a DVB-T compliant carrier that can be received by off-the-shelf consumer DVB-T receivers. And all this on Linux, using gnuradio and the USRP.

This is really great news, and an incredible achievement by the authors of the software, particularly Vincenzo Pellegrini.

There is one (at this time still) moot point, though: The code has not been released yet. It has been demoed at SDR related conferences, so it really exists. Vincenzo has announced on the gnuradio-discuss mailinglist that eventually it will be public - without stating some kind of date, though.

I suppose he probably has to wait until his master thesis has been finalized and approved. That should be in the order of months, not years...

Nokia, FOSS, SIM Locks, DRM and the universe + Motorola's failure

As Bruce Perens points out at this blog entry, it is very much possible to design a product, particularly an embedded Linux device such as a mobile handset with all the usual bits and pieces (DRM for mobile media content, SIM locks, etc.) while preserving the freedom of Free Software.

I'm really pissed off by the kind of FUD that big vendors try to spread about it. There are so many claims that the user has to be locked down, that he cannot be allowed to modify/replace the Linux kernel or other bits of the software stack, etc.

I can only agree full-heartedly with Bruce's article. Such claims are all bullshit. I've worked for a long enough time with Free Software, the Licenses involved, the legal framework of those licenses (Copyright Law), the Hardware Industry, lately even a mobile handset manufacturer. I've seen the software and hardware architecture of a number of phones myself by reverse engineering. Never have I found any reason why the bright-line philosophy (see Bruce's article) should not result in a perfectly working, all-interests-satisfied solution.

Let me use this opportunity to point out my disappointment at the failure of Motorola to solve this problem properly. Instead of designing their MotoMAGX family of handsets in a way that preserves the freedom of the Free Software [community, users] and protects their valid business interests, they chose to go the easy shortcut of walking borderline on what they think the GPL permits them: They use cryptographically signed kernel images, a bootloader that only accepts binaries signed by them, plus a kernel that only accepts signed modules, plus a SELinux locked-down userspace that is very restrictive on what userspace programs can still do.

This would all be nice and good _if_ they were to provide the user with a way to either sign his own kernel images with their key, or (better) to store his own signature in the bootloader. So the hardware would accept Motorola-signed kernels and kernels signed by the user (actual owner!) of the device.

The further proprietary bits of the software stack required for DRM protection can simply refuse to operate if not run under a Motorola-signed kernel. Especially with TPM's and similar technologies becoming more widespread in the mobile world, there is a very straight-forward solution to this problem. The bootloader can store the hash of the kernel image in some TPM protected register, and the proprietary DRM system can refuse to operate if the hash is not the original one.

With regard to SIM-Lock, Operator-Lock and all the other locks: As Bruce points out, those are restrictions of the GSM/3G modem. All implemented in the firmware of this device. It doesn't matter if you run Windows Mobile, Symbian, Motorola's own locked-down Linux kernel or a custom user-built Linux kernel on the application processor. The various GSM/3G related locks are never implemented on that processor, but on the baseband side.

I hereby challenge the mobile industry to come up with hard, technical fact about what particular problem they have in designing open, FOSS-compatible devices, where every user can modify and/or replace the FOSS programs, while ensuring the integrity of their DRM, IPR, SIM lock and other business model related technologies. I will sit down and look at any such issue brought forward and I'm extremely confident that for all of such problems there's a straight-forward technical solution (bright-line in Bruce's terminology) which will not require the proprietary or FOSS side to make any sort of moot compromise.

If not only for the reason of legal safety and security, such solutions should always preferred to going borderline with FOSS licenses or against the FOSS developers and users community!

Persistent Google recruiters suck

I think I've read this before by one or the other Linux/FOSS developers blog: Googles persistent recruitment sucks. At least I've spoken with a number of well-known developers in the community, and they all have been contacted before.

What makes the situation even more difficult is that there are apparently different recruitment teams, so sometimes they want to hire you in Australia, sometimes somewhere else. I've heard rumors that they now have a company-wide blacklist, and I've asked a number of times to not receive further recruitment mail, so I should be on that list by now.

The worst message arrived today. The particular recruiter actually _knew_ that the same department had last contacted me six months ago, and that I was completely not interested. But she was hoping that by now my mind or my job situation had changed, and that she would want to talk to me about employment options at Google.

I'm now really running out of options. I've tried to state it politely a number of times over many years that I am not interested and do not want to receive further emails. As if this wouldn't occur to me automatically, given their omnipresence in the Internet world, and their numerous previous recruitment mails, even in the case I actually was seeking employment now.

I guess I will have to try to be rude now, maybe then they think my personality wouldn't fit the company spirit. I don't know.

Just let me say that this kind of aggressive recruiting is in itself alone reason enough for me to not want to work for this company :(