Just in case you haven't already read about this... Some researchers from Princeton have published a paper about methods which can be used to attack full-disk-encryption (FDE) schemes.
They have demonstrated that at least BitLocker (Windows Vista), FileVault (MacOS X) and dm-crypt (Linux) are vulnerable to this type of (partly hardware-based) attack scenarios. Quite likely lots of similar other solutions are vulnerable as well.
The main problem is that (contrary to popular belief) RAM does indeed retain its data for a non-trivial amount of time after power is cut (seconds, even minutes or hours if it's cooled down enough), so you can mount some new attacks such as:
Yes, all attacks assume that the attacker has physical access to your PC/RAM, in which case you already have several other problems. Still, the new thing about this is that even full-disk-encryption doesn't help much in some cases. You probably shouldn't depend too much on it (but you shouldn't stop using disk encryption either, of course!).
Make sure to read the comments of the various articles for more scenarios and possible ideas for how to prevent such attacks. Some ideas include enabling the BIOS RAM checks (which might explicitly erase RAM contents on reboot; that doesn't help in all cases, though) or using coreboot (previously LinuxBIOS) to erase RAM contents at boot-up and/or shutdown.
It's a highly non-trivial issue, though, there's no easy and complete fix so far. The only sure way is to not have your laptop or PC stolen and to not give attackers physical access to your computers.
The old name has become quite a misnomer in recent years; the name LinuxBIOS created the impression that it's a drop-in BIOS-replacement and that it's using Linux or is Linux-specific in any way. Neither is the case.
If you're into such games, the Lincity clone has been around for some time now, too. And, as I found out yesterday, there's also Lincity-NG, which is a more recent clone with better (3D/isometric) graphics, sound, etc.
$ apt-get install lincity-ng
(run it as lincity-ng --sdl if you don't have 3D-accelerated drivers)
Very nice tool I recently discovered: ink, a small tool using libinklevel, used to query the ink level of your printer (USB or parallel). In my case this is an Epson Stylus DX4200 (which works very nicely and out of the box btw).
$ apt-get install ink
$ ink -p usb ink v0.4.1 © 2007 Markus Heinz EPSON Stylus DX4200 Cyan: 76% Magenta: 76% Yellow: 76% Photoblack: 72%
Graphical ink level display:
$ apt-get install qink
Another nice tool built upon libinklevel is called qink, which is a QT-based GUI which displays the same information graphically (see screenshot).
A list of printers supported by libinklevel is available.
Since the "World's First Motherboard Using LinuxBIOS Released" hype at the beginning of this year (which was incorrect btw; it was not the first supported desktop board, there were many others before), LinuxBIOS hasn't been in the news very much. That doesn't mean that there was no progress, however. We've been working hard behind the scenes to improve the LinuxBIOS code, add support for new chipsets and boards, and advance the upcoming next-generation LinuxBIOSv3 version which will brings lots of great improvements in various areas.
Here's a random collection of stuff that happened in the last few months.
Most work will probably go into LinuxBIOSv3 in the future, in order to make it suitable for productive use.
Of course, work on new chipsets and boards will continue, too. For example the VIA CN700 chipset (plus Jetway J7F2WE board using it) is being worked on right now, probably also several others I don't know about.
If you're interesting in trying out LinuxBIOS, please check the list of supported motherboards. If your board is not listed there, but the chipset is already supported we can probably add support for your board relatively easy with some testing help from you.
An (incomplete) list of good candidate boards for future support is available in the wiki.
We're very grateful for the many contributors who have helped us with testing and fixing existing code, or who even contributed code for new chipsets and motherboards. Thanks a lot!
Many thanks especially to all hardware vendors who have been supporting us or even actively contributed by submitting code for their chipsets or boards (recently or in the past), including AMD, SiS, VIA, MSI, Tyan, Artec Group, and many others. Your efforts are very appreciated. Thanks!