You have the client you are backing up push the backups to the backup server via SSH, instead of the backup server remoting into you client to pull the files. This way you can deposit the files into a restricted account on the backup server.

The only problem is that when I buy a motherboard / CPU, there are usually a dozen or so variations on which CPU will work in a given motherboard. Right now it makes sense to mix & match to get exactly what you want, but if the CPU is attached to the motherboard at purchase time, you are stuck with one of the 2 - 3 choices that the motherboard manufacturer decides to sell.

Deep frying a whole turkey makes it come out extremely juicy -- it doesn't have that "fried" flavor or taste. Cooking in the oven gets you a bit dryer turkey. What happens is the hot oil sears the skin, trapping the juices inside. Usually you inject them with a butter based solution, seasoned with various spices, and that gets embedded into the turkey meat. Oh, and when you inject the bird, first figure out which way you are going to position it in the pot, and make sure the injection holes are at the top (try to reuse the same injection site, and with different angles / depths), so that the juice doesn't run out into the oil when cooking.

And yes, the first time I had seen this done was in Arkansas. But like I said above, it doesn't come out greasy or anything like that.

The big difference is that Lenovo makes their own laptops in their own factories -- whereas all the others make them at an outsourced factory. And I don't care where the factory is, quality always seems poorer at an outsourced plant.

When you write for iOS, you aren't working for yourself. You are instead working as a contractor for Apple. You are given the job of coming up with product ideas, implementing and marketing them. And you get paid a hefty commission on the sales. But as an Apple contractor, they are free to reject any idea or implementation thereof -- it has to be in line with what they would want to develop themselves.

If you think of it this way, it makes things so much easier.

The problem with anti texting laws is the law of unintended consequences. Instead of holding the phone up higher where someone could see the phone and traffic at the same time (and where a cop could see), they now put it in their lap and take chances. And worse punishments don't always reduce infractions.

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).