I'm assuming HD refers to hardware decode. That is on the Broadcom chip, it just has to be licensed separately. They have it on their web store for 2.40 pounds. http://www.raspberrypi.com/mpeg-2-license-key/

To be fair, I was initially having major problems on the Ethernet and USB ports, but then I switched out the power supply. The one I was using was from my Nokia phone, labeled as 1.5 amp. The one that worked better was the one that came with my Samsung Nexus phone. The problems with the other power supply was that when I boot up, the USB would lock up sometimes if I had both keyboard and mouse, and Ethernet hooked up (along with a bunch of USB errors on the console). None of that with the other power plug.

So what does that say about someone who new what song was linked to, without even checking it out? Just from the context of the comment?

I read an alternate account of that case years later, which changed my opinion a bit. It appears that Seasoft had made source code available for arc, so that it could easily be ported to other platforms (although it was still under a shareware type license). They also had as a requirement that if you modified it such that it made arc files that were incompatible with SEA's arc, that you had to send those modifications to them so that it wouldn't fragment the file format. Now apparently PKarc was based off of the available SEA source, and it made incompatible (embrace, extend) versions of ARC. So those two points were what the lawsuit was about, both the code reuse, and making a product claiming to be ARC but with incompatible file formats. Which is why SEA won.
Now here's the kicker. Both sides were under a gag order while the case was pending. However, a one-sided version of the case was leaked (possibly by a PK employee), which made it look like SEA was being the bad guy. And they couldn't respond, due to the gag order. And this happened about the same time as the various Look and Feel lawsuits (Lotus 123 vs. Paperback Software, , Apple vs. Microsoft, and a couple others I can't recall). So of course PK got the sympathy of the BBS community. The first thing PK did was change the extension to "pac" and the name of the program to "pkpak". Then he made a new format "zip", and the BBS community converted overnight. By the time SEA was able to tell their side of the story, it was too late.

Of course, it's been a number of years since I read that account, and even longer since the original events, so most of it is paraphrased. But if needed, I can probably dig up the magazine articles that had the details.

On first glance, they are close enough where it looks like the Open Hardware group is a subsidiary of OSI (that is, once you interpret both logos as a stylized keyhole). And that may actually be the solution -- the two groups should join up, with a stock swap or something like that.

For those that don't know how ssh-agent works:
You have two parts to your key, one part encrypts only (public key) and the other part decrypts only (private key). The remote server sends a random message encrypted with the public key; that message is sent to the ssh-agent program, which decrypts the message with your private key which it has in memory. This decrypted message is sent back to the remote server -- if it matches what it randomly generated, it know that your are in possession of the private half of the key and lets you in. The secure part is that your private key is never sent over the wire, and never leaves the memory of the ssh-agent program (unlike a regular password).

Now one thing I've done in the past to make this more secure (when I carried a Nokia N900 linux-based phone) is I ran the agent on my phone only, and forwarded the connection to my PC via Bluetooth. I had it set up so that it would auto pair with PCs that I trusted (and play a particular sound on the pone during pairing and key usage), and require an accept button on the phone for other machines. I've been meaning to pick up Android programming so that I could port this over to my current phone. Oh, and when the agent program gets started on the phone, it requires a symmetric decryption key (protects it if the phone is stolen). Probably security overkill, but in my case I used it more for convenience than anything else.

My main problem is that when I'm writing something down, I miss what is being said next. Always had that issue. But I can type and listen at the same time, no problem. Maybe learning shorthand would help though.

A number of years ago I was developing for some Linux based PDAs (Sharp Zaurus), and the main issue I had with cross compiling was that a package's "configure" script would inspect the machine it was running on, so wouldn't produce proper configs for the target platform, among other similar issues. So what I did then was run the builds on the target platform, but use distcc so that it would shove over the pre-processed C files over to my main host to cross compile. The resultant binaries were identical to what was compiled natively (since the header includes and other preprocessing, and linking, was done on the target hardware). Looking around, this appears to be the exact method that Arch linux uses. Would something similar work for you, or do you find that GCC still produces invalid executables in a cross compiling setup using the same input you would have on the native hardware? If this would work, then would it also be faster to run your builds completely on a PC using Qemu/arm (along with distcc)?

First, there is inexpensive, and then there is lunch-money inexpensive. Once you get to the price of a couple $20 bills, it becomes an impulse buy, no need to budget it.
Second, size / heat / power draw are big issues (no fan).
Third, unlike many other ARM-based devices, this one boots directly off the SD card. So it makes it much harder to "brick" than, say, re-purposing a home router with a Linux distro. And, most of the other similar type devices don't have video / audio out, so they are only suitable for network use or as an embedded controller.

As for what projects I'm using this for:
1) Simple NAS type device to dump backups to -- I have a network based backup daemon running on it with a restricted protocol, which makes it very resilient to being attacked by malware on other boxes that I'm backing up.
2) My parents have an LCD TV in their kitchen -- I am planning on hooking one of these up so they can use it as a kitchen computer (wireless keyboard, look up recipes, play card games, etc).
3) Also, I can give one to my Dad to hook up as a spare computer, that would allow him to click on anything without getting into trouble (one of his friends is always forwarding stuff, some of which may link back to a drive-by download site).

I actually had gotten to an order page a while ago, this was way after the initial rush. Placed the order (Element 14) in April, and just got it last Friday. I also got an invitation to order it from RS about a couple weeks ago.

Even better is if it is a Firewire device -- from what I've read, Firewire gives all kinds of direct memory access to stuff plugged into it (it is a system level bus). Even more so for PC-card (pcmcia) devices.

I think that is mainly to raise public awareness that there is a treatment for the condition that they are experiencing (or don't know that they have), and it gets them to actually go see a doctor. Believe it or not, quite a few folks just don't go to a doctor regularly.

From my experience, when a talk page starts to get a lot of activity, an admin will install "MiszaBot", which is an automatic archiving script that archives discussion threads older than 90 days. I just checked this article's talk page, and it looks like the whole discussion is still there in the archive 3.

I just need one with a timer on it. One time I was cleaning up my computer desk, and almost burned myself on a (cheap Radio Shack) iron that was still plugged in... from a soldering job I did 3 days prior. Oops. Needless to say, the tip was pretty much ruined on that one.

This is one of the things that a lot of people have a hard time understanding about space travel / orbital mechanics. The analogy I use, is let's say you throw a baseball on the interstate, intending it to land in the bed of a specific pickup truck. Now half way through the ball's flight, you find out that it needs to go into another truck traveling in the opposite direction, and the only thing the ball can do is eject pieces of itself in order to change it's direction / velocity. Well, it ain't going to make it. So that is why the Columbia shuttle couldn't dock with the ISS, even if the damage was known about.

However, one thing it could have done is fly in using a trajectory which put more stress on the good wing, until the vehicle reached an altitude in which the occupants could safely eject. But that was only speculation on NASA's part, no guarantee that it would have worked. But an inspection would have at least left it as an option.