Repurposing missiles as ship killers? You have heard the term "guided missile cruiser", haven't you? The first purpose built guided missile cruisers were put in service in the early 80s, and could sink ships at 10x the range the big guns on the New Jersey could hit. The Harpoon anti-ship missile went into service in the 70s.
Now I understand the big criticism of the Zumwalt is that it has limited anti-ship capability; but it's supposed to be a destroyer. Destroyers traditionally play mainly anti-submarine and anti-aircraft roles, and in the US Navy mount modest 5" guns for anti-ship use. The Zumwalt's gus are actually 6.1 inches and have considerably longer range -- if they work as advertised. The idea of making it more potent in the anti-ship role would fall into the F35 trap: building cost-is-no-objecdt, do-everything wonder-weapons.
Well, let's assume that malware authors are economically rational. If they demand millions of dollars almost nobody will pay. If they demand a penny they'll get lots of people paying, but they won't net much. There's an optimum ransom price between the extremes where they maximize their revenue, and it's likely to be relatively low -- in the hundreds of dollars -- rather than the tens of thousands of dollars. For one thing any organizations has a threshold under which managers can spend with their own discretion; going over that level is apt to make getting paid a lot quicker. Quick in finance is a very important thing; and it's an even more important thing when it comes to banditry. The longer something goes on the more likely you'll get caught or people will find a way around your scheme.
Now if it were me, I'd set a series of dates after which the ransom goes up, and promptly respond to anyone who paid up early. It's like selling anything else; if you're seen as reliable and responsive people are more likely to give you money; they're also more likely to give you money if they think they'll have to pay you more later.
Well, as you probably guessed I've been around a long time, and this idea comes up over and over again, and it never takes off, and for a good reason. Programming is hard; it's deeply tied to logical reasoning, which in turn is tied to language and notation. Having visual representations as an adjunct often does make reasoning easier, but having only visual representations does not.
Through the years I've met a number of people who claim to be "visual thinkers", but in fact I don't think most people who make that claim are particularly good at visual thinking. What they really mean is they want things kept simple so they don't have to work that hard; when confronted with visual subtlety or complexity they're just as lost as when they are confronted with linguistic complexity. Basically they're mentally lazy but prefer to think of themselves as misunderstood.
Now there are people who are great visual thinkers. Any decent graphic designer is bound to be a strong visual thinker. But oddly enough it's not graphic designers who make this claim. It's usually managers who don't have the patience to read through pages of text; but they don't have the patience to wade through pages of diagrams, either.
The Comprehensive Test Ban Treaty was adopted by the UN General Assembly in 1996, but won't come into force until 44 specific nations with nuclear technology capabilities have ratified the treaty. At present there are eight nations on the list who have not ratified the treaty, including the United States. The US, however, is a signatory to the treaty, and has not conducted a nuclear test since 1992.
So the US abides by the CTBT as a matter of policy, even though the treaty is not in force, and the Obama administration has in the past indicated that it wants to ratify the treaty, although that won't happen with this Senate.
The reason it's smart policy to promote the adoption of the CTBT is that it would discourage nuclear proliferation, and we don't need to perform testing. We already have enough data from half a century of active testing to ensure our bombs go boom.
This is a situation where Isaac's Asimov's ideas about psychohistory are worth considering. Mass murder is an aberrant, rare behavior and predicting it in an individual or even a modest population is a very questionable thing. But it's quite predictable when you're talking about very large populations.
Obama has proposed letting in 10,000 Syrian refugees -- not "millions". How will that effect your chance of being killed in a mass murder? Will that effect be significant?
Well, let's start with the base rate of mass attacks in the US. For purposes of discussion, lets call a "mass attack" as an attack on at least four people. Just in shootings, there have been 353 mass shooting in the US in 2015, and we're on day 340 of 2015. So it's fair to say that mass attacks are a daily occurrence in America. However spread across the large pool of potential victims, any individual's chance of being killed in a mass attack is very low -- so low that in practice we treat the situation as not urgent enough to do anything about.
Three hundred million is a population large enough to predict with certainty that it contains a substantial number of mass murderers. 10,000 is not. So any fear of letting in ten thousand refugees is based on an implicit belief that there is an extraordinarily high proportion of mass murderers in that population, or that the base rate of mass murders in the US is lower than it is, or both.
Let's examine the belief that a high proportion of Syrian refugees are mass murderers. Now what we know about most terrorists, at least the kind that operate across international lines, tend to be from comfortable or privileged backgrounds -- not refugees. This was the case for Santa Barbara shooter Tashfeen Malik, who like many of the 9/11 hijackers had an comfortable, uneventful upbringing and a university degree in a technical field. Refugees who commit terrorism tend to operate in-country (e.g. Al Aqsa Martyr's Brigades) against the immediate source of their displacement. So the idea that a Syrian refugees will commit acts of terror on behalf of ISIS is pretty far-fetched -- if we're talking only 10,000 of them. If we were talking a million of them it's not something we could discount, and if we were talking a hundred million it'd be a virtual certainty, as vanishingly unlikely as any individual taking this path would be.
So what this leaves us with in practical terms is the possibility that an ISIS operative may somehow sneak in amongst the refugees. This is something the Europeans definitely can't rule out. In fact two of the nine November 13 attackers were in the EU on faked Syrian refugee papers. However it's important to note three things: (1) had they not been in the EU their places would be certain to have been taken by indigenous participants; (2) Europe is dealing with far more refugees: 750,000 by some estimates; (3) the US program would only let in people who have been through a two-year long vetting process; in Europe they're just showing up and then have to be characterized after the fact. Even so let's assume one or two terrorists make it in through the program; killing the entire program won't stop ISIS from getting people in through other methods, or radicalizing people who are already here, so keeping those guys out will neither stop ISIS or make a dent in the base rate of mass attacks in the US.
What keeping refugees will do is put ISIS in a more advantageous position. ISIS actually supports the position of people who don't to let Syrian refugees into the US, because that works for them. Remember the famous picture of the dead toddler washed up on the European beach? That saturated the ISIS controlled media in the areas they control, because that's what ISIS wants people leaving their territory to face. Muslims fleeing from ISIS territory demolishes their claim of having established a legitimate new caliphate. It also undermines them in more practical ways -- they've had e
Ever notice how whenever there's a Star Trek away mission, if it's not on a planet with fiberglass rocks it's on a planet that looks like Southern California? If you know anything about natural history, you not only can identify the plants in the scene as specific Earth plants, but you can place the site within a distinctive band of montane chaparral about 250 miles long by 50 miles wide running along the Transverse Range north of LA, and nowhere else on Earth.
That's understandable, since a TV show needs an affordable location shoot, but there's no reason for books to do the same thing; yet authors assume that the present flora of Earth is some kind of universal template -- that all planets must have landscapes featuring flowers, and grass, and trees, but these are all recent developments in the evolution of plants. If you landing on Earth at some random time in the past 425 million years in which there have been plants, chances are you wouldn't see any flowers, grass, or trees. The dinosaurs roamed a landscape where the largest plants were giant ferns. When you land on an alien planet, everything is bound to be alien and disorienting, starting with the division of life into plants and animals, which is Earth-specific.
Even so, I can accept that coming up with a distinct and vivid alien biome is too much work, so I'll settle on getting one thing right: gravity. It bothers me when characters in a story land on planets and the surface gravity seems to be exactly 1g or so close it's not noticeable. That's a heck of a coincidence, and if the characters land on many planets one of the first and biggest things they ought to notice is how the difference in gravity affects them. Granted if we are talking about colonized planets people would no doubt prefer planets with surface gravities near 1g, but even a few percent off normal is going to have a big impact on what it feels like to work on that planet.
Along the same vein, differences in air pressure always bother me. If there is some kind of time-travel portal there ought to be a hell of a wind passing through because of differences in air pressure, which varies with the weather. If you use a time machine that moves through time, then your ears should pop (as should Captain Kirk's after he uses the transporter).
And while we're at it, where does Iron Man store the reaction mass for his boot jets?
Almost anyone can become a competent programmer. They need the right teaching and opportunity, but it's definitely something that can be learned.
A lot of complex programming tasks are less about software engineering and more about knowledge of the application. Business knowledge, systems knowledge, that sort of thing. Stuff that can be learned.
The ability to learn is the real key to it.
Well, while I mostly agree with what you're saying, I think a lot depends on what your standard of "competence" is.
Suppose the standard is this: take a clearly defined task and code a solution in a reasonably acceptable style using the first approach that pops into your head. Well, anyone of average intelligence could be trained to do that, and I think this the kind of conception of competence that a lot of HR departments use. That's why they like certifications; certifications measure exactly this kind of competence: whether you can regurgitate what you've been taught to do.
But I think it's the wrong way of thinking about programming competence.
While the first approach that pops into your head is likely the right one if it does the job, I think a "competent" programmer needs to be able to come up with alternative approaches, especially when it doesn't look like the obvious ones work. This is where I think many "competent" programmers find themselves out of their depth. Don't get me wrong, there is a need for people who can do the obvious thing adequately, or implement a solution when the hard thinking has already been done for them. And goodness knows many schools don't seem to be able to turn out enough graduates who can tell the teacher what he expected to hear. But even if most schools can't meet that target, it's still an unacceptably low standard. Schools need to do more to foster creativity.
And I think creativity can be fostered. The only reason most people believe that someone has to be born creative is that so many schools are so successful at snuffing out any kind of unconventional thinking at such an early age. Teaching programming can help, if you're teaching students to tackle tough problems, problems where they have to face round after round of failure. But it's not programming that's the point; that's just a vehicle. It could be art, or creative writing, or music; anything that teaches persistence and flexibility when your first crack at something isn't good enough.
too bad that each letter in each of those three words probably requires (UNICODE) 2 bytes of 4-5 digits worth of numbers PER CHARACTER to store
Well, that assumes you use a poorly chosen unicode encoding. In UTF8 you only need one byte per character for these particular strings. In fact you don't need unicode at all; since the words only use lowercase latin alphabet you can store them as just five bits per character.
But even that's a lot more space than you can get away with for storage. You don't need to store the string at all; since the triplets are made up from words selected from a 40,000 word dictionary, you can simply store a three-tuple of indices into that dictionary (x1, x2, x3), where each index takes 16 bits [log2(40,000) < 15.29]. So the total storage you would need for an address is 48 bits, or six bytes, which is less than it would take to store a lat/lon coordinate as a pair of single precision floating point numbers (32 bits each x 2 = 64 bits = 8 bytes)
Well, I don't know whether it's inborn, although if sometimes seems this way. But without taking a position on whether programmers are born or made, there are skills and habits involved with being a good programmer that would be useful to anyone. That said, however, I'm not convinced that these skills and habits are what the programming education movement is teaching. I am convinced that coding isn't the only way to gain those things.
What a really skillful programmer does that special is transform problems from something it isn't clear how to solve into other problems that are readily solvable. That takes a peculiar mix of discipline and imagination which simply teaching coding per se will not foster.
The server wound up getting exploited through a remote hole in Apache long before any of my scripts could be a problem. Besides, they all ran as a relatively unprivileged user.
Well, in the early days that would likely have been the case; the vulnerabilities in the Apache server would have presented a better-known target than your code, people weren't in the habit of keeping up with security updates, and automated tools for attacking website specific code didn't exist yet. Today if you did that then flaws in your code would be much more likely to be the cause.
I'm sure you know that the fact that your code runs unprivileged doesn't really protect you or your users, especially these days, but it's worth pointing that out to others. Yes, it does remove certain vulnerabilities, but it doesn't stop things like SQL injection or cross-site scripting or request forgery.
Many years ago a friend of mine had a dog that was hit by a car and had it's leg crushed. He put it in a box and took it to the local animal hospital in the super-wealthy town he lived in, accompanied by his son and his son's best friend. That was a mistake. He was expecting the dog to be put down, but the vet instead told him -- with the kids right there -- that the leg could be saved with an experimental microsurgical procedure. Well, that was that; it was either fork over the equivalent of $20,000 in 2015 dollars or be known around the neighborhood as the rich guy who was too cheap to save the family pet's leg.
When he told me this story he shook his head, and then recounted the time when he was growing up on a ranch and his dog was hit by a car. His dad came out, looked at the dog and said, "Too bad, that was a good dog. Go fetch the shotgun."
While I strongly agree with the argument that PHP's large target footprint has something to do with its reputation for insecurity, I can't help but wonder whether the architectural similarities of typical PHP, ColdFusion and ASP.NET have something to do with the tendencies of some programmers to produce vulnerable code with them. If you squint, they all have a strong family resemblance to each other: you mix language-specific procedural markup with HTML, which is processed on a server and returned as plain HTML to the browser.
Note that I'm not saying PHP is inherently insecure, but I can think of three reasons why this approach might tend to encourage insecure practices. The first is the way programmers, particularly novice programmers, tend to be introduced to such systems. This is a pet peeve of mine; instructors try to sell students on how easy it is to do things so they show students the simplest way of producing a particular result -- not the way that a proficient programmer should produce that result. The message is "look at how easy it is to make a dynamic website with X!" The details of what you need to do to do things like sanitizing input really clutter that message up; especially in the case of these template-y languages where one of the chief selling points is that they're incremental on top of the HTML you need to know anyway.
It's interesting to contrast something like these systems to JSP, which can be used in exactly the same way except that programmers are taught early on that this "model 1" approach is for wimps who can't handle MVC. Java web apps tend to be grossly over-architected; PHP web apps -- at least the ones I've looked at -- tend to be under-architected, with lots of code replicated across many files which should be centralized in some kind of library. That's the second reason I can think why PHP apps might tend to be insecure: under-designed systems mean you have more places where you have to implement some design policy, or where a "temporary" bit of code that does something like build a SQL query from unchecked user input might slip through into production code. It's not the fault of the language per se; it's programmers reproducing the simplest way they were taught to do something over and over again rather than taking the time to refactor their work so that maintaining and securing it is a manageable task.
The third reason I can think of is that these kinds of systems are so easy for someone who doesn't know what he's doing to tweak in the field. I've done it myself; if you have a basic knowledge of HTML, have ever used a programming language, and know how to use "grep" you can find the bit of PHP that produces a particular output and tweak it to your liking without being a PHP programmer. That means that code that ships secure might not remain so in the field.
Anyhow, I don't know enough about PHP per se to say whether it is inherently insecure in some way, but what I've seen leads me to think that some of the problems at least may be an unwanted side effect of ease of use and learning. There's a world of difference between a PHP system generated by a skilled and conscientious programmer and someone who knows a little HTML and picks up a little PHP to add to that. Fortunately this kind of hacked-up HTML website is looking increasingly archaic these days; if you look at RESTful PHP code it looks pretty much like RESTful interfaces done in any other scripting language. It doesn't have the sprawl I tend to associate with PHP web apps.
This only looks hard because of a mental block people have about stuff that doesn't have a gui. In reality it's way often easier to copy and paste into a terminal window -- doing obvious substitutions for things like "www.example.com" -- than it is to try to read some gui designer's mind.
You don't have to understand everything "git clone" does, any more than you have to understanding everything that happens behind the scenes when you click a button.
People with the kinds of jobs that require a physical presence often don't have hobbies or pasttimes that are conducive to working on while riding a bus, unless the bus makes accommodations for tieing fly's, reloading ammunition, or working on cars while in transit.
You have a strange ideas about people's hobbies. I'm an engineer but I work on cars and fish. And plenty of people who do manual labor play videogames.
I'm with you on the closed-mindedness of people in these debates, but to be fair if you don't have the discussion after a recent mass shooting, when can you have it? If you count any murder in which there were four or more victims there have been 353 mass shootings this year; on average more than one a day. The San Bernadino shootings were the second mass shooting on that day. There really isn't time to process one mass shooting before we're on to the next.
Of course this is something of a self-correcting problem, in that mass shootings with only a half dozen victims or so don't make the national news anymore. The San Bernadino event is the tenth shooting with ten or more victims this year, which works out to one a month.
Basically the patent describes a time division wireless networking scheme in which certain nodes orchestrate transmission and receiving time slots assigned to adjacent nodes. The claimed benefits of this scheme amount to these: bandwidth can be allocated to nodes dynamically, and nodes can extend battery life by turning off their receivers when it's not their turn to receive data. I have no strong opinions as to whether the networking scheme as so vaguely described in the patent is original enough to be patented, but the complaint is a different matter. It appears that Atlas IP LLC appears claiming that any system in which devices are polled and in which the devices may not be transmitting or receiving at any time infringes on this patent. If that is what the patent means, then clearly it's too obvious to be "original".
I'm addressing the point that time spent waiting for the bus equal time wasted. That's not the case any longer, even if you aren't being paid for the time. The hedonic calculus of driving vs. public transit isn't what it used to be in the pre-mobile Internet days. It used to be a choice between spending say 45 minutes doing something you didn't want to do (driving) vs. spending 90 minutes doing something you didn't want to do (riding transit). Obviously shorter was better.
Now on your transit commute (and some day soon in your computer-driven car) you can be doing a lot of the stuff you'd have been doing if your were sitting around your house: reading, shopping, blogging, playing games. That's just as true for a welder taking public transit as it is for a consulting software engineer. It is true as a consultant I have the option of doing paid work, and that's nice. The flip side is people expect you to work all the time.
I've looked up the methodologies used to rank states by corruption; and it's more complicated than you'd think at first.
The top six states by the number of convicted officials (the most commonly used ranking metric) are in order: New York, California, Illinois, Florida, Pennsylvania, then Texas. Note carefully, however, that the top six states by population are in order: California, Texas, Florida, New York, Illinois, and Pennsylvania. It's no surprise that by raw number of convictions that New York tops the list and Vermont is at the bottom; New York has 32x the population, and thus has proportionally more government officials. If the probabilities of an official being corrupt were equal you'd expect more convictions in New York than Vermont.
Things get a bit more interesting when you look at convicted officials per capita. Then the top five corrupt states are, in order: Louisiana, Mississippi, Alaska, South Dakota, then North Dakota. So the states with the most corruption convictions per capita are small-to-middle sized states; the outliers are Illinois, a big state ranking at #6 in per capita convictions, then Vermont and New Hampshire: small states that rank near the bottom in per capita convictions.
Even that doesn't tell an entirely accurate story, because convictions depend on having a government which goes after corrupt officials. For example my state ranks #22 by per capita corruption convictions, but if you go by local reporter estimates of state government corruption it ranks as the least corrupt state, and I think I know the reason for this discrepancy. I've done business with state governments around the country and the kind of cozy relationships between officials and vendors which are the normal way of doing business in many states just don't happen here, because government employees assume they're being watched. On the other side I've seen states where people hate government, but seem to tolerate sloppy or even downright corrupt practices, almost as if having their preconceptions about government confirmed made up for having their tax dollars misspent.
We can't seem to build high-speed rail in the US, which is a proven technology.
Well you put your finger on the problem right there. We Americans have a novelty fetish; we're the only country that could go from putting our first man in orbit to landing a man on the Moon in seven years, then totally lose interest in manned spaceflight. The fact that other countries have done high speed rail successfully makes tackling all the complicated and expensive things you need to make it work profoundly uninteresting to the average American.
That said, they are building a high speed rail link between LA and San Francisco, but while that's an eminently practical project, particularly when you consider the impact on places in between on the line like Bakersfield and Fresno, it's boring. The train won't be the fastest in the world; until we're talking the fastest train or train-like system, Americans won't like the idea.
Slashdot Mirror
uh, a flopping fish just reformatted your drive
... and I don't care.
Repurposing missiles as ship killers? You have heard the term "guided missile cruiser", haven't you? The first purpose built guided missile cruisers were put in service in the early 80s, and could sink ships at 10x the range the big guns on the New Jersey could hit. The Harpoon anti-ship missile went into service in the 70s.
Now I understand the big criticism of the Zumwalt is that it has limited anti-ship capability; but it's supposed to be a destroyer. Destroyers traditionally play mainly anti-submarine and anti-aircraft roles, and in the US Navy mount modest 5" guns for anti-ship use. The Zumwalt's gus are actually 6.1 inches and have considerably longer range -- if they work as advertised. The idea of making it more potent in the anti-ship role would fall into the F35 trap: building cost-is-no-objecdt, do-everything wonder-weapons.
Well, let's assume that malware authors are economically rational. If they demand millions of dollars almost nobody will pay. If they demand a penny they'll get lots of people paying, but they won't net much. There's an optimum ransom price between the extremes where they maximize their revenue, and it's likely to be relatively low -- in the hundreds of dollars -- rather than the tens of thousands of dollars. For one thing any organizations has a threshold under which managers can spend with their own discretion; going over that level is apt to make getting paid a lot quicker. Quick in finance is a very important thing; and it's an even more important thing when it comes to banditry. The longer something goes on the more likely you'll get caught or people will find a way around your scheme.
Now if it were me, I'd set a series of dates after which the ransom goes up, and promptly respond to anyone who paid up early. It's like selling anything else; if you're seen as reliable and responsive people are more likely to give you money; they're also more likely to give you money if they think they'll have to pay you more later.
Well, as you probably guessed I've been around a long time, and this idea comes up over and over again, and it never takes off, and for a good reason. Programming is hard; it's deeply tied to logical reasoning, which in turn is tied to language and notation. Having visual representations as an adjunct often does make reasoning easier, but having only visual representations does not.
Through the years I've met a number of people who claim to be "visual thinkers", but in fact I don't think most people who make that claim are particularly good at visual thinking. What they really mean is they want things kept simple so they don't have to work that hard; when confronted with visual subtlety or complexity they're just as lost as when they are confronted with linguistic complexity. Basically they're mentally lazy but prefer to think of themselves as misunderstood.
Now there are people who are great visual thinkers. Any decent graphic designer is bound to be a strong visual thinker. But oddly enough it's not graphic designers who make this claim. It's usually managers who don't have the patience to read through pages of text; but they don't have the patience to wade through pages of diagrams, either.
I dunno. Learning a new language is easy. It's the APIs they come with that's a bitch.
With a gesture-based interface connected to my fishing rod.
The Comprehensive Test Ban Treaty was adopted by the UN General Assembly in 1996, but won't come into force until 44 specific nations with nuclear technology capabilities have ratified the treaty. At present there are eight nations on the list who have not ratified the treaty, including the United States. The US, however, is a signatory to the treaty, and has not conducted a nuclear test since 1992.
So the US abides by the CTBT as a matter of policy, even though the treaty is not in force, and the Obama administration has in the past indicated that it wants to ratify the treaty, although that won't happen with this Senate.
The reason it's smart policy to promote the adoption of the CTBT is that it would discourage nuclear proliferation, and we don't need to perform testing. We already have enough data from half a century of active testing to ensure our bombs go boom.
Enlightened self-interest. Sheesh.
This is a situation where Isaac's Asimov's ideas about psychohistory are worth considering. Mass murder is an aberrant, rare behavior and predicting it in an individual or even a modest population is a very questionable thing. But it's quite predictable when you're talking about very large populations.
Obama has proposed letting in 10,000 Syrian refugees -- not "millions". How will that effect your chance of being killed in a mass murder? Will that effect be significant?
Well, let's start with the base rate of mass attacks in the US. For purposes of discussion, lets call a "mass attack" as an attack on at least four people. Just in shootings, there have been 353 mass shooting in the US in 2015, and we're on day 340 of 2015. So it's fair to say that mass attacks are a daily occurrence in America. However spread across the large pool of potential victims, any individual's chance of being killed in a mass attack is very low -- so low that in practice we treat the situation as not urgent enough to do anything about.
Three hundred million is a population large enough to predict with certainty that it contains a substantial number of mass murderers. 10,000 is not. So any fear of letting in ten thousand refugees is based on an implicit belief that there is an extraordinarily high proportion of mass murderers in that population, or that the base rate of mass murders in the US is lower than it is, or both.
Let's examine the belief that a high proportion of Syrian refugees are mass murderers. Now what we know about most terrorists, at least the kind that operate across international lines, tend to be from comfortable or privileged backgrounds -- not refugees. This was the case for Santa Barbara shooter Tashfeen Malik, who like many of the 9/11 hijackers had an comfortable, uneventful upbringing and a university degree in a technical field. Refugees who commit terrorism tend to operate in-country (e.g. Al Aqsa Martyr's Brigades) against the immediate source of their displacement. So the idea that a Syrian refugees will commit acts of terror on behalf of ISIS is pretty far-fetched -- if we're talking only 10,000 of them. If we were talking a million of them it's not something we could discount, and if we were talking a hundred million it'd be a virtual certainty, as vanishingly unlikely as any individual taking this path would be.
So what this leaves us with in practical terms is the possibility that an ISIS operative may somehow sneak in amongst the refugees. This is something the Europeans definitely can't rule out. In fact two of the nine November 13 attackers were in the EU on faked Syrian refugee papers. However it's important to note three things: (1) had they not been in the EU their places would be certain to have been taken by indigenous participants; (2) Europe is dealing with far more refugees: 750,000 by some estimates; (3) the US program would only let in people who have been through a two-year long vetting process; in Europe they're just showing up and then have to be characterized after the fact. Even so let's assume one or two terrorists make it in through the program; killing the entire program won't stop ISIS from getting people in through other methods, or radicalizing people who are already here, so keeping those guys out will neither stop ISIS or make a dent in the base rate of mass attacks in the US.
What keeping refugees will do is put ISIS in a more advantageous position. ISIS actually supports the position of people who don't to let Syrian refugees into the US, because that works for them. Remember the famous picture of the dead toddler washed up on the European beach? That saturated the ISIS controlled media in the areas they control, because that's what ISIS wants people leaving their territory to face. Muslims fleeing from ISIS territory demolishes their claim of having established a legitimate new caliphate. It also undermines them in more practical ways -- they've had e
Ever notice how whenever there's a Star Trek away mission, if it's not on a planet with fiberglass rocks it's on a planet that looks like Southern California? If you know anything about natural history, you not only can identify the plants in the scene as specific Earth plants, but you can place the site within a distinctive band of montane chaparral about 250 miles long by 50 miles wide running along the Transverse Range north of LA, and nowhere else on Earth.
That's understandable, since a TV show needs an affordable location shoot, but there's no reason for books to do the same thing; yet authors assume that the present flora of Earth is some kind of universal template -- that all planets must have landscapes featuring flowers, and grass, and trees, but these are all recent developments in the evolution of plants. If you landing on Earth at some random time in the past 425 million years in which there have been plants, chances are you wouldn't see any flowers, grass, or trees. The dinosaurs roamed a landscape where the largest plants were giant ferns. When you land on an alien planet, everything is bound to be alien and disorienting, starting with the division of life into plants and animals, which is Earth-specific.
Even so, I can accept that coming up with a distinct and vivid alien biome is too much work, so I'll settle on getting one thing right: gravity. It bothers me when characters in a story land on planets and the surface gravity seems to be exactly 1g or so close it's not noticeable. That's a heck of a coincidence, and if the characters land on many planets one of the first and biggest things they ought to notice is how the difference in gravity affects them. Granted if we are talking about colonized planets people would no doubt prefer planets with surface gravities near 1g, but even a few percent off normal is going to have a big impact on what it feels like to work on that planet.
Along the same vein, differences in air pressure always bother me. If there is some kind of time-travel portal there ought to be a hell of a wind passing through because of differences in air pressure, which varies with the weather. If you use a time machine that moves through time, then your ears should pop (as should Captain Kirk's after he uses the transporter).
And while we're at it, where does Iron Man store the reaction mass for his boot jets?
Almost anyone can become a competent programmer. They need the right teaching and opportunity, but it's definitely something that can be learned.
A lot of complex programming tasks are less about software engineering and more about knowledge of the application. Business knowledge, systems knowledge, that sort of thing. Stuff that can be learned.
The ability to learn is the real key to it.
Well, while I mostly agree with what you're saying, I think a lot depends on what your standard of "competence" is.
Suppose the standard is this: take a clearly defined task and code a solution in a reasonably acceptable style using the first approach that pops into your head. Well, anyone of average intelligence could be trained to do that, and I think this the kind of conception of competence that a lot of HR departments use. That's why they like certifications; certifications measure exactly this kind of competence: whether you can regurgitate what you've been taught to do.
But I think it's the wrong way of thinking about programming competence.
While the first approach that pops into your head is likely the right one if it does the job, I think a "competent" programmer needs to be able to come up with alternative approaches, especially when it doesn't look like the obvious ones work. This is where I think many "competent" programmers find themselves out of their depth. Don't get me wrong, there is a need for people who can do the obvious thing adequately, or implement a solution when the hard thinking has already been done for them. And goodness knows many schools don't seem to be able to turn out enough graduates who can tell the teacher what he expected to hear. But even if most schools can't meet that target, it's still an unacceptably low standard. Schools need to do more to foster creativity.
And I think creativity can be fostered. The only reason most people believe that someone has to be born creative is that so many schools are so successful at snuffing out any kind of unconventional thinking at such an early age. Teaching programming can help, if you're teaching students to tackle tough problems, problems where they have to face round after round of failure. But it's not programming that's the point; that's just a vehicle. It could be art, or creative writing, or music; anything that teaches persistence and flexibility when your first crack at something isn't good enough.
too bad that each letter in each of those three words probably requires (UNICODE) 2 bytes of 4-5 digits worth of numbers PER CHARACTER to store
Well, that assumes you use a poorly chosen unicode encoding. In UTF8 you only need one byte per character for these particular strings. In fact you don't need unicode at all; since the words only use lowercase latin alphabet you can store them as just five bits per character.
But even that's a lot more space than you can get away with for storage. You don't need to store the string at all; since the triplets are made up from words selected from a 40,000 word dictionary, you can simply store a three-tuple of indices into that dictionary (x1, x2, x3), where each index takes 16 bits [log2(40,000) < 15.29]. So the total storage you would need for an address is 48 bits, or six bytes, which is less than it would take to store a lat/lon coordinate as a pair of single precision floating point numbers (32 bits each x 2 = 64 bits = 8 bytes)
Well, I don't know whether it's inborn, although if sometimes seems this way. But without taking a position on whether programmers are born or made, there are skills and habits involved with being a good programmer that would be useful to anyone. That said, however, I'm not convinced that these skills and habits are what the programming education movement is teaching. I am convinced that coding isn't the only way to gain those things.
What a really skillful programmer does that special is transform problems from something it isn't clear how to solve into other problems that are readily solvable. That takes a peculiar mix of discipline and imagination which simply teaching coding per se will not foster.
The server wound up getting exploited through a remote hole in Apache long before any of my scripts could be a problem. Besides, they all ran as a relatively unprivileged user.
Well, in the early days that would likely have been the case; the vulnerabilities in the Apache server would have presented a better-known target than your code, people weren't in the habit of keeping up with security updates, and automated tools for attacking website specific code didn't exist yet. Today if you did that then flaws in your code would be much more likely to be the cause.
I'm sure you know that the fact that your code runs unprivileged doesn't really protect you or your users, especially these days, but it's worth pointing that out to others. Yes, it does remove certain vulnerabilities, but it doesn't stop things like SQL injection or cross-site scripting or request forgery.
Many years ago a friend of mine had a dog that was hit by a car and had it's leg crushed. He put it in a box and took it to the local animal hospital in the super-wealthy town he lived in, accompanied by his son and his son's best friend. That was a mistake. He was expecting the dog to be put down, but the vet instead told him -- with the kids right there -- that the leg could be saved with an experimental microsurgical procedure. Well, that was that; it was either fork over the equivalent of $20,000 in 2015 dollars or be known around the neighborhood as the rich guy who was too cheap to save the family pet's leg.
When he told me this story he shook his head, and then recounted the time when he was growing up on a ranch and his dog was hit by a car. His dad came out, looked at the dog and said, "Too bad, that was a good dog. Go fetch the shotgun."
Here is an image of the impact site.
While I strongly agree with the argument that PHP's large target footprint has something to do with its reputation for insecurity, I can't help but wonder whether the architectural similarities of typical PHP, ColdFusion and ASP.NET have something to do with the tendencies of some programmers to produce vulnerable code with them. If you squint, they all have a strong family resemblance to each other: you mix language-specific procedural markup with HTML, which is processed on a server and returned as plain HTML to the browser.
Note that I'm not saying PHP is inherently insecure, but I can think of three reasons why this approach might tend to encourage insecure practices. The first is the way programmers, particularly novice programmers, tend to be introduced to such systems. This is a pet peeve of mine; instructors try to sell students on how easy it is to do things so they show students the simplest way of producing a particular result -- not the way that a proficient programmer should produce that result. The message is "look at how easy it is to make a dynamic website with X!" The details of what you need to do to do things like sanitizing input really clutter that message up; especially in the case of these template-y languages where one of the chief selling points is that they're incremental on top of the HTML you need to know anyway.
It's interesting to contrast something like these systems to JSP, which can be used in exactly the same way except that programmers are taught early on that this "model 1" approach is for wimps who can't handle MVC. Java web apps tend to be grossly over-architected; PHP web apps -- at least the ones I've looked at -- tend to be under-architected, with lots of code replicated across many files which should be centralized in some kind of library. That's the second reason I can think why PHP apps might tend to be insecure: under-designed systems mean you have more places where you have to implement some design policy, or where a "temporary" bit of code that does something like build a SQL query from unchecked user input might slip through into production code. It's not the fault of the language per se; it's programmers reproducing the simplest way they were taught to do something over and over again rather than taking the time to refactor their work so that maintaining and securing it is a manageable task.
The third reason I can think of is that these kinds of systems are so easy for someone who doesn't know what he's doing to tweak in the field. I've done it myself; if you have a basic knowledge of HTML, have ever used a programming language, and know how to use "grep" you can find the bit of PHP that produces a particular output and tweak it to your liking without being a PHP programmer. That means that code that ships secure might not remain so in the field.
Anyhow, I don't know enough about PHP per se to say whether it is inherently insecure in some way, but what I've seen leads me to think that some of the problems at least may be an unwanted side effect of ease of use and learning. There's a world of difference between a PHP system generated by a skilled and conscientious programmer and someone who knows a little HTML and picks up a little PHP to add to that. Fortunately this kind of hacked-up HTML website is looking increasingly archaic these days; if you look at RESTful PHP code it looks pretty much like RESTful interfaces done in any other scripting language. It doesn't have the sprawl I tend to associate with PHP web apps.
This only looks hard because of a mental block people have about stuff that doesn't have a gui. In reality it's way often easier to copy and paste into a terminal window -- doing obvious substitutions for things like "www.example.com" -- than it is to try to read some gui designer's mind.
You don't have to understand everything "git clone" does, any more than you have to understanding everything that happens behind the scenes when you click a button.
People with the kinds of jobs that require a physical presence often don't have hobbies or pasttimes that are conducive to working on while riding a bus, unless the bus makes accommodations for tieing fly's, reloading ammunition, or working on cars while in transit.
You have a strange ideas about people's hobbies. I'm an engineer but I work on cars and fish. And plenty of people who do manual labor play videogames.
I'm with you on the closed-mindedness of people in these debates, but to be fair if you don't have the discussion after a recent mass shooting, when can you have it? If you count any murder in which there were four or more victims there have been 353 mass shootings this year; on average more than one a day. The San Bernadino shootings were the second mass shooting on that day. There really isn't time to process one mass shooting before we're on to the next.
Of course this is something of a self-correcting problem, in that mass shootings with only a half dozen victims or so don't make the national news anymore. The San Bernadino event is the tenth shooting with ten or more victims this year, which works out to one a month.
STFU is a political agenda too, you know.
Here is the complaint: https://www.unitedstatescourts.org/federal/ilnd/318734/1-0.html.
Here is the patent in question: http://www.google.com/patents/US5371734.
Basically the patent describes a time division wireless networking scheme in which certain nodes orchestrate transmission and receiving time slots assigned to adjacent nodes. The claimed benefits of this scheme amount to these: bandwidth can be allocated to nodes dynamically, and nodes can extend battery life by turning off their receivers when it's not their turn to receive data. I have no strong opinions as to whether the networking scheme as so vaguely described in the patent is original enough to be patented, but the complaint is a different matter. It appears that Atlas IP LLC appears claiming that any system in which devices are polled and in which the devices may not be transmitting or receiving at any time infringes on this patent. If that is what the patent means, then clearly it's too obvious to be "original".
I'm addressing the point that time spent waiting for the bus equal time wasted. That's not the case any longer, even if you aren't being paid for the time. The hedonic calculus of driving vs. public transit isn't what it used to be in the pre-mobile Internet days. It used to be a choice between spending say 45 minutes doing something you didn't want to do (driving) vs. spending 90 minutes doing something you didn't want to do (riding transit). Obviously shorter was better.
Now on your transit commute (and some day soon in your computer-driven car) you can be doing a lot of the stuff you'd have been doing if your were sitting around your house: reading, shopping, blogging, playing games. That's just as true for a welder taking public transit as it is for a consulting software engineer. It is true as a consultant I have the option of doing paid work, and that's nice. The flip side is people expect you to work all the time.
I've looked up the methodologies used to rank states by corruption; and it's more complicated than you'd think at first.
The top six states by the number of convicted officials (the most commonly used ranking metric) are in order: New York, California, Illinois, Florida, Pennsylvania, then Texas. Note carefully, however, that the top six states by population are in order: California, Texas, Florida, New York, Illinois, and Pennsylvania. It's no surprise that by raw number of convictions that New York tops the list and Vermont is at the bottom; New York has 32x the population, and thus has proportionally more government officials. If the probabilities of an official being corrupt were equal you'd expect more convictions in New York than Vermont.
Things get a bit more interesting when you look at convicted officials per capita. Then the top five corrupt states are, in order: Louisiana, Mississippi, Alaska, South Dakota, then North Dakota. So the states with the most corruption convictions per capita are small-to-middle sized states; the outliers are Illinois, a big state ranking at #6 in per capita convictions, then Vermont and New Hampshire: small states that rank near the bottom in per capita convictions.
Even that doesn't tell an entirely accurate story, because convictions depend on having a government which goes after corrupt officials. For example my state ranks #22 by per capita corruption convictions, but if you go by local reporter estimates of state government corruption it ranks as the least corrupt state, and I think I know the reason for this discrepancy. I've done business with state governments around the country and the kind of cozy relationships between officials and vendors which are the normal way of doing business in many states just don't happen here, because government employees assume they're being watched. On the other side I've seen states where people hate government, but seem to tolerate sloppy or even downright corrupt practices, almost as if having their preconceptions about government confirmed made up for having their tax dollars misspent.
We can't seem to build high-speed rail in the US, which is a proven technology.
Well you put your finger on the problem right there. We Americans have a novelty fetish; we're the only country that could go from putting our first man in orbit to landing a man on the Moon in seven years, then totally lose interest in manned spaceflight. The fact that other countries have done high speed rail successfully makes tackling all the complicated and expensive things you need to make it work profoundly uninteresting to the average American.
That said, they are building a high speed rail link between LA and San Francisco, but while that's an eminently practical project, particularly when you consider the impact on places in between on the line like Bakersfield and Fresno, it's boring. The train won't be the fastest in the world; until we're talking the fastest train or train-like system, Americans won't like the idea.