Note: This article is part of my Testing stuff with QEMU series.
From the Debian GNU/kFreeBSD port page:
Debian GNU/kFreeBSD is a port that consists of GNU userland using the GNU C library on top of FreeBSD's kernel, coupled with the regular Debian package set.
Q: Why would anybody want to do that?
A: Why not? 
So, after we have talked about that, let's start:
apt-get install qemu
qemu-img create -f qcow2 qemu_kfreebsd_i386.img 5G
qemu -boot d -cdrom debian-20070313-kfreebsd-i386-install.iso -hda qemu_kfreebsd_i386.img
ALT-F3. Do it.
At the end you must select "No" as you're told to do, then reboot via "Exit Install". You can then shutdown QEMU.
qemu -hda qemu_kfreebsd_i386.img
apt-get update && apt-get dist-upgrade
apt-get install vim xorg icewm xterm
apt-get install kbdcontrol
Section "InputDevice" Option "Device" "/dev/psm0" Option "Protocol" "PS/2" [...] Section "Device" Driver "vesa"
Both kfrebsd-i386 and kfreebsd-amd64 seem to be reasonably stable already (and more than 70% of the whole Debian archive builds fine on these architectures, see kfreebsd-i386_stats and kfreebsd-amd64_stats). I'll quite likely install kfreebsd-amd64 on one of my boxes soonish and start using it, maybe I'll even find some time to fix/patch/port some packages...
 More elaborate answer(s) and reasons are available in the Debian wiki.
Many online video sites such as Youtube, Google Video, Dailymotion, Metacafe, and others only provide limited or inconvenient access to the videos; either they require you to install the proprietary Flash player (and I surely won't do that), and/or you can only view them online (but not download them).
There are some solutions, each with advantages and disadvantages:
After the download, you can either view the videos using (e.g.) mplayer, or recode them into a more sane format. For all of the above programs there are Debian packages available, except for VideoDownloader/UnPlug (but you can easily install those from within Firefox).
Update 2007-07-26: Added UnPlug and swfdec (thanks Joe Buck and Josh Triplet for the comments).
This is really sad in my opinion, as we should rather support more architectures instead of less architectures. After all, Debian is "The Universal Operating System" .
Now, I know that my opinion doesn't matter much in this case, but many other people who own sparc32 boxes seem to feel the same, judging from the thread which was started by the announcement.
Also, I do realize that nobody wants to retire the port just for fun. To my understanding there is one major problem which needs to be sorted out in order to "save" the sparc32 support in Debian (and also in Linux!):
There is no Linux kernel maintainer for the sparc32 Linux code at the moment!
This seems to be the root of the whole problem. It makes maintaining a Debian port for sparc32 really hard, as you can surely imagine. Also, there seem to be too few people who actively work on the surrounding toolchain stuff (gcc, binutils, etc) which is also very important.
My suggestion would be to not drop the Debian support for now, but rather set the status to "needs help" or something and actively search for contributors and/or maintainers. Heck, list it on Unmaintained Free Software, or write a "call for help" Slashdot article, post the issue on all Linux-/Debian-/SPARC-related mailing lists etc. etc. (or write funny blog posts, heh).
I guess if two or three experienced SPARC developers would step up and take care of the kernel and toolchain maintenance for sparc32, there would be no reason to drop it anytime soon.
There are a gazillion HOWTOs out there for flashing a BIOS image without having to resort to ugly "boot DOS from floppy" or "run Windows *.exe file from BIOS vendor" and other ugly stuff. Unfortunately, the proposed solutions are equally ugly (e.g. creating custom CD-ROMs which contain the "floppy" with DOS/Windows flash tools).
Folks, this is so much simpler than you think:
The flashrom tool (GPL'd, written for LinuxBIOS purposes, but works perfectly fine with proprietary BIOSes, too) will easily do what you want, on a running Linux system. No floppy crap, no CD-ROM crap, no DOS/Windows crap, no rebooting crap.
$ apt-get install flashrom
Detect whether flashrom knows about your chipset/mainboard/BIOS chip:
Read the BIOS image into a file:
$ flashrom -r backup.bin
Write a BIOS image (proprietary or LinuxBIOS) on the ROM chip:
$ flashrom -wv newbios.bin
WARNING: This will overwrite your current BIOS! Make sure you know what you're doing!
For the Debian-challenged, flashrom is available in source form too, of course:
$ svn co svn://linuxbios.org/repos/trunk/util/flashrom $ cd flashrom $ make
The list of supported chipsets, mainboards, and ROM chips is limited of course, but it's constantly expanding. Contact us on the LinuxBIOS mailing list if you want other hardware supported (or even better: if you have patches!). In many cases adding support for new hardware is pretty easy...
I haven't yet read the licenses in detail, so I cannot say much about them, but more information is available in the (updated) GPL FAQ. The compatibility table from the GPLv3 Discussion Draft FAQ can be pretty helpful, too. There's a Why Upgrade to GPLv3? text and even a video of Richard Stallman (Ogg Theora, transcript available) introducing the GPLv3, the rationale behind it and some of the changes in this new version.
(One nice advantage of the GPLv3 I like is that it's compatible with the Apache license now, btw.)
Probably the most interesting GPLv3 resource at the moment is Palamida's list of projects which already switched to the GPLv3, which includes a number of GNU tools (sed, tar, ed, bison, texinfo, cpio, coreutils) and some other major projects such as Samba. Currently the page lists ca. 140 projects which switched.
It'll be interesting to see how the adoption proceeeds. My guess is that in a few months it'll be hard to build distributions or embedded (GNU/Linux-based) hardware devices without GPLv3 code...