pconf

This article fails my smell test. The adolescent vocabulary doesn't correlate with the otherwise polished writing style and the technical merits fall far short of the proposed remediations. It is therefore likely to have been funded or otherwise inspired by the NSA in an attempt to smear PGP, still the most effective cryptography available to the average person.

It looks to me like the OP is making more of a beef about Verizon's advertised speeds being significantly different from their actual speeds. That Verizon is continuing to advertise speeds that it intentionally is not delivering, IMO, constitutes fraudulent advertising. This can and should be the basis of, and resolved by, a class action suit.

It's no different really than an ISP that advertises 100Mbps, has ethernet to the home, but only a T3 to the Internet.

I'm sure their customer contract has clauses which specify that "actual speeds may vary". This does not, however, make their advertised speeds any less knowingly false.

This is a story about what can happen when a governmental agency has: A) too little oversight, B) way too much (taxpayer) money, and C) way, way too little transparency.

What can you do about it? A) join the ACLU and donate a little every month, B) actively support open government ordinances and proposals at every level of government, C) support investigative journalism and avoid agenda-driven media outlets and D) vote against surveillance-state supporting politicians (esp Feinstein and Boxer in CA) at every opportunity.

A writeable open VCS would also make heartbleed-like vulnerabilities more likely. As such the OP's comments should be evaluated as potential astroturf. Were the NSA looking to introduce new and effective backdoors, and we know they are, this would be one way to pressure IBM/Weitse for access.

It's more than "coders who don't know how to code", it's also managers who don't know how to read code or review diffs. Sadly, there are lots of experienced coders whose planning horizon stops as soon as the code works i.e., they don't maintain code or think in those terms as long as it's working. This is often why shops use these overreaching frameworks.

Systems administration is no different, which is why so many servers are now either straight-jacketed in OS packages + chef/puppet/ansible or such a mess they're the equivalent of spaghetti code.

IMO this is fundamentally a failure of higher education (EE/CS, IS ...).

> Maybe a typo

Could be a bug in your web browser. The first sentence is a quote as indicated by the ">" character at the beginning of the line.

>There's more to it.

That is alluded to in the 5th from last paragraph: "Facebook's terms of service forbid third-party verification of its clicks". What reason, other than fraud, would they have for such a clause?

This is one of the reasons I only purchase AMD-based systems. Well that and the fact that AMD's CPU/GMU combo has better graphics performance.

It's either that or support a company whose market advantage is based on anti-competitive practices and who will spend a significant portion of their profits on reducing consumer's choice of CPU (up to the point they no longer have to of course).

It is unfortunate that FreeBSD chose those names to attract people to the pre-release versions. What's needed is a section of the website clarifying:

CURRENT = alpha, dev

STABLE = beta, rc

RELEASE = passed all tests and released

That's not to say that things never break in releases. I've seen gjournalled disks (on a gmirror) require fsck (in 8 and 9 -REL) and carp fail (in 7 -REL). Other than those FreeBSD has been the most reliable, secure and up-to-date of any Unix or Linux distribution I've used. My only request would be a policy discouraging ports with perl build-deps, most of which seem to be one-liners that could easily use awk, sed and/or grep instead of forcing a perl build on every upgrade (most not even bothering to remove the build-deps when done).

There are downside to AWS other than reliability (a la Netflix). One of those is privacy. If you host with AWS Amazon has access to all of your user data, and with Amazon likely the NSA. If you want to maintain a free and open forum for people to express support for people like Snowden and Assange and question the NSA or military / industrial complex' percent of the federal budget (>50) then you have to run your own servers in a skilled, ethical, small to mid-sized ISP's facility.

This doesn't explain the penny-wise (IMO) allocation of hardware or dev/sysadmin resources of course.

IMO data loss is less a symptom of untested backups than it is of developer-managed systems. I wonder if ycombinator has a sysadmin (who isn't also a developer)?

Please correct if I'm wrong but it looks like the decision to scale using HG instead of git was made on 2 points: 1) git maintainers basically said you should split repositories and left it at that, and 2) HG's cleaner code and abstractions made it easier to patch.

Fundamentally I like how this cleans up the design flaw of requiring history everywhere. 99% of the time when I clone or pull or diff or whatever I only care about HEAD. Why should I be forced to pull or store GBs of history or even MBs of metadata I can't use? Why not make leaving this data on the server optional? I can see how the decision to push history everywhere was made for simplicity but it doesn't reflect real world usage and clearly isn't scalable. Let's hope these history-option patches continue to be developed and make their way upstream. They certainly have my vote, not just as options but as defaults.

IMO the most important aspect of this whole debate is money. Lots of money is made from manufacturing and selling bicycle helmets. That's why the bicycle-naive general population only knows about helmets when asked about bicycle safety.

Given that skills training, traffic engineering and other key components of real (i.e., statistically defensible) bicycle safety are not profitable how would you go about fixing this dysfunctional aspect of our automobile-centric cultures?