I dunno about survivorship bias. Some of the books I've been re-reading are out of print and hard to find. In any case, I'm not saying the best books today can't hold a candle to what was published forty year ago. Not at all. The remains as it was. But you have to understand the changes that have gone on in traditional publishing. Yes, ebooks are a big deal, but an even bigger deal is print on demand.
It used to be that publishers had to take a big risk publishing anyone who wasn't an A-list author. The way it worked is that the publisher would do a big print run. They'd send cases of the book to bookstores, who'd put them on the shelves. After awhile if all the copies didn't sell, the bookstores would ship back the unsold copies and the publisher would pulp them. All very expensive.
It doesn't work that way any longer. It's now feasible and affordable to do much smaller print runs, and bookstores can order a few copies of a book, then if those copies sell order a few more copies. This has two big effects. First, it's a lot less *intrinsically* risky to publish an author than it was ten or twenty years ago. This means you don't need balls to be a publisher these days. You still make money on the blockbusters that fly off the shelves, but you can also make money on a mediocre, me-too book.
The second big effect is that bookstores can stock more authors. All things being equal, that should mean there's a lot more diversity in books on bookstore shelves -- but there isn't. Instead there's more authors doing more of the same. And these second tier authors are not by any means *bad*. The craft standard for these stories is very high, probably higher than run-of-the-mill stories forty years ago. It's just that as a whole it's more of the same old thing.
This isn't the author's fault; an author writes whatever appeals to him, then tries to get an editor to pick it up. It's the agents, editors and booksellers who selectwhat the public finally sees, and by in large that is well-crafted stories that bear a striking resemblance to some blockbuster franchise. This is not because anyone expects to duplicate the success of the Sookie Stackhouse or Twilight stories. They know quite well that's not going to happen with a "me too" story. What they're looking for is something that can sell a modest number of copies to fans of the big franchises and turn a small but reliable profit. That's a strategy that wasn't possible twenty years ago.
Movies of course are looking for blockbusters, but the essential similarity is that the producers are often combining well-known elements in an attempt to generate sure-fire profits.
Well, I saw "Pacific Rim", and it wan't a shitty movie. It wasn't a great movie, either. It was mediocre, in a particular way that seems to be becoming more common as businesses begin to feel more confident crunching the numbers on a work of art. It's happening in publishing too, as second tier authors churn out clones of The Dresden Files, Sookie Stackhouse, The Hunger Games, and of course, Twilight. The formula is "Like X but with Y" -- e.g. "Like Twilight, but with zombies." Some literary agents are even asking for this kind of summation in query letters.
I think this is because on a spreadsheet at least, it looks like you can make money without risk these days, if you just get the formula right. Usually these mediocre "me-too" books and movies aren't bad; in fact they often display a high degree of a certain kind of perfection -- the kind of perfection that consists of not making too many major mistakes.
Take "Pacific Rim". It's high-concept -- giant monsters vs. giant robots -- and the script and director work hard to deliver exactly what is promised. No time is wasted on back story or set-up; the exposition is somewhat crude and artless, but it is calculated to take the minimum time possible to get the viewer to the giant robot action. You have to admire the high level of artistic discipline required to predictably churn out something serviceably mediocre, but it means that you won't get something great. If *all* you're looking for in a movie is CGI battles between giant robots and monsters, it'd be hard to improve on "Pacific Rim"; it's just that most of us, even mecha-loving geeks, kind of appreciate a story that has a bit more creative excitement in it.
I've made something of an effort over the last couple of years to go back and re-read many classic sci-fi novels from the 40s - 80s, and almost without exception the great stories break some canons of taste. If you read a great novel critically, you'll almost always see that it has structural or artistic flaws; rules are broken, but so that the story can reach levels you can't get to by adhering strictly to a formula. I don't know as much about cinema as I do about books, but I bet it's much the same: you've got to be willing to try some things that are wrong, or questionable at least, to rise above mediocrity.
Oh, there's no question *life* can adapt to these changes. The question is whether certain economies with enormous assets located in coastal regions can survive. 39% of Americans, for example, live in coastal counties. Although for political reasons that figure includes counties bordering the Great Lakes (America's "North Coast"), nonetheless the assets the US economy has enormous assets on the coast.
Of course *rate* makes a big difference. The extreme upper level IPCC estimate for sea level rise by 2100 is 2m; that would be an economic disaster. We'd probably abandon much of the Gulf Coast, and most East Coast cities would require massive flood control projects. The same rise over two hundred years would have the same results, but it would happen over many more generations and would probably feel a lot less like a disaster.
Life is adaptable, and humanity is among the most adaptable species on the planet. There is no prospect of human extinction under any conceivable climate change scenario, what we are looking at is human misery and economic dislocation. The Great Depression and WW2 combined weren't even a blip on the species survival radar, but they packed an enormous load of human suffering. The difference between 75cm and 2m sea level rise over a century is the difference between a serious ongoing economic concern and a long-running disaster.
It's not the magnitude of change we have to worry about, it's the *rate*.
Overpriced death-trap it may be, but the F-22 is an elegant tool designed to do a single thing well: wrest control of European airspace from the Soviet Union.
which is content. You're not experts in DRM, so trying to roll your own is only going to be a PITA for you, and your customers, while hardly impeding anyone who wants to pirate.
This means if you want a solution with DRM, you're going to publish through somebody who is doing DRM'd electronic distribution. That means Amazon's Kindle Publisher, the equivalent Barnes and Noble program, iTunes, or Kobo. The trickiest thing will be figuring out whose terms of use give you the most opportunity to recapture revenue.
If you're publishing a paper magazine, chances are you are heavily into Adobe already. It would make sense to see what they're offering in terms of electronic distribution and DRM infrastructure to their magazine publishing customers. I'd be willing to bet they've got a solution targeted right at your kind of outfit, because you are hardly unique in your predicament.
If DRM isn't that critical a concern for you, you might think outside the magazine publisher's box and go right to social media. I know that a number of publications are offering Facebook apps, and again because you are hardly unique in your situation I'd bet there's a way to capture advertising revenue through a Facebook app. Going this route you probably won't be able to keep folks from copying chunks of text from your magazine for their own purposes; that could be an issue for some of your contributors. That said, it's so convenient for users that wholesale piracy of the latest stuff probably won't be a practical concern for you.
The argument over who's at fault entirely misses the point. With a little planning the officers could have searched the house without mounting a paramilitary style assault with a SWAT team. They could, for example, have entered the man's house while he was at work. That would have been a safe, predictable, and effective way of obtaining the evidence they needed. Instead the police chose a dangerous and unpredictable alternative.
There's no reason to believe the cops didn't announce themselves, but the instant they *do*, the clock is ticking. If the suspect actually *is* armed and hostile every second waiting increases the danger to the officers on the raid. That puts them in an automatic escalation mode. There's no way for officers put in this situation to distinguish between the case where the occupants aren't responding because they'are asleep, as in this case, or because they are preparing to repel the assault with force.
Ultimately the responsibility for the officer's death lies with the commander who ordered an assault because it was his automatic way of dealing with drug searches. A little thought could have reduced the danger to which his officers were exposed, not to mention anyone who happened to be in the house. A SWAT team is a powerful tool, and like any such tool fools can get enamored of the power and use it where a little finesse would be simpler, safer and more effective.
Nobody deserved to die in this situation, but somebody deserved to lose his job.
Well, as devil's advocate you actually made a pretty good case that there are too many such raids, and that sending SWAT teams in where there is no specific reason to is criminally negligent.
I agree with your sentiment, but it's not either/or. True, they should pardon him, and others less prominent than he, because prosecuting someone for his sexual orientation is an affront to justice as we now understand it. But nonetheless Turing was an exceptional human being, and exceptional human beings play a special role in changing attitudes.
Arguably, no other person did more to preserve liberty in the 20th C than Alan Turning, through his work at Bletchley Park. The ingratitude with which his nation treated him after that doesn't add to the injustice done to him, but the ingratitude of that treatment does throw the callousness and irrationality of that injustice into sharp relief. People can look at the injustice done to such a figure and feel shame, well before they are ready to feel shame for the treatment of a less gifted person.
Shame for the shabby maltreatment of heroes is the first step towards feeling shame for the maltreatment of ordinary people.
Those customers that are left, aren't stupid enough to buy a windows computer that can't run all the x86 programs they usually have?
So they'll buy an iPad that doesn't run those x86 programs either?
It's an irrelevant point. Preserving your software investment was a "value proposition" that helped keep people locked into windows, but it doesn't apply in the tablet world, where apps are smaller, simpler and *cheaper*. $199 is a cheap desktop app, and $1000/seat is common for business apps, $3000/seat is not unheard-of. But people don't buy tablets to run $3000/seat software, they buy them mostly to run browser-based software or apps that cost more like $3.99/seat.
If anything, I'd bet it's the association of Surface with Windows that turns people away from it. Tablet are about a direct manipulation experience: you see something onscreen, you reach out with your fingers to twiddle it and it responds immediately in an intuitive way. These are not qualities that people associate with Windows, which they associate with heavyweight, non-intuitive, and *expensive* apps. That's why Apple was better positioned to launch a tablet than Microsoft.
It's taken Microsoft a long time to wrap its head around the user experience thing, because unlike Apple they're not a company built on selling to end users. People use Microsoft products because somebody else decided they'd use them, the IT department for example. In pre-iPhone smartphones, Microsoft and handset manufacturers gave the *carriers* exactly what they wanted, which were phones that didn't undercut the carrier's expensive premium services. No voice dial for you, Sprint customer, it's a Sprint add-on. Oh, and if you want the pictures off your phone, send them through the carrier's "picture mail" (!?!?) service. Things were that way, not because the end-users wanted them that way, but to make the middle-man happy. The iPhone destroyed those kinds of business practices, leaving Microsoft with the image of the company that wouldn't let you do what you wanted with your device.
You totally missed the point. I'm saying you *don't* interrupt the sprint. You make the sprint long enough to get things done but short enough that changing business priorities get injected into the development process in a timely fashion.
A 1 week sprint is, in my opinion, almost always going to be too short. 30 days is almost always a reasonable sprint length, and as you say if something is *really* pressing you can always interrupt it. A one week sprint that you can interrupt is almost meaningless as a sprint, excepting of course bona fide crises (e.g. man-rated emergencies).
I second the nomination of Scrum, which complements agile development practices.
Scrum is about managing development priorities. You can't work efficiently if you keep changing priorities every day because nothing will ever get finished. On the other hand, if you *never* change development priorities until you've finished everything you set out to do, developers are happy but they might not be working on things the business needs or wants.
The truth is that businesses have to respond to change. A rival announces a new feature; the price of some related product or service changes dramatically; regulators threaten to fine your company for some reason; a PR scandal forces your CEO to get up and make public promises you'd never imagined. Things like these can change a business's priorities, and if your employer's priorities change, yours ought to as well. Just not so often you never manage to finish anything.
Scrum strikes a sensible balance between changing direction so often you never finish anything, and putting your head down and finishing things but then finding out your employer actually needed something else. Don't get me wrong, if you *can* keep the same priorities for months on end, you should. But in many situations you don't have that luxury. You have to respond to business changes, while at the same time finishing what you set out to accomplish.
No problem on the TL DR, but you raise an important point. You're absolutely right that a strongly typed language has some optimization advantages, but CPU is only one kind of resource. Optimizing CPU usage for a sequence of statements is a good thing, but that's simply not the bottleneck in scaling web services these days.
Node.js demonstrates this. Under the covers it uses polling (I presume) to ensure that the CPU keeps doing useful work as the load climbs, rather than spinning its wheels waiting for I/O. So instead of allocating a thread per request and stalling every single thread as it waits for the results of a database query, Node just goes down the list of queries with data returned and fires off a small event handler you write in javascript. I suppose it helps that the javascript engine Node uses is very efficient (for Javascript), but there's more to gain in efficiently CPU usage by managing *other* resources efficiently than there is by compiler optimizations -- at least for *typical* web applications, where the task is to glue back end resources like databases to front end applications in HTML.
I dunno. I'm pretty liberal myself, and I've supported same sex marriage since even before it was legal here in Massachusetts. I see no reason to boycott an author *just because I disagree with him*.
Now I could perhaps see some point in it if it were ten years ago, and I'd be sending money to an anti-gay marriage activist who would turn around and spend it on perpetuating an injustice. But as Card says, it's a moot point now. Opposition to gay marriage has been defeated with stunning rapidity, and as the change is implemented people will discover that dire predictions for the institution of marriage won't come true. In twenty years young people will wonder what all the fuss was about.
So the only point of a boycott NOW is to punish Card for being wrong. I suppose there's something in that, but I can't get all that excited about it; it smacks of being a bad winner. And if we punish people on our right for being wrong, shouldn't we also punish people on our left? Shall we boycott Frederik Pohl for being a former communist? Granted, he's not really much to *my* left, but I've never advocated nationalizing private businesses, I think that's morally wrong.
Now I don't care a bit about the movie, it can sink without a trace as far as I'm concerned, but to be totally consistent in the Jihad Against Card we'd *also* have to target the book; to shame people who buy the book and stores that sell the book. Against the value of stroking our righteous indignation against Card for his past misdeeds, we have to set the loss the the public of what is a landmark literary work. It's hard to name a science fiction novel in the past thirty or forty years of greater literary importance. Perhaps THE DISPOSESSED, GATEWAY, THE LEFT HAND OF DARKNESS, DO ANDROIDS DREAM OF ELECTRIC SHEEP, or TAU ZERO. Just a handful, and few of them are as accessible as ENDER'S GAME, which can be read as a straight up adventure story or bildungsroman. Accessible it may be, but ENDER'S GAME does something very interesting and ambitious: it explores the very nature of moral responsibility.
If there is a moral imperative to make the ENDER'S GAME movie into a commercial failure, then why wouldn't the *same* imperative must apply equally to the novel? And if we forced ENDER'S GAME out of the bookstores, we'd be depriving those future people (who have no idea what the fuss about same sex marriage was about) of an important science fiction novel.
You're asking for the classic apples to oranges comparison here.
Node.js is all about scaling the number of requests/second -- about minimizing the number of boxen you need to serve thousands of requests per second. By using polling instead of threads (under the covers) and asynchronous event handling (above the covers), it becomes simple to respond to high volumes of requests without allocating huge volumes of resources.
But requests/second is only one dimension of scalability. There is management of the infrastructure. There is security (the number of Node tutorials which completely omit this is shocking). There is complexity (much of which in Node.js is pushed to the client side). There are features (e.g. the messaging and timer services in Java EE).
The buzz over Node.js reminds me of the buzz over Ruby on Rails a few years back. RoR also introduced an elegant new programming paradigm -- configuration by convention. People were amazed that the could field a simple example app without having to write XML configuration files for the ORM layer. Look! It creates all CRUD interfaces for me! But in the end those tasks really aren't that challenging for an expert programmer; they're more like sand in the gears when you're starting up a project. So while RoR remains a good tool for certain kinds of web apps, it's nowhere near as revolutionary as it seemed at the time, and it has little penetration in the enterprise market. It sees to me that most of the joy in Node.js is likely to be on the front end of the project, but in the long tail of the project you're still going to have a lot of drudge work, especially where you have to roll your own enterprise features.
Which is not to say Node.js isn't brilliant. It appeals to the old Unix man in me, because it does one thing really well. It's a superb piece of middle-ware glue. It makes exposing back end services like databases to RESTful web clients a snap, and if you've got to do that on a massive scale, where by "massive scale" I mean by retail web standards where you have to handle tens of thousands of simultaneous connections. For web applications where you don't have to integrate with a lot of back end enterprise systems and where there's a heavy emphasis on a rich HTML/CSS UI, Node.js is an elegant solution that reduces the information overload on the development team by taking advantage of the Javascript expertise they're bound to have.
My oppinion is that Javascript is not bad as a scripting language, but we are abusing it and twisting it beyond its original purpose. The main issue is actually that Javascript is too flexible. Untyped code has an habit of hiding mistakes in hard-to-debug ways. But once you add types to Javascript, it's not Javascript anymore.
A couple of points. First, the argument you're making is for static -- i.e. compile-time -- semantic checking. I was hearing the very same argument thirty years ago among people who advocated Pascal over C; on paper it's sound, but decades of practice have convinced me that static checking, while probably helpful, is not as efficacious as it seems like it should be. After all, you *still* run into mishandled exceptions in Java, and many Java programmers do an end-run around around much of the compile-time restrictions by using runtime exceptions; in fact wrapping low-level checked exceptions in runtime exceptions are a feature of some frameworks. It's hard to get programmers out of the mindset that a core dump, or an unhandled exception, is some kind of serious calamity. You don't want them in production code of course, but they're far less calamitous than continuing processing with bad data. The place to catch those problems is in testing.
As for the other kind of compile-time problem, handing an object to a routine that expects an interface the object does not support, what scripting languages like Python have shown is that it's not that big of a problem. Large, sophisticated systems programs have been written in Python, which lacks precisely this kind of checking.
I'm very comfortable with Java, but there is something about the design of the language and its core libraries which encourages over-engineering. For example, itis possible to do asynchronous http handling in Java EE, like you do in Node.js, but in Node.js you simply create a non-blocking event handler for every case you want to handle. In Java EE, if memory serves, you create a ServletContextListener with a Queue member, and put that member in the servlet context. Then in your servlet you create an AsyncContext and put it in the Queue. None of this is as complicated as it sounds, but it only covers the case when you want to keep a socket open to the client, like when you're doing Comet. If you want to conserve resources by serving your I/O requests using polling rather than blocking threads (the primary Node.js use case), you've got to use java.nio, which can get complicated.
On paper, designing programs in Java is a cinch with Java's rich OO features. Any reasonably competent programmer can quickly learn enough to demonstrate facility with the *features* of the language. In practice as a programs required feature set grows, the number of classes and interfaces explodes, unless you are a very talented software designer.
While it's true most Javascript programmers write simple onload and onclick handlers, this doesn't make Javascript a toy language. While its object-oriented features are relatively primitive, its functional programming features are quite sophisticated, and this turns out to be just the thing when you are writing sophisticated event handlers, as in Node.js. Expert Javascript programming is about implementing higher order functions which return closures, something that current versions of Java can't do (Java SE8 is getting lambda expressions, so this might change). Functional programming is all about getting a single transformation of inputs to outputs correct; it feels *contained* -- that is to say you don't need to think a lot about the context in which your code runs. Programming in Java is often an exercise in information overload, as it typically involves mastering the nuances of multiple complex libraries and frameworks so you can fit them together properly.
So, I saw a *car* run a red light today. Strangely, that does not cause me to question the right of automobile drivers to use the roads.
I agree with most of your other points, although a turn signal isn't really practical. I use hand signals (although most drivers don't seem to understand them, so I signal a right turn with my right hand). I stop at the stop-line, I don't weave between cars, and in general obey all the rules that apply to slower moving vehicles. I do claim a lane when I travel in traffic, although I pull over regularly (when it is safe) to let trailing cars pass. That's not the law, it's just common courtesy.
Security is hard. General-knowledge techies think they're much better at security than their masters, but I have my doubts. Techies don't always understand the value of assets and nature of threats to those assets. And they often overestimate their knowledge of system vulnerabilities. For example many techies think you can turn a computer into a blank slate by erasing the hard drive, but there have been demonstrations of firmware based malware. Just last year a security researcher created a proof-of-concept worm that stores itself in a computer's BIOS and the flash memory of attached devices and PCI cards. It has stealth features that make it virtually undetectable, except by pulling the flash chips and dumping their contents. If you *were* infected by a worm like this, and you wanted to eradicate it, you would *have* to physically destroy any attached device which had its own flash memory, including cameras, optical drives, and possibly even printers . Eradicating all physical traces is probably more than is needed to deactivate the worm, but it's a subtle point.
Another subtle point is that if you are worried about almost non-detectable malware, you have no assurance that the new equipment you are buying to replace the old stuff isn't factory infected. What that probably means is that trying to ensure you have a 100% guaranteed clean slate isn't cost effective for agencies, unless perhaps they are high value targets (e.g. NSA, CIA, some of the DoD). What to do instead isn't obvious. The simplistic model is you start with a clean slate and you prevent bad stuff from being introduced to your systems. That model doesn't work if you can't ensure your stuff is clean from the start, and if malware can enter your systems through channels you'd never imagined (e.g. some kind of innocuous USB device).
Destroying the equipment is almost certainly overkill in this case, but I can see why this particular agency might have chosen to do so. Given their role in advancing American competitiveness, they're probably hypersensitive to issues of industrial espionage and Advanced Persistent Threats (APT). According to the article the agency's CIO thought he was dealing with some sort of Stuxnet-like attack, which in hindsight doesn't seem to be the case.
As usual the/. summary is garbage. The agency spent 2.7 million to respond to the threat, but they didn't spend 2.7 million on hammer wielding contractors.Only $4,300 went to that, or 0.15% of the total expenditure on the event. The bulk of the rest of the money went to obtaining replacement services while their servers were offline, paying security investigators to track down the infection they did have, and developing a long term response to malware.
The physical destruction of the equipment was almost certainly overkill, as was bringing down their mail servers because they were transferrig infected emails. But one thing you have to admit is that the agency's response was swift and decisive.
Having led development teams with native-born Indian engineers on them, I can confirm that Indian cultural diversity notwithstanding, deference to superiors is a big deal with many people brought up there. That's neither good, nor bad. It's just different. Where problems arise is when people don't recognize that there are differences and fail take those differences into account.
As an American, I don't feel insulted when a subordinate questions my ideas, in fact I rely on them challenging me. What took me awhile to figure out was that my Indian employees wouldn't stand up and contradict me, especially in public. In a American that would be cowardly, but that's because we communicate in what amounts to be a different social language from Indians. I soon learned that you have to manage employees from deferential cultures differently; you've got to spend a lot of personal time together having quiet chats, maybe go out after work for a couple of beers. And you have to recalibrate your trouble sensors when dealing with deferential employees. If you give them something resembling an order, if they do anything short of hopping right to it with open enthusiasm, it's time to have a quiet, tactfully executed one-on-one.
This is not a worse way of doing things, it's just different, and it has its advantages and disadvantages. For me the toughest thing was I had to be careful about thinking out loud -- at least at first -- because my guys took every that came out of my mouth so seriously. At first, I found my Indian subordinates to be frustratingly passive. They found me (no doubt) to be overbearing, insensitive, rash and pig-headed. This was all just miscommunication, because we all were acting and interpreting each others' actions through the lenses of different cultural conventions. In the end, we did what intelligent people of different cultures do when working with each other: we developed a way of doing things that combined what we felt was the best of both cultures.
And that's an important lesson: people aren't culturally programmed automatons. We are capable of thinking and adapting. People in an egalitarian culture are perfectly capable of coming together and working coherently as a team, although the process may look ugly and chaotic to outsiders. People in cultures with deference to elders are perfectly capable of reporting unwelcome news to a superior.
So if a junior pilot didn't communicate an emergency situation to a senior pilot, *then somebody on that team screwed up*. They weren't doomed to crash by cultural programming. There may be nuances of their culture which contributed to the disaster, but that's bound to be true of human error in every culture.
I won't go so far as to say that *all* cultural differences are superficial. But I think many differences are more superficial than a casual outsider might suspect. That outsider might look at something like the reluctance of a subordinate to question a superior's instructions and assume that the subordinate *can't*. That's simply not true. On one level, the shared cultural understanding of the subordinate and the boss provides them with ways of communication that escape the outsider's understanding. But more importantly, people aren't mindless cultural automatons. If his boss is about to stall your plane on the approach to the runway, I don't think a Korean co-pilot is simply going to stand by silently. I suppose it is possible that he might be inclined to wait a few seconds longer than an American co-pilot, but if that endangers the plane then that is a mistake, period. A Korean airline is perfectly capable of training the co-pilots to report problems promptly, just as an American airline can train co-pilots to execute the commander's orders promptly without engaging in an impromptu debate.
Not really discrimination if there are reasons. Old people are in physical and mental decline. Old people also aren't a minority: just like it's OK for a female manager to prefer to hire women, or a black manager to prefer blacks, the young can prefer their own kind. Sorry, time to die.
I've got news for you sonny -- we're *all* in physical and mental decline. If you think you are going to live forever, think again.
But the decline goes at different rates for each of us, it starts from different points, and is offset (in most cases) by gains in maturity, experience, and wisdom. So the bottom line is you can't make any useful generalization whatsoever about the ability of a fifty year-old to do programming vs the ability of a 25 year-old. It depends on all the things that add up to that unique person.
This is what's broken about bigoted thinking. It reduces people to some kind of ill-conceived average for their "group", when it ought to be evaluating them as individuals. Back in the 90s there was a controversial book called "The Bell Curve" which pointed out that there was a racial difference in IQs between blacks and whites, and made a number of (stupid) policy recommendations based on that difference. The inevitable shit-storm followed, in which the validity of IQ tests was questioned (in some cases with good reason), but lost in the shuffle was a simple mathematical fact: even if we assume that IQ tests are a perfect, unbiased measure of mental capability, and accept the racial differences in scores as measuring something real, those aggregate differences give almost no useful guidance in making decisions about *individuals*. That's because under those assumptions, something like 40% of blacks are smarter than 50% of whites. When you're looking for very high scoring individuals, they occur as statistical flukes in both groups.
Where that leaves you is that when intelligence is an important factor in judging a candidate for something, *especially* if you're looking for high scoring individuals, you have to judge individuals on their own merits. Skin color is at best statistically useless as a selection filter, at worst self-defeating.
The analogy holds for age differences. Even if we grant that 25 year-olds are on average more capable programmers than 50 year-olds (which is doubtful), it nonetheless remains that the vast majority of 25 year-old programmers are mediocre. It may be true that mental decay has shifted some fifty year-olds from the high performer category to the mediocre category, but it remains true that high performers are statistical flukes in either group. So gray hair has no value as a filter if you are looking for *good* programmers. They're a fluke in any category.
By the way, about older people being "minorities" -- they are effectively so *for purposes of anti-discrimination laws*. The term of art you are looking for is "protected class". So the good news for all you young, white American males who resent the legal protections minorities get is that all you have to do is survive until you are forty and you'll be protected by the Age Discrimination in Employment Act of 1967.
It's not fear of nuclear power that makes it uneconomical. It's cheap fossil fuels. Back in the 70s it was the Saudis opening the oil spigot; today it's fracking natural gas and of course coal.
Which is not to say irrational fear hasn't created nuclear problems -- particularly when it comes to developing long term storage facilities for high level radioactive waste. We also give fossil fuels a break on externalized costs because we're familiar with the and therefore fear them less than we probably ought. But still, it's hard to supplant a mature, entrenched, *cheap* technology.
Well, it depends. You have to look at each situation individually to see what is at stake. If you know that Anne Frank's family is hiding in the office annex, you obviously keep your mouth shut.
In a case like this, it's important to remember that civil disobedience is most effective when it forces the government to mete out a wildly unpopular punishment. What the government has done is bound to be extremely unpopular because it has come perilously close to passing a secret law.
People think they have fourth amendment protections for most of this data, but long established precedent (Smith v. Maryland) is that there is no Constitutional expectation of privacy for metadata on phone calls. When Congress weakened *statutory* protections against collecting call metadata, American citizens *believed* their calling data was still protected by the Constitution. Nobody has bothered to disabuse them of this idea; not Congress (who despite their current posturing passed the law and authorized the program) nor the Obama administration (their posturing on "transparency" and "accountability" notwithstanding). They knew that the majority of Americans had no idea the changes in the law technically allowed the government to run a program like PRISM.
The exposure of this bit of flim-flammery makes Snowden standing up and outing himself incredibly powerful. His doing that means that this issue will *not* die down anytime soon. Look at how long the Bradley Manning case has dragged on, and *this* one, rightly or wrongly, may prove to be far more powerful in the public imagination. I think Snowden might have been morally justified in laying low if he thought he could get away with it, but his outing of himself will keep this issue alive through the next election cycle at least. That could deal a far more serious blow to the PRISM program than quietly leaking it's existence. The cost of that greater impact is that Snowden definitely loses his job, and he faces prosecution and legal punishments.
OK, now you are in a position where the burden of proof is on you.
It's legitimate to look at somebody's evidence and say, "it doesn't convince me." It's sometimes *also* legitimate to say "I've seen enough evidence to convince myself beyond a reasonable doubt, so I won't bother thinking about your evidence; otherwise you'd have to take the time to examine the workings of every proposed perpetual motion machine.
What you can't do is say, "I'll dismiss your evidence because there's a possibility you have a conflict of interest." Everyone *always* has a vested interest in any position they've taken in the past. If you go there, if you call a man a liar because he has stated a professional opinion you disagree with, it's *your* responsibility to show evidence that lying has taken place. If you can't, STFU.
I actually subscribe to the Kindle edition of the Boston Globe -- a newspaper I don't particularly like -- precisely because I think somebody need to pay for things like local investigative reporting.
I don't suppose it could be that they were making shit up, and now find it more difficult to do so with video evidence? Could this be extrapolated to suggest that a majority of "resisting arrest" charges are entirely bogus?
Which must be why the patrolmen's union wants them as standard equipment. Really, you missed your chance to make this an anti-union rant a well as an anti-cop rant.
I developed a very serious mobile app back way in the mid-90s for public health and disease surveillance. Let me tell you from experience why an app that people rely upon every day for critical work is no way to strike it rich. People *need* a lot of support for that kind of app. Support equals labor, and labor is expensive. Businesses with high expenses don't get rich unless they can command huge prices.
When smartphones came along, my partner used to gnash his teeth at stories of developers scoring windfalls with ringtones or stupid little games, and here we were doing *important* work and only making an OK living. I pointed out that if somebody pays $1.99 for something to amuse himself, he's never going to call tech support. When something represents a total investment of fifty to a hundred thousand dollars in hardware, software and system integration services, he damn well is going to call tech support. But 50K isn't really that much money if you include hardware, third party software licenses, QC'ing the client's existing data and converting it, training the administrators and end uses, and negotiating with IT gatekeepers. That's what you have to face when you do work that everyone agrees is important. Yes, people are willing to spend real money on important problems, but they also subject you to higher standards, intense scrutiny, and exacting ongoing demands, and those things eat into your profits. And the only way to get rich in business is to generate profits -- and salary you pay yourself for your labor IS AN EXPENSE.
That's why the $1.99 app somebody buys on a whim to amuse himself is bound to be more profitable than *important* software that somebody relies on to do something important -- no matter how much you charge for that software. There are exceptions to this rule, of course. Software that is a cheaper, more convenient alternative to something someone already has (e.g. Skype) is practical because what it does may be important, but that software itself is at first dispensable.
Look at the vast amounts of cash going into develop "social media"; it is no accident that most of it goes to support is so trivia. Trivia is profitable. It's easier to try radical new things in the trivial. A lot more people have an early adopter stance towards a service like Facebook than they do to towards things they regard as critical. They take convincing and hand-holding. That's why something like Google Wave couldn't get off the ground, you have to approach something as important as collaboration much more conservatively, usually working around how people already do things (e.g. Sharepoint).
Slashdot Mirror
I dunno about survivorship bias. Some of the books I've been re-reading are out of print and hard to find. In any case, I'm not saying the best books today can't hold a candle to what was published forty year ago. Not at all. The remains as it was. But you have to understand the changes that have gone on in traditional publishing. Yes, ebooks are a big deal, but an even bigger deal is print on demand.
It used to be that publishers had to take a big risk publishing anyone who wasn't an A-list author. The way it worked is that the publisher would do a big print run. They'd send cases of the book to bookstores, who'd put them on the shelves. After awhile if all the copies didn't sell, the bookstores would ship back the unsold copies and the publisher would pulp them. All very expensive.
It doesn't work that way any longer. It's now feasible and affordable to do much smaller print runs, and bookstores can order a few copies of a book, then if those copies sell order a few more copies. This has two big effects. First, it's a lot less *intrinsically* risky to publish an author than it was ten or twenty years ago. This means you don't need balls to be a publisher these days. You still make money on the blockbusters that fly off the shelves, but you can also make money on a mediocre, me-too book.
The second big effect is that bookstores can stock more authors. All things being equal, that should mean there's a lot more diversity in books on bookstore shelves -- but there isn't. Instead there's more authors doing more of the same. And these second tier authors are not by any means *bad*. The craft standard for these stories is very high, probably higher than run-of-the-mill stories forty years ago. It's just that as a whole it's more of the same old thing.
This isn't the author's fault; an author writes whatever appeals to him, then tries to get an editor to pick it up. It's the agents, editors and booksellers who selectwhat the public finally sees, and by in large that is well-crafted stories that bear a striking resemblance to some blockbuster franchise. This is not because anyone expects to duplicate the success of the Sookie Stackhouse or Twilight stories. They know quite well that's not going to happen with a "me too" story. What they're looking for is something that can sell a modest number of copies to fans of the big franchises and turn a small but reliable profit. That's a strategy that wasn't possible twenty years ago.
Movies of course are looking for blockbusters, but the essential similarity is that the producers are often combining well-known elements in an attempt to generate sure-fire profits.
Well, I saw "Pacific Rim", and it wan't a shitty movie. It wasn't a great movie, either. It was mediocre, in a particular way that seems to be becoming more common as businesses begin to feel more confident crunching the numbers on a work of art. It's happening in publishing too, as second tier authors churn out clones of The Dresden Files, Sookie Stackhouse, The Hunger Games, and of course, Twilight. The formula is "Like X but with Y" -- e.g. "Like Twilight, but with zombies." Some literary agents are even asking for this kind of summation in query letters.
I think this is because on a spreadsheet at least, it looks like you can make money without risk these days, if you just get the formula right. Usually these mediocre "me-too" books and movies aren't bad; in fact they often display a high degree of a certain kind of perfection -- the kind of perfection that consists of not making too many major mistakes.
Take "Pacific Rim". It's high-concept -- giant monsters vs. giant robots -- and the script and director work hard to deliver exactly what is promised. No time is wasted on back story or set-up; the exposition is somewhat crude and artless, but it is calculated to take the minimum time possible to get the viewer to the giant robot action. You have to admire the high level of artistic discipline required to predictably churn out something serviceably mediocre, but it means that you won't get something great. If *all* you're looking for in a movie is CGI battles between giant robots and monsters, it'd be hard to improve on "Pacific Rim"; it's just that most of us, even mecha-loving geeks, kind of appreciate a story that has a bit more creative excitement in it.
I've made something of an effort over the last couple of years to go back and re-read many classic sci-fi novels from the 40s - 80s, and almost without exception the great stories break some canons of taste. If you read a great novel critically, you'll almost always see that it has structural or artistic flaws; rules are broken, but so that the story can reach levels you can't get to by adhering strictly to a formula. I don't know as much about cinema as I do about books, but I bet it's much the same: you've got to be willing to try some things that are wrong, or questionable at least, to rise above mediocrity.
Oh, there's no question *life* can adapt to these changes. The question is whether certain economies with enormous assets located in coastal regions can survive. 39% of Americans, for example, live in coastal counties. Although for political reasons that figure includes counties bordering the Great Lakes (America's "North Coast"), nonetheless the assets the US economy has enormous assets on the coast.
Of course *rate* makes a big difference. The extreme upper level IPCC estimate for sea level rise by 2100 is 2m; that would be an economic disaster. We'd probably abandon much of the Gulf Coast, and most East Coast cities would require massive flood control projects. The same rise over two hundred years would have the same results, but it would happen over many more generations and would probably feel a lot less like a disaster.
Life is adaptable, and humanity is among the most adaptable species on the planet. There is no prospect of human extinction under any conceivable climate change scenario, what we are looking at is human misery and economic dislocation. The Great Depression and WW2 combined weren't even a blip on the species survival radar, but they packed an enormous load of human suffering. The difference between 75cm and 2m sea level rise over a century is the difference between a serious ongoing economic concern and a long-running disaster.
It's not the magnitude of change we have to worry about, it's the *rate*.
Overpriced death-trap it may be, but the F-22 is an elegant tool designed to do a single thing well: wrest control of European airspace from the Soviet Union.
which is content. You're not experts in DRM, so trying to roll your own is only going to be a PITA for you, and your customers, while hardly impeding anyone who wants to pirate.
This means if you want a solution with DRM, you're going to publish through somebody who is doing DRM'd electronic distribution. That means Amazon's Kindle Publisher, the equivalent Barnes and Noble program, iTunes, or Kobo. The trickiest thing will be figuring out whose terms of use give you the most opportunity to recapture revenue.
If you're publishing a paper magazine, chances are you are heavily into Adobe already. It would make sense to see what they're offering in terms of electronic distribution and DRM infrastructure to their magazine publishing customers. I'd be willing to bet they've got a solution targeted right at your kind of outfit, because you are hardly unique in your predicament.
If DRM isn't that critical a concern for you, you might think outside the magazine publisher's box and go right to social media. I know that a number of publications are offering Facebook apps, and again because you are hardly unique in your situation I'd bet there's a way to capture advertising revenue through a Facebook app. Going this route you probably won't be able to keep folks from copying chunks of text from your magazine for their own purposes; that could be an issue for some of your contributors. That said, it's so convenient for users that wholesale piracy of the latest stuff probably won't be a practical concern for you.
The argument over who's at fault entirely misses the point. With a little planning the officers could have searched the house without mounting a paramilitary style assault with a SWAT team. They could, for example, have entered the man's house while he was at work. That would have been a safe, predictable, and effective way of obtaining the evidence they needed. Instead the police chose a dangerous and unpredictable alternative.
There's no reason to believe the cops didn't announce themselves, but the instant they *do*, the clock is ticking. If the suspect actually *is* armed and hostile every second waiting increases the danger to the officers on the raid. That puts them in an automatic escalation mode. There's no way for officers put in this situation to distinguish between the case where the occupants aren't responding because they'are asleep, as in this case, or because they are preparing to repel the assault with force.
Ultimately the responsibility for the officer's death lies with the commander who ordered an assault because it was his automatic way of dealing with drug searches. A little thought could have reduced the danger to which his officers were exposed, not to mention anyone who happened to be in the house. A SWAT team is a powerful tool, and like any such tool fools can get enamored of the power and use it where a little finesse would be simpler, safer and more effective.
Nobody deserved to die in this situation, but somebody deserved to lose his job.
Well, as devil's advocate you actually made a pretty good case that there are too many such raids, and that sending SWAT teams in where there is no specific reason to is criminally negligent.
I agree with your sentiment, but it's not either/or. True, they should pardon him, and others less prominent than he, because prosecuting someone for his sexual orientation is an affront to justice as we now understand it. But nonetheless Turing was an exceptional human being, and exceptional human beings play a special role in changing attitudes.
Arguably, no other person did more to preserve liberty in the 20th C than Alan Turning, through his work at Bletchley Park. The ingratitude with which his nation treated him after that doesn't add to the injustice done to him, but the ingratitude of that treatment does throw the callousness and irrationality of that injustice into sharp relief. People can look at the injustice done to such a figure and feel shame, well before they are ready to feel shame for the treatment of a less gifted person.
Shame for the shabby maltreatment of heroes is the first step towards feeling shame for the maltreatment of ordinary people.
Those customers that are left, aren't stupid enough to buy a windows computer that can't run all the x86 programs they usually have?
So they'll buy an iPad that doesn't run those x86 programs either?
It's an irrelevant point. Preserving your software investment was a "value proposition" that helped keep people locked into windows, but it doesn't apply in the tablet world, where apps are smaller, simpler and *cheaper*. $199 is a cheap desktop app, and $1000/seat is common for business apps, $3000/seat is not unheard-of. But people don't buy tablets to run $3000/seat software, they buy them mostly to run browser-based software or apps that cost more like $3.99/seat.
If anything, I'd bet it's the association of Surface with Windows that turns people away from it. Tablet are about a direct manipulation experience: you see something onscreen, you reach out with your fingers to twiddle it and it responds immediately in an intuitive way. These are not qualities that people associate with Windows, which they associate with heavyweight, non-intuitive, and *expensive* apps. That's why Apple was better positioned to launch a tablet than Microsoft.
It's taken Microsoft a long time to wrap its head around the user experience thing, because unlike Apple they're not a company built on selling to end users. People use Microsoft products because somebody else decided they'd use them, the IT department for example. In pre-iPhone smartphones, Microsoft and handset manufacturers gave the *carriers* exactly what they wanted, which were phones that didn't undercut the carrier's expensive premium services. No voice dial for you, Sprint customer, it's a Sprint add-on. Oh, and if you want the pictures off your phone, send them through the carrier's "picture mail" (!?!?) service. Things were that way, not because the end-users wanted them that way, but to make the middle-man happy. The iPhone destroyed those kinds of business practices, leaving Microsoft with the image of the company that wouldn't let you do what you wanted with your device.
You totally missed the point. I'm saying you *don't* interrupt the sprint. You make the sprint long enough to get things done but short enough that changing business priorities get injected into the development process in a timely fashion.
A 1 week sprint is, in my opinion, almost always going to be too short. 30 days is almost always a reasonable sprint length, and as you say if something is *really* pressing you can always interrupt it. A one week sprint that you can interrupt is almost meaningless as a sprint, excepting of course bona fide crises (e.g. man-rated emergencies).
I second the nomination of Scrum, which complements agile development practices.
Scrum is about managing development priorities. You can't work efficiently if you keep changing priorities every day because nothing will ever get finished. On the other hand, if you *never* change development priorities until you've finished everything you set out to do, developers are happy but they might not be working on things the business needs or wants.
The truth is that businesses have to respond to change. A rival announces a new feature; the price of some related product or service changes dramatically; regulators threaten to fine your company for some reason; a PR scandal forces your CEO to get up and make public promises you'd never imagined. Things like these can change a business's priorities, and if your employer's priorities change, yours ought to as well. Just not so often you never manage to finish anything.
Scrum strikes a sensible balance between changing direction so often you never finish anything, and putting your head down and finishing things but then finding out your employer actually needed something else. Don't get me wrong, if you *can* keep the same priorities for months on end, you should. But in many situations you don't have that luxury. You have to respond to business changes, while at the same time finishing what you set out to accomplish.
No problem on the TL DR, but you raise an important point. You're absolutely right that a strongly typed language has some optimization advantages, but CPU is only one kind of resource. Optimizing CPU usage for a sequence of statements is a good thing, but that's simply not the bottleneck in scaling web services these days.
Node.js demonstrates this. Under the covers it uses polling (I presume) to ensure that the CPU keeps doing useful work as the load climbs, rather than spinning its wheels waiting for I/O. So instead of allocating a thread per request and stalling every single thread as it waits for the results of a database query, Node just goes down the list of queries with data returned and fires off a small event handler you write in javascript. I suppose it helps that the javascript engine Node uses is very efficient (for Javascript), but there's more to gain in efficiently CPU usage by managing *other* resources efficiently than there is by compiler optimizations -- at least for *typical* web applications, where the task is to glue back end resources like databases to front end applications in HTML.
I dunno. I'm pretty liberal myself, and I've supported same sex marriage since even before it was legal here in Massachusetts. I see no reason to boycott an author *just because I disagree with him*.
Now I could perhaps see some point in it if it were ten years ago, and I'd be sending money to an anti-gay marriage activist who would turn around and spend it on perpetuating an injustice. But as Card says, it's a moot point now. Opposition to gay marriage has been defeated with stunning rapidity, and as the change is implemented people will discover that dire predictions for the institution of marriage won't come true. In twenty years young people will wonder what all the fuss was about.
So the only point of a boycott NOW is to punish Card for being wrong. I suppose there's something in that, but I can't get all that excited about it; it smacks of being a bad winner. And if we punish people on our right for being wrong, shouldn't we also punish people on our left? Shall we boycott Frederik Pohl for being a former communist? Granted, he's not really much to *my* left, but I've never advocated nationalizing private businesses, I think that's morally wrong.
Now I don't care a bit about the movie, it can sink without a trace as far as I'm concerned, but to be totally consistent in the Jihad Against Card we'd *also* have to target the book; to shame people who buy the book and stores that sell the book. Against the value of stroking our righteous indignation against Card for his past misdeeds, we have to set the loss the the public of what is a landmark literary work. It's hard to name a science fiction novel in the past thirty or forty years of greater literary importance. Perhaps THE DISPOSESSED, GATEWAY, THE LEFT HAND OF DARKNESS, DO ANDROIDS DREAM OF ELECTRIC SHEEP, or TAU ZERO. Just a handful, and few of them are as accessible as ENDER'S GAME, which can be read as a straight up adventure story or bildungsroman. Accessible it may be, but ENDER'S GAME does something very interesting and ambitious: it explores the very nature of moral responsibility.
If there is a moral imperative to make the ENDER'S GAME movie into a commercial failure, then why wouldn't the *same* imperative must apply equally to the novel? And if we forced ENDER'S GAME out of the bookstores, we'd be depriving those future people (who have no idea what the fuss about same sex marriage was about) of an important science fiction novel.
You're asking for the classic apples to oranges comparison here.
Node.js is all about scaling the number of requests/second -- about minimizing the number of boxen you need to serve thousands of requests per second. By using polling instead of threads (under the covers) and asynchronous event handling (above the covers), it becomes simple to respond to high volumes of requests without allocating huge volumes of resources.
But requests/second is only one dimension of scalability. There is management of the infrastructure. There is security (the number of Node tutorials which completely omit this is shocking). There is complexity (much of which in Node.js is pushed to the client side). There are features (e.g. the messaging and timer services in Java EE).
The buzz over Node.js reminds me of the buzz over Ruby on Rails a few years back. RoR also introduced an elegant new programming paradigm -- configuration by convention. People were amazed that the could field a simple example app without having to write XML configuration files for the ORM layer. Look! It creates all CRUD interfaces for me! But in the end those tasks really aren't that challenging for an expert programmer; they're more like sand in the gears when you're starting up a project. So while RoR remains a good tool for certain kinds of web apps, it's nowhere near as revolutionary as it seemed at the time, and it has little penetration in the enterprise market. It sees to me that most of the joy in Node.js is likely to be on the front end of the project, but in the long tail of the project you're still going to have a lot of drudge work, especially where you have to roll your own enterprise features.
Which is not to say Node.js isn't brilliant. It appeals to the old Unix man in me, because it does one thing really well. It's a superb piece of middle-ware glue. It makes exposing back end services like databases to RESTful web clients a snap, and if you've got to do that on a massive scale, where by "massive scale" I mean by retail web standards where you have to handle tens of thousands of simultaneous connections. For web applications where you don't have to integrate with a lot of back end enterprise systems and where there's a heavy emphasis on a rich HTML/CSS UI, Node.js is an elegant solution that reduces the information overload on the development team by taking advantage of the Javascript expertise they're bound to have.
My oppinion is that Javascript is not bad as a scripting language, but we are abusing it and twisting it beyond its original purpose. The main issue is actually that Javascript is too flexible. Untyped code has an habit of hiding mistakes in hard-to-debug ways. But once you add types to Javascript, it's not Javascript anymore.
A couple of points. First, the argument you're making is for static -- i.e. compile-time -- semantic checking. I was hearing the very same argument thirty years ago among people who advocated Pascal over C; on paper it's sound, but decades of practice have convinced me that static checking, while probably helpful, is not as efficacious as it seems like it should be. After all, you *still* run into mishandled exceptions in Java, and many Java programmers do an end-run around around much of the compile-time restrictions by using runtime exceptions; in fact wrapping low-level checked exceptions in runtime exceptions are a feature of some frameworks. It's hard to get programmers out of the mindset that a core dump, or an unhandled exception, is some kind of serious calamity. You don't want them in production code of course, but they're far less calamitous than continuing processing with bad data. The place to catch those problems is in testing.
As for the other kind of compile-time problem, handing an object to a routine that expects an interface the object does not support, what scripting languages like Python have shown is that it's not that big of a problem. Large, sophisticated systems programs have been written in Python, which lacks precisely this kind of checking.
I'm very comfortable with Java, but there is something about the design of the language and its core libraries which encourages over-engineering. For example, itis possible to do asynchronous http handling in Java EE, like you do in Node.js, but in Node.js you simply create a non-blocking event handler for every case you want to handle. In Java EE, if memory serves, you create a ServletContextListener with a Queue member, and put that member in the servlet context. Then in your servlet you create an AsyncContext and put it in the Queue. None of this is as complicated as it sounds, but it only covers the case when you want to keep a socket open to the client, like when you're doing Comet. If you want to conserve resources by serving your I/O requests using polling rather than blocking threads (the primary Node.js use case), you've got to use java.nio, which can get complicated.
On paper, designing programs in Java is a cinch with Java's rich OO features. Any reasonably competent programmer can quickly learn enough to demonstrate facility with the *features* of the language. In practice as a programs required feature set grows, the number of classes and interfaces explodes, unless you are a very talented software designer.
While it's true most Javascript programmers write simple onload and onclick handlers, this doesn't make Javascript a toy language. While its object-oriented features are relatively primitive, its functional programming features are quite sophisticated, and this turns out to be just the thing when you are writing sophisticated event handlers, as in Node.js. Expert Javascript programming is about implementing higher order functions which return closures, something that current versions of Java can't do (Java SE8 is getting lambda expressions, so this might change). Functional programming is all about getting a single transformation of inputs to outputs correct; it feels *contained* -- that is to say you don't need to think a lot about the context in which your code runs. Programming in Java is often an exercise in information overload, as it typically involves mastering the nuances of multiple complex libraries and frameworks so you can fit them together properly.
So, I saw a *car* run a red light today. Strangely, that does not cause me to question the right of automobile drivers to use the roads.
I agree with most of your other points, although a turn signal isn't really practical. I use hand signals (although most drivers don't seem to understand them, so I signal a right turn with my right hand). I stop at the stop-line, I don't weave between cars, and in general obey all the rules that apply to slower moving vehicles. I do claim a lane when I travel in traffic, although I pull over regularly (when it is safe) to let trailing cars pass. That's not the law, it's just common courtesy.
Security is hard. General-knowledge techies think they're much better at security than their masters, but I have my doubts. Techies don't always understand the value of assets and nature of threats to those assets. And they often overestimate their knowledge of system vulnerabilities. For example many techies think you can turn a computer into a blank slate by erasing the hard drive, but there have been demonstrations of firmware based malware. Just last year a security researcher created a proof-of-concept worm that stores itself in a computer's BIOS and the flash memory of attached devices and PCI cards. It has stealth features that make it virtually undetectable, except by pulling the flash chips and dumping their contents. If you *were* infected by a worm like this, and you wanted to eradicate it, you would *have* to physically destroy any attached device which had its own flash memory, including cameras, optical drives, and possibly even printers . Eradicating all physical traces is probably more than is needed to deactivate the worm, but it's a subtle point.
Another subtle point is that if you are worried about almost non-detectable malware, you have no assurance that the new equipment you are buying to replace the old stuff isn't factory infected. What that probably means is that trying to ensure you have a 100% guaranteed clean slate isn't cost effective for agencies, unless perhaps they are high value targets (e.g. NSA, CIA, some of the DoD). What to do instead isn't obvious. The simplistic model is you start with a clean slate and you prevent bad stuff from being introduced to your systems. That model doesn't work if you can't ensure your stuff is clean from the start, and if malware can enter your systems through channels you'd never imagined (e.g. some kind of innocuous USB device).
Destroying the equipment is almost certainly overkill in this case, but I can see why this particular agency might have chosen to do so. Given their role in advancing American competitiveness, they're probably hypersensitive to issues of industrial espionage and Advanced Persistent Threats (APT). According to the article the agency's CIO thought he was dealing with some sort of Stuxnet-like attack, which in hindsight doesn't seem to be the case.
As usual the /. summary is garbage. The agency spent 2.7 million to respond to the threat, but they didn't spend 2.7 million on hammer wielding contractors.Only $4,300 went to that, or 0.15% of the total expenditure on the event. The bulk of the rest of the money went to obtaining replacement services while their servers were offline, paying security investigators to track down the infection they did have, and developing a long term response to malware.
The physical destruction of the equipment was almost certainly overkill, as was bringing down their mail servers because they were transferrig infected emails. But one thing you have to admit is that the agency's response was swift and decisive.
Having led development teams with native-born Indian engineers on them, I can confirm that Indian cultural diversity notwithstanding, deference to superiors is a big deal with many people brought up there. That's neither good, nor bad. It's just different. Where problems arise is when people don't recognize that there are differences and fail take those differences into account.
As an American, I don't feel insulted when a subordinate questions my ideas, in fact I rely on them challenging me. What took me awhile to figure out was that my Indian employees wouldn't stand up and contradict me, especially in public. In a American that would be cowardly, but that's because we communicate in what amounts to be a different social language from Indians. I soon learned that you have to manage employees from deferential cultures differently; you've got to spend a lot of personal time together having quiet chats, maybe go out after work for a couple of beers. And you have to recalibrate your trouble sensors when dealing with deferential employees. If you give them something resembling an order, if they do anything short of hopping right to it with open enthusiasm, it's time to have a quiet, tactfully executed one-on-one.
This is not a worse way of doing things, it's just different, and it has its advantages and disadvantages. For me the toughest thing was I had to be careful about thinking out loud -- at least at first -- because my guys took every that came out of my mouth so seriously. At first, I found my Indian subordinates to be frustratingly passive. They found me (no doubt) to be overbearing, insensitive, rash and pig-headed. This was all just miscommunication, because we all were acting and interpreting each others' actions through the lenses of different cultural conventions. In the end, we did what intelligent people of different cultures do when working with each other: we developed a way of doing things that combined what we felt was the best of both cultures.
And that's an important lesson: people aren't culturally programmed automatons. We are capable of thinking and adapting. People in an egalitarian culture are perfectly capable of coming together and working coherently as a team, although the process may look ugly and chaotic to outsiders. People in cultures with deference to elders are perfectly capable of reporting unwelcome news to a superior.
So if a junior pilot didn't communicate an emergency situation to a senior pilot, *then somebody on that team screwed up*. They weren't doomed to crash by cultural programming. There may be nuances of their culture which contributed to the disaster, but that's bound to be true of human error in every culture.
I won't go so far as to say that *all* cultural differences are superficial. But I think many differences are more superficial than a casual outsider might suspect. That outsider might look at something like the reluctance of a subordinate to question a superior's instructions and assume that the subordinate *can't*. That's simply not true. On one level, the shared cultural understanding of the subordinate and the boss provides them with ways of communication that escape the outsider's understanding. But more importantly, people aren't mindless cultural automatons. If his boss is about to stall your plane on the approach to the runway, I don't think a Korean co-pilot is simply going to stand by silently. I suppose it is possible that he might be inclined to wait a few seconds longer than an American co-pilot, but if that endangers the plane then that is a mistake, period. A Korean airline is perfectly capable of training the co-pilots to report problems promptly, just as an American airline can train co-pilots to execute the commander's orders promptly without engaging in an impromptu debate.
Not really discrimination if there are reasons. Old people are in physical and mental decline. Old people also aren't a minority: just like it's OK for a female manager to prefer to hire women, or a black manager to prefer blacks, the young can prefer their own kind. Sorry, time to die.
I've got news for you sonny -- we're *all* in physical and mental decline. If you think you are going to live forever, think again.
But the decline goes at different rates for each of us, it starts from different points, and is offset (in most cases) by gains in maturity, experience, and wisdom. So the bottom line is you can't make any useful generalization whatsoever about the ability of a fifty year-old to do programming vs the ability of a 25 year-old. It depends on all the things that add up to that unique person.
This is what's broken about bigoted thinking. It reduces people to some kind of ill-conceived average for their "group", when it ought to be evaluating them as individuals. Back in the 90s there was a controversial book called "The Bell Curve" which pointed out that there was a racial difference in IQs between blacks and whites, and made a number of (stupid) policy recommendations based on that difference. The inevitable shit-storm followed, in which the validity of IQ tests was questioned (in some cases with good reason), but lost in the shuffle was a simple mathematical fact: even if we assume that IQ tests are a perfect, unbiased measure of mental capability, and accept the racial differences in scores as measuring something real, those aggregate differences give almost no useful guidance in making decisions about *individuals*. That's because under those assumptions, something like 40% of blacks are smarter than 50% of whites. When you're looking for very high scoring individuals, they occur as statistical flukes in both groups.
Where that leaves you is that when intelligence is an important factor in judging a candidate for something, *especially* if you're looking for high scoring individuals, you have to judge individuals on their own merits. Skin color is at best statistically useless as a selection filter, at worst self-defeating.
The analogy holds for age differences. Even if we grant that 25 year-olds are on average more capable programmers than 50 year-olds (which is doubtful), it nonetheless remains that the vast majority of 25 year-old programmers are mediocre. It may be true that mental decay has shifted some fifty year-olds from the high performer category to the mediocre category, but it remains true that high performers are statistical flukes in either group. So gray hair has no value as a filter if you are looking for *good* programmers. They're a fluke in any category.
By the way, about older people being "minorities" -- they are effectively so *for purposes of anti-discrimination laws*. The term of art you are looking for is "protected class". So the good news for all you young, white American males who resent the legal protections minorities get is that all you have to do is survive until you are forty and you'll be protected by the Age Discrimination in Employment Act of 1967.
It's not fear of nuclear power that makes it uneconomical. It's cheap fossil fuels. Back in the 70s it was the Saudis opening the oil spigot; today it's fracking natural gas and of course coal.
Which is not to say irrational fear hasn't created nuclear problems -- particularly when it comes to developing long term storage facilities for high level radioactive waste. We also give fossil fuels a break on externalized costs because we're familiar with the and therefore fear them less than we probably ought. But still, it's hard to supplant a mature, entrenched, *cheap* technology.
Well, it depends. You have to look at each situation individually to see what is at stake. If you know that Anne Frank's family is hiding in the office annex, you obviously keep your mouth shut.
In a case like this, it's important to remember that civil disobedience is most effective when it forces the government to mete out a wildly unpopular punishment. What the government has done is bound to be extremely unpopular because it has come perilously close to passing a secret law.
People think they have fourth amendment protections for most of this data, but long established precedent (Smith v. Maryland) is that there is no Constitutional expectation of privacy for metadata on phone calls. When Congress weakened *statutory* protections against collecting call metadata, American citizens *believed* their calling data was still protected by the Constitution. Nobody has bothered to disabuse them of this idea; not Congress (who despite their current posturing passed the law and authorized the program) nor the Obama administration (their posturing on "transparency" and "accountability" notwithstanding). They knew that the majority of Americans had no idea the changes in the law technically allowed the government to run a program like PRISM.
The exposure of this bit of flim-flammery makes Snowden standing up and outing himself incredibly powerful. His doing that means that this issue will *not* die down anytime soon. Look at how long the Bradley Manning case has dragged on, and *this* one, rightly or wrongly, may prove to be far more powerful in the public imagination. I think Snowden might have been morally justified in laying low if he thought he could get away with it, but his outing of himself will keep this issue alive through the next election cycle at least. That could deal a far more serious blow to the PRISM program than quietly leaking it's existence. The cost of that greater impact is that Snowden definitely loses his job, and he faces prosecution and legal punishments.
OK, now you are in a position where the burden of proof is on you.
It's legitimate to look at somebody's evidence and say, "it doesn't convince me." It's sometimes *also* legitimate to say "I've seen enough evidence to convince myself beyond a reasonable doubt, so I won't bother thinking about your evidence; otherwise you'd have to take the time to examine the workings of every proposed perpetual motion machine.
What you can't do is say, "I'll dismiss your evidence because there's a possibility you have a conflict of interest." Everyone *always* has a vested interest in any position they've taken in the past. If you go there, if you call a man a liar because he has stated a professional opinion you disagree with, it's *your* responsibility to show evidence that lying has taken place. If you can't, STFU.
I actually subscribe to the Kindle edition of the Boston Globe -- a newspaper I don't particularly like -- precisely because I think somebody need to pay for things like local investigative reporting.
I don't suppose it could be that they were making shit up, and now find it more difficult to do so with video evidence? Could this be extrapolated to suggest that a majority of "resisting arrest" charges are entirely bogus?
Which must be why the patrolmen's union wants them as standard equipment. Really, you missed your chance to make this an anti-union rant a well as an anti-cop rant.
I developed a very serious mobile app back way in the mid-90s for public health and disease surveillance. Let me tell you from experience why an app that people rely upon every day for critical work is no way to strike it rich. People *need* a lot of support for that kind of app. Support equals labor, and labor is expensive. Businesses with high expenses don't get rich unless they can command huge prices.
When smartphones came along, my partner used to gnash his teeth at stories of developers scoring windfalls with ringtones or stupid little games, and here we were doing *important* work and only making an OK living. I pointed out that if somebody pays $1.99 for something to amuse himself, he's never going to call tech support. When something represents a total investment of fifty to a hundred thousand dollars in hardware, software and system integration services, he damn well is going to call tech support. But 50K isn't really that much money if you include hardware, third party software licenses, QC'ing the client's existing data and converting it, training the administrators and end uses, and negotiating with IT gatekeepers. That's what you have to face when you do work that everyone agrees is important. Yes, people are willing to spend real money on important problems, but they also subject you to higher standards, intense scrutiny, and exacting ongoing demands, and those things eat into your profits. And the only way to get rich in business is to generate profits -- and salary you pay yourself for your labor IS AN EXPENSE.
That's why the $1.99 app somebody buys on a whim to amuse himself is bound to be more profitable than *important* software that somebody relies on to do something important -- no matter how much you charge for that software. There are exceptions to this rule, of course. Software that is a cheaper, more convenient alternative to something someone already has (e.g. Skype) is practical because what it does may be important, but that software itself is at first dispensable.
Look at the vast amounts of cash going into develop "social media"; it is no accident that most of it goes to support is so trivia. Trivia is profitable. It's easier to try radical new things in the trivial. A lot more people have an early adopter stance towards a service like Facebook than they do to towards things they regard as critical. They take convincing and hand-holding. That's why something like Google Wave couldn't get off the ground, you have to approach something as important as collaboration much more conservatively, usually working around how people already do things (e.g. Sharepoint).