HN user
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.
This sort of vague comment
Not sure about "vague comment"s but anyone who has run an email server, used an rbl/rhsbl, and followed the logs <http://www.postconf.com/docs/spamrep/> would say the same. Having done so for years and run reports on dozens of servers daily it is clear that blacklists are the most effective form of spam blocking, by at least an order of magnitude.
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?
I don't use Google docs/sheets/gmail/... due to their terms of service. Why give Google a perpetual right to do anything they want with any content put in a Google app? https://www.google.com/google-d-s/terms.html
Who clearly has not take even one semester of college level nutrition.
These sorts of "studies" are still being published, many of them funded by the dairy industry. Has nothing to do with science or nutrition as is taught in college, it is simply sales and marketing not unlike similar studies done by the tobacco industry just a few decades ago.
It actually started with the British whose spooks taught it to the US' Herbert Hoover before WWII. Read "Enemies: A History of the FBI by Tim Weiner" <http://www.theguardian.com/books/2012/mar/30/enemies-fbi-his... for the definitive historical overview of how domestic spying and its abuse got started.
George Orwell foresaw the potential for abuse long before 1948 when he wrote "1984" <https://en.wikipedia.org/wiki/Nineteen_Eighty-Four>.
Why would an email client need an RDBMS backend in the first place other than the fact that, like WordPress, the devs did not value KIS? Squirrelmail does fine without a db, as do all of the command line clients.
You can see how ridiculous the argument is ...
It doesn't seem so ridiculous if you follow the money. The author is "executive director of SPUR, a Bay Area nonprofit membership organization" whose directors, advisors and members are comprised almost exclusively of real-estate developers and investors.
The current Berkeley Daily Planet goes in to some detail about this sort of non-profit, http://www.berkeleydailyplanet.com/issue/2013-10-11/article/... as does the Bay Guardian in its "Friends in the Shadows" expose http://www.sfbg.com/2013/10/08/friends-shadows You'll never read these sorts of in-depth articles in the rest of the Bay Area's real-estate advertising filled newspapers.
Not exactly. The free market is also what enables neighborhood preservationists to keep redevelopment out. Well that and the horrid examples of redevelopment 40 and 50 years ago that are getting uglier and less livable by the decade.
Developers have done a good job of buying off the media, and the Chronicle has never waivered from its support of those sectors that still advertise in its pages. That's why many of us are not sad to see the otherwise well written paper giving way to Internet new sources that, this article excepted, are less inclined to skew their editorial policy in favor of anything real-estate (-development) related.
This is typical real-estate developer rhetoric "we can continue growing forever". Don't look behind the curtain, though, at the real reason redeveloped neighborhoods are sometimes more affordable i.e., you get what you pay for. IMO not every city is well served by demolishing large tracts of historic buildings for the glass-facade utilitarian apartment buildings predicated on Quonset hut structural engineering principles (cheap, fast, profitable, not to be confused with architecture). Let the developers work where they're needed, Brisbane, Millbrae, SSF, etc. but leave San Francisco's character and beautiful neighborhoods to those who appreciate _living_ in them (vs profiting off of them).
The Examiner did a great article on the damage done to the City by redevelopment of the type this article advocates, in the 50s and 60s. Seems now to be available at USA Today: http://usatoday30.usatoday.com/news/nation/2008-11-09-245099... IMO, if you want to see exactly what Gabriel Metcalf is talking about go to the City's Western Addition and while there ask yourself if it was worth it.
we were trusting that such programs would not exist here
It's still not clear what programs you are talking about. Because google provides no access logs "someone could go into our account and take confidential information, and we would never know". What does that have to do with Echelon or Prism?
This is perhaps true where budget is severely constrained, or where Windows servers are spec'd, or where developers do systems administration, or where the corporate culture won't pay for capable IT.
Experienced IT staff can typically exceed the uptime of Google and Salesforce on a standard budget with no special accommodation. Perhaps the organization's IP (intellectual property) wasn't really worth that much, or upper management forced their hand? Sounds like that wasn't the case but you never really know.
It doesn't take much reading of the literature to understand industrial espionage or any of the other substantive risks of outsourcing. Prism or not, when you put your intellectual property on someone else's networks you are taking a risk.
Yet most of the managers I see who make this decision just don't care. They ignore the advice of their systems admins and follow the old adage "you can't get fired for buying IBM" like sheep to a slaughter. It's typical of the short-term mindset that drives so many business decisions.
I chalk this up to a lack of education, both in business and IT. While CS professors obsess over data structures and algorithms, and non-IT departments preach about the relevance of the next quarter's results, "Rome is burning".
I would rather see them challenge FISA requests on the basis of tax law. These requests are, in addition to everything else, a form of taxation.
This isn't really an educational article. I say that because of the studies it selectively cites and the conclusions they reach.
For example it's fine to call a facial skin abrasion a "head injury" if you are clear about that definition in the research. It's another thing to cite research about "head injuries" and helmet use without mentioning what they means by a head injury.
The article also fails to cite research that contradicts the authors bias. Academic work such as Robinson's longitudinal study of AU or numerous pieces in the British Medical Journal (as referenced at http://www.boycottbell.com/ ) appear to have been carefully avoided.
For these reasons, and the fact that Bicycling Magazine is heavily funded by helmet advertising, it would be naive not to see the advertising influence in this article which goes out of its way to appear to be educational.
The unfortunate result of this sort of "journalism" is that people with little cycling experience and no knowledge of epidemiology read it and assume it is true despite the fact that 98% of the world's bicycling population don't wear helmets and their incidence of true head injuries are uniformly lower among them than the US' helmeted riders. Another downside to this propaganda is that many kids never take up cycling in the first place and many of those who do ride are afraid to venture outside of bike paths, sidewalks and super-low-traffic routes.
From a foreigner's perspective this illustrates American's naivete with regards to sales and marketing and their relatively undeveloped bicycling ecosystem. I for one hope both of those dysfunctional cultural attributes improve with the rising price of petrol.
Rare to find somebody who understands the monitization of big data as well as this. It's too bad more users of google analytics, facebook et al don't know how much they're giving away.
>I have /boot, /home and sometimes /srv in a different >partition. I don't know of any other way to accomplish >that
/boot is typically located on the same disk as root, so that should be ok. /srv and /home, however, would be problematic root mounts. You can use automount to fix /home but /srv should be mounted under /usr or /var.
Mounting NFS or busy disks on the root dir is not a good idea on any server where filesystem i/o performance is an issue.
The docroot path? That would indicate the Ubuntu devs who chose this location had little or no sysadmin experience. Files and dirs under /usr should not be mutable, that's what /var is for.
At least they didn't locate it on the root directory. Mount points should never be on root. See the sources for stat() for the main reason why not.