28 karma · joined November 23, 2010
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.
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.
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 ...).
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.
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.
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?
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).
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).
This doesn't explain the penny-wise (IMO) allocation of hardware or dev/sysadmin resources of course.
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.
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?
George Orwell foresaw the potential for abuse long before 1948 when he wrote "1984" <https://en.wikipedia.org/wiki/Nineteen_Eighty-Four>.
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.
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.
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.
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?
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.
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".
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.
/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.
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.