Edoofus blocked by the Government of India

Against stupidity the gods themselves contend in vain.

-- Friedrich von Schiller

(For those of you who are wondering this post is about: at the time the post was written, the Indian government had forced Indian ISPs to restrict internet access to all the blogs under the blogger.com domain. The rationale for this edict remains unclear, even today.)

Robert Watson: "How FreeBSD Works"

An excellent summary of the FreeBSD project, by Robert Watson: http://www.watson.org/~robert/freebsd/2006bsdcan/20060512-bsdcan2006-how-freebsd-works.pdf

D-Link

In 2005, I had the opportunity to visit D-Link India's development office in Bangalore. I found that they were using Linux on a few routers that they were developing. This surprised me since I had not found mention either of Linux, or for their obligations to their customers under the GPL, on the main D-Link website. My understanding of the GPL was that GPL-derived binaries need to be accompanied with a prominent offer of source code. Most companies that use Linux for embedded work just put their sources up on the web.

The matter got stranger. In response to a direct question, the VP of Development (at Bangalore) indicated that he didn't think that they needed to make the Linux source code that went into their products available to their customers. I didn't have the opportunity to ask why he thought that the GPL didn't apply to his product line. I do know that some D-Link routers are Linux based and that you can find GPL'ed source tarballs for these by assiduously googling for them. However, it is not clear to me whether source code is available for all of D-Link's Linux based routers and whether the provisions of the GPL are being correctly honored by this company.

And now, there is the news that D-Link's routers have been abusing NTP by directly connecting to Tier-1 NTP servers around the world, in violation of the way NTP is designed to work. The Slashdot thread on the topic revealed a few interesting tidbits:

• D-Link's products had previously affected the free DynDNS service. This anonymously posted comment is particularly revealing: instead of taking time to fix the bugs in their code, D-Link apparently invested energy to work around the restrictions placed by DynDNS.org (this should be easy to verify).
• Another comment expressed frustration at the D-Link/India firewall :) used to protect management from customer feedback.

The impression I came away with after going through the material on the Internet is that D-Link, as a company, gives short shrift to the network of gentlemen's agreements that hold the internet (and modern society) up. They have demonstrated that they are not above abusing a free service if they can find one, and if the anonymous poster's information is correct, that they are willing to work-around technical protective blocks with impunity. They use GPL'ed code without honoring its copyright fully and completely.

Whether this attitude arises due to malice or due to plain incompetence is not clear yet. Either way, this is one company whose products I'm personally going to avoid in the future, following the principle of giving my business to the least sucky corporation that I can find.

New Indian BSD developer

India now has another BSD developer: Cherry G. Mathew <cherry at netbsd dot org>. Cherry is porting NetBSD to the ia64 architecture.

Congratulations, Cherry!

hwpmc as a basecamp project

I'm trying out Basecamp as a communication/project management tool for hwpmc work.

37 Signals, the company behind Basecamp, uses FreeBSD servers to host Basecamp.

Embedded Space

The past few weeks I've been hacking a small MIPS-based router, getting a glimpse into the workings of the embedded 'Linux' world. This is life at the edge of chaos: open-source, yes, but nearly bereft of sane software development practices. The FreeBSD world is so much nicer:

• I found FreeBSD to be an excellent platform for development. The tools I needed were already part of the FreeBSD ports collection, and building applications via ports allowed me to tweak their configuration as I wished (e.g., make WITH_PYTHON=1 WITHOUT_PERL=1); a future port upgrade would preserve such settings automatically. User interaction remains smooth and glitch-free even running large compiles in the background.
• Cross-development in FreeBSD is straightforward to get started off with ...

  # cd /usr/src # make buildworld TARGET_ARCH=other-architecture # make buildenv TARGET_ARCH=other-architecture

  and in one fell swoop one has a cross-compiler, standard libraries, and all the standard utilities synchronized with the kernel and ready for use. This is very different from the typical 'Linux' project where one has to do a lot of work to reach this point.
• Then there is source history for every file in the base system. Figuring out "what changed?" isn't an exercise in frustration, scanning a myriad diffs and rummaging inside terse changelogs.
• Similarly, is no need to go hunting on the 'net for the current version of common utilities, hoping that these would work with today's cross-toolchain and patch set. Most of the common utilities that one needs for an embedded product are part of our base system—code and have recieved a fair degree of testing on our supported architectures, the i386, sparc64, arm, amd64, powerpc, ia64 and the alpha. For 3rd-party tools too, patch management is easy with FreeBSD: if a FreeBSD port exists for the application then a

  # cd PORTS-DIR && make patch

  would give you source code that is (a) patched to compile on FreeBSD and is (b) upto-date or close to upto-date.
• Tracking security vulnerabilities is straightforward on FreeBSD, both for the base system and for 3rd-party ports.

It was sobering to realize how much we FreeBSD folk just take for granted.

I also now understand how embedded Linux vendor companies manage to charge hefty sums for their embedded OS offerings. If I were a manager charged with implementing an 'embedded' Linux device, I would pay too. The risk of a project slipup because of some bizarre interaction between lightly tested upstream source bases is all too real here.

There are a number of ways by which FreeBSD could be made even better for embedded development:

• It would be great if we could cross-compile 3rd-party applications as easily as we do the base system today. A general fix is probably hard, but there are ways to get the near ubiquitous "configure" shell script to handle cross builds reasonably well.
• We need a way to quickly cobble together complete system images (kernel, configuration files, basic utilities, 3rd party tools) for common target platforms. For example, what if we could say ``I'd like an image from the RELENG_6 branch suitable for a Linksys WRT54GS clone, with pf and sshd from the base system, and clamav and smtp-proxy from ports and with the following local patches'', and have the system churn out a flashable image? The NanoBSD and PicoBSD tools are a start in this direction.
• We need our system analysis and performance measurement tools to be truly cross-platform and embedded development friendly. For example, it would be cool to be able to run gprof on an AMD64 platform to analyse profiles for ARM binaries. It would be useful to be able to take kernel core dumps over the network and have seamless cross-architecture kernel debugging over a local LAN.
• Multiple implementations of system functionality would be useful (e.g., some embedded applications could benefit from a less profilgate malloc(3) implementation that the default).
• Documentation on scaling FreeBSD down would be useful to new adopters. Right now this knowledge is scattered in our list archives.

It would be great to see FreeBSD running on more embedded & resource constrained platforms.