It doesnt matter if those countries get 100 bucks if 99 of them end up going back to cost of manufacturing.

Part of "cost of manufacturing" is paying workers. There and here. So it does matter. When my $100 goes there instead of here, our economy takes a hit. Tiny, sure, but when it's thousands or tens of thousands or hundreds of thousands of "whatever", then it's no longer a tiny hit.

That remark was hackneyed.

Ultra mobile? I don't think I've ever seen it in that configuration. It's in the same space as Intel's Atom, but unlike the Atom, AMD doesn't try to artificially segment the market too much so you can actually buy one with enough SATA slots for a NAS.

LinkedIn was ever relevant? I've had a lot of spam from them (even though I never joined or gave them permission to contact me), but I'd never consider using them to find people to hire (or to find work, back when I was looking).

Define 'proper'. Re-randomisation after every fork()? Good luck with that. PLTs at random offsets? Sure, if you're willing to pay the overhead of not being able to share any position-independent code between processes.

Depends on the AMD chip. I have a box that serves as a NAS and HTPC with an AMD Fusion E-350, which is one of their lower-power chips. Maximum power consumption is 18W for the CPU and GPU. The GPU works fine for decoding HD video (on FreeBSD, presumably it's as good on Linux). It's now around 4-5 years old and the only reason that I'm considering replacing it is that the motherboard can only handle 8GB of RAM, which isn't enough for ZFS deduplication with a 12TB pool.

True, although most password managers can generate random passwords (of varying strengths, as a recent Oakland paper showed). Using this functionality is generally easier than thinking up a password.

JavaScript can also intercept the contents of the clipboard. If you're blocking password managers, then people are going to do one of two things. Either they'll pick a (weak) easy-to-remember password, or they'll use a password manager and paste the password in. If they opt for the latter, then any malicious ad on the page can grab the password while it's in the clipboard...

I think that you're slightly missing the grandparent's point. About 10-15 years ago, there were two groups pushing new directions for the web. One group, led mostly by the W3C (though backed by Apple and a few other big companies) wanted to completely separate content and presentation. You'd have a service that would provide structured XML and then a web page or a native app that would process it and present it to the user. This would make it easy to write programs that aggregated data from multiple sources (e.g. find bus, train and flight times and prices so that you can find out the cheapest or most convenient route from A to B, including getting to and from different airports).

The other faction, led by Google, wanted to completely destroy this separation and make web pages into rich web apps that would ensure that you could only view the content in exactly the form that the authors intended. The main goal of this was to make it hard to distinguish content from ads and therefore make it hard to automatically remove ads.

Unfortunately, the second group mostly won. The grandparent seems to want people to go back to the other approach and present machine-readable data feeds so that we can then have rich client-side apps that are agnostic to the source, but present the data as the user wants. I'd like that too.

The only problem is that you may forget to turn off blocking of whatever analytics spyware they're running, so they won't get feedback that you only stayed on the page for a few seconds before leaving the site.

Read this paper if you want to know how easy it is.

PC-BSD occasionally picks some patches to apply on top of a stock FreeBSD, but they try to keep it fairly small. I suspect that they're unlikely to pick up these for several reasons. First, there are still some random segfaults in applications caused by these patches that are not yet diagnosed. Second, the HardenedBSD team doesn't have a great track record for security, for example merging some insecure random number generator patches that were under review for FreeBSD and rejected over security issues and shipping them in production. Third, since the Blind ROP work from Stanford, ASLR is largely discredited as a security feature - it's a nice checkbox feature, but it doesn't really buy you much against a determined attacker. Fourth, the last iteration of the patches still had some very odd decisions about the interfaces for turning ASLR on and off (they also had a number of lock-order reversals, which are hopefully fixed in the latest version).

This. A thousands times this. Should be modded to positive infinity.

How do you get shell access on your average Mac without physical access? SSH isn't enabled by default as has been pointed out. In fact, it's been a real PITA to get the versions of OS X I've configured to play nice on the network for the command line. I doubt one user in a thousand has done it -- slashdot mac users not being significantly representative of the average mac users, of course. My macs have SSH available, but the port isn't open to the Intertubes outside of my LAN, so it doesn't concern me very much.

So this essentially resolves to a "you have to be there" exploit.

Exactly so.