Because Bitcoin was founded on ideas of economic illiterates who at least halfway believed the gold standard bullshit that these days is most associated with Ron Paul and his ilk of political grifters. Bitcoin or any other "hard" currency is limited to a niche role in any economy where fiat currencies controlled by reasonably sane governments dominate. Ever since Gresham figured out that inflated currencies win, mild to moderate inflation has been used both intentionally and accidentally as a facilitator of real economic growth that isn't bound by the supply of a commodity (e.g. gold) or of people. If one listens to charlatans and demogogues on monetary issues, one might well believe that a "strong" currency is a "good" one, but that is only true for people hoarding it or lending it to others. With the core concepts coming out of the naively paranoid Anarcho-Libertarian and Objectivist influenced 'Cipherpunk' community, BTC takes the idea of a "hard" currency to a whole new absurd level by designing in deflation consciously. No evil government will ever be able to inflate away the BTC-denominated wealth earned by the unshackled titans of capitalism who seem to "earn" it by making huge stacks of video cards do cryptography...

You are either sadly mistaken or quite literally correct.

BTC might not be an intentional scam, but I wouldn't even bet a deflating Bitcoin on that. It is "truly exceptional" in that nothing else quite like it has ever been done before. It is "fantastic" in the sense that its proponents (sadly including /. editors, apparently) seem convinced of the fantasies that electronic transactions are somehow less traceable than physical ones and that hard currencies have some advantage over soft ones for their users.

The /. headline I'm waiting for: "Immortal Vampire Robot Zombie Unicorns From The Planet Nemesis Accept Bitcoin As Ransom to Survive 2012!:"

With the caveat that US courts will not enforce specific performance of contracts where a payment is specified in non-US currency. Whether a court would enforce a barter contract for BTC is an interesting question, since BTC are not recognized as currency by much of anyone yet a contract requiring payment in BTC implies that the parties recognize them as such. My guess is that most judges would take one look at a BTC contract and take the easy way out of voiding it. Until someone with the dollars needed to push an appeals process has a suitable case, the big risk of BTC is not knowing whether any court ever will recognize them as the basis for an enforceable contract.

I don't disagree at all with your overall point, but as a practical matter here you are wrong. As it turns out, most human brains have a threshold at 7 items. Below that the difficulty of remembering a sequence of items grows linearly with a very low slope (i.e. remembering 7 numbers is only slighly harder than remembering 6) but past that it gets hard parabolically, so much so that most people will find mental ways to break up any series longer than 7 into parts. You don't really remember a 10-digit (NANP format ) phone number, you remember the 3-digit area code and the 7-digit local number, which most people probably break into 3+4 . If you are remembering a 12-character password your brain will break it up into at least 2 pieces, both of which should be rather random (unlike phone numbers) and containing more than digits. However you do it, the same number of 12-character passwords will be harder to remember than 10-digit numbers.

1. NTLM hashes have not been deemed a safe way of protecting passwords for many years.
2. If you use NTLM hashes for password storage and a blackhat has the freedom to run a GPU cracker on them, you've almost certainly already lost whatever those passwords protect. The only advantage in cracking them would be to try them on other systems.
3. Sure, 5, 6 and 7 character passwords are trivially cracked. The headline reference to "strong passwords" cannot refer to that fact. A short password is a weak password, and that has been known for a long time.
4. The fastest way to strengthen passwords is to add length, not to expand the element space (as suggested in the referenced article.) To make an 6-character password limited to the base64 ("email safe") character set 64 times harder to guess, i.e. to add 6 bits of variability, just add a character of length. To do that by broadening the character set, you'd need to add a bit to each character, i.e. find another 64 available characters.

Bottom line: Want a strong password that you can type anywhere? Make it 12 mixed case letters, numbers and at least one punctuation mark. Based on the times claimed in the article, that should take 35,000 current GPU-cracker-years.

Bad math. My factors were too low. 2 more characters from a 64-character space (as implied by the examples) would multiple the guessing difficulty by 4096, 4 more by 16M, and a 12-character password would occupy the claimed GPU for 35ky.

Not useless, but do the math. A printable ASCII character space can be typed almost anywhere, and gives you about 6.5 bits of variability per character. The cases described in the FUD of the article are all assuming limits on the length of passwords shorter than 8 characters, but they don't hide the fact that lengthening the password (or in fact, just allowing longer passwords) gives pretty good protection rather swiftly even with a fairly limited character space. At 6 bits per character, 2 more characters means about a factor of 2k in time to guess, 4 more adds a factor of 4 million. Based on the numbers in the summary, a 12-character password will take that GPU well over 8 millennia. That's not a meaningful number, but it is well past any rational threshold of being easy to crack.

No need to do that. Killing a domain only requires changing the registry-level zone file. Also, as a legal matter the traditional gTLD's registries operate under a contract with the federal government. Simply put, the feds own .com, .net, .edu, .gov, and .org. so they could rather easily and effectively knock domains out of those zones if they wanted to work that way. As for the roots, they wouldn't ever need to seize anything, they just (at worst ) might need to get a new root zone deployed if they wanted to kill off an incumbent TLD authority. And yes, that would be a mess...

However, it is worth a few minutes to look at Kaminsky's paper, because it describes what the bill is apparently defining as the mechanism of action against specific names: filtering and redirection at the ISP level on the resolver side, not logical seizure of the domain on the authoritative side. That is a positively stupid approach to killing a domain name. Looking at the bill myself, it seems to me that there is a huge gap built in because it requires service of court orders to every DNS resolver operator being asked to do the filtering and redirection (that would be quite a "jobs program"!) and includes language that provides obvious grounds for just telling the feds to stuff their orders.

It's not that I missed your point, but rather that I was too subtle in mine.

Proof? That's a hard standard... However, such a fact is solid evidence and if it looks like the goal isn't being accomplished, it is evidence that the real goal is not what you think it is.

I think I was implying that it was a great analogy. Like I said: too subtle.

Making a significant and persistent change downward in the amount of drugs flowing into the market may not be the most important goal of the "War on Drugs" for the people who direct it. It may not be a goal at all. The War on Drugs kills, hurts, and/or incarcerates a large number of people, most of them not affluent white Americans. It forces the raw pure capitalists of the drug trade into a choice between leaving the trade or incorporating violence and other criminal acts as core competencies. It reinforces class distinctions in the US by entrenching the drug trade as a generally dangerous and criminal but highly lucrative business that has very few barriers to entry and advancement other than its serious risks, drawing its participants mostly from communities where other opportunities are thin. It co-opts foreign governments, leaving places like Colombia and Mexico with governments which would disintegrate were it not for their anti-drug battles backed by the US. The War on Drugs yields results which benefit the people who have driven and steered the War on Drugs for decades. It is reasonable to conclude that those results are the goals of the War on Drugs, and that the War on Drugs is in fact working. Similarly, the War on Terror has proven itself useful, even though it has not been terribly successful at eliminating terrorism and seems to have actually bolstered the recruiting of violent Islamist groups who focus on the US as their enemy. Just as an end to the drug market in the US would be a catastrophe the people driving the War on Drugs, an end to Islamic extremism would be a catastrophe for the people who drive the War on Terror. It is not coincidence that those two groups are so overlapped that they can be seen as one gang.

Absolutely. I guess we're defining "success" differently.

The meaningful success metric for the task of building a network of machines for illicit activities is not the crack percentage of attacked systems, it is the aggregate capacity of cracked systems which can be harnessed for those illicit activities. Breaking into 90 of 100 Windows boxes attacked isn't so great if the result is control of 90 desktops and laptops that get disconnected from the net, shut down, or rebooted routinely, are largely 5 years or more old, and mostly have users sitting in front of them who might notice hijacked capacity. Breaking into 10 of 1000 machines with SSH daemons (i.e. mostly Linux and other Unix-ish systems) by brute force password guessing may be a better result, since the cracked systems are likely to be more exploitable than the average Windows box and the attack is absurdly cheap to run against a huge set of targets.

Winning? No. Causing a lot of casualties? Certainly. Interdicting a lot of drugs? Sure. SSH brute force attacks and the other modes of attack that have become "background noise" for any competent admin work often enough that they are worth the effort for crackers to keep up the pounding. They don't have to work most of the time or even a whole percent of the time to be worth committing a few zombie machines to the scanning, because vulnerable Unix-ish machines tend to be more valuable than vulnerable Windows boxes (those tend to have people sitting down in front of them noticing the slowness... )

Speaking as a sysadmin who does some network work and was a pretty damn good programmer once upon a time...

• Programming as a job gets boring. It is very unusual to have the right employer and projects to keep the task of writing code from becoming tedious and unchallenging after a few years. A diverse midsized network never stops presenting interesting challenges, because users will always be pushing for it to do more. Users like their software stable, but they want their networks better.
• There are not millions of highly motivated would-be network admins on the other side of the planet who would love to make $200/week and who can manage a diverse midsized network remotely with a 10:30 timezone offset and an accent that users can't understand. For a programmer in the US, that competition is very real.
• Programming is a dead end for many people. The only ways up take you into less of being a programmer. In systems and network administration, you can make a career of handling ever larger and more capable facilities without having to move into management or starting your own company or any of the other things that programmers end up moving into when the boredom, offshoring, or need to put kids through college pushes them out of programming.

Of course, I'm not saying that all programmers have to become admins to remain in technical jobs, but it is a very common path and there are very few programmers who are still programming into their 40's. It is also extremely useful for people managing operational infrastructure to understand the practice of software development. One of the most limiting factors for an IT technician is excessively narrow focus, so a network admin with a programming background or a server admin with networking experience or a programmer who has done desktop supoport can bring useful insights that someone with a narrow career focus won't have.

Realize? Heck, I've seen it happen... It is more than a little disconcerting to break open a damp bale and get a "WHUMP" as the air hits hot methane inside. You can get the same sort of thing with composted yard waste or wood chips. But a spontaneous burn left to itself is a very slow smolder starting deep inside, and it is bottlenecked by lack of O2 so that it will usually self-extinguish. It's not the sort of consuming conflagration you'd want for needle-hunting.

Sheesh, kids these days... If you'd ever worked with hay, you'd know that a haystack is likely to be rather moist inside and that hay dry enough to burn well is not necessarily dense enough to sustain a fire in a stack. Dousing it in gasoline makes it more likely that any particular straw will burn hot enough and long enough to dry out and ignite its neighbors.

Not very likely. Apple only really needs to worry about US anti-trust law and its enforcement, and that means they would have to hold on to their 90% share in tablets for years and engage in predatory anti-competitive practices just to get a stern finger-wagging. See Microsoft for an example of how fearsome US anti-trust law is...

As long as Apple doesn't get an entitled mindset towards their market share and keeps putting out products people like better than their competitors, they have no reason to fear anti-trust prosecution that would actually hurt. Microsoft ended up agreeing to a toothless consent decree because they had an absurd market share, customers willing to complain on the record about monopolistic abuses, and a prominent US competitor that could demonstrate that they were the innovators in their segment and were being specifically targeted by MS. Apple has a long way to go before they even get to that point.

Limited scope answer...

Purely for documentation, i.e. making visual recordings showing how to do something, there are multiple tools for capturing a video from the screen of doing something in a GUI. I use Snapz Pro X when I need that.

Indeed, logical recordings are much more than documentation. A CLI is much better for making a replayable logical recording of user activity than a GUI because the CLI has a much less complex universe of actions. For example: on my ornately configured personal system I have 2390 executables in my $PATH, but the main display on the same machine has 3686400 logical cursor locations on each of 6 desktops. If the basic action of a CLI is a command and the basic action of a GUI is a mousedown, the GUI starts out with 3 orders of magnitude more possibilities to track at that gross level. The CLI can't lose the contest of what is easier to record in a reproducible way.

That said, MacOS has had recordability to replayable scripts as a feature for a long time (even before OS X,) but it works best with application support and many apps don't bother. That means that it is not a universally available tool, although admins do use it (and the related Automator/AppleScript/OSA plumbing) to do the same sort of integration/automation work that Unix sysadmins are used to doing with shell scripts. It's a bit like scripting in csh: there's lots of intrinsic breakage but a lot of admins manage to work around it.