You're talking about virtualization. I'm talking about things like the Java Virtual Machine or Microsoft's CLR, which provide an abstract model of idealized hardware.
To answer the question you posed: we're gullible. For that reason none of the solutions you pose would work, because any one of them could and would be used by a malicious party to exploit our gullibility. The only solution to the problem is to find some way of making people less gullible.
If you're interested, I have a cure for gullibility, and have started a multilevel marketing program to sell it. You could get in on the ground floor. I guarantee that the vast majority of participants will come out of my program less gullible than they went in (provided they aren't entirely hopeless cases).
Well, I'd agree with you if you this were a class in an O-O language, but it's a class in a major programming *paradigm*. And even theoreticians have to express themselves in code. If the summary is to be believed, the department is taking a stand against O-O programming based on what it sees as the paradigm's shortcomings. Let me tell you, thirty years ago you'd hear the same kinds of arguments in a computer science department about how bad virtual machines were. Virtual machines were an early, failed attempt at getting around the limitations of early compiler technology. C showed you could have a language which was nearly as fast as assembler (faster for most programmers), and easily portable across architectures. There was no reason to study virtual machines, they had no practical application. Well, it probably would have been a good idea to have them in the curriculum somewhere to study on a theoretical basis, because ideas in computer science have a way of re-emerging.
Computer science as a discipline embraces topics other than the theory of computability and complexity theory, which might as well be taught in the mathematics department. For example there is computer language design, hardware architecture, data communication theory, database theory, AI etc. Some of these could be put into other departments, I suppose, but an understanding of the core intellectual discipline *is* widely applicable to all the topics that commonly fall under the "computer science" rubric.
I think an empirical case for separating computer science from software engineering might have sounded convincing fifteen years ago, but Google, and the Internet in general, are strong disproofs of this. Google isn't a search company. It's an algorithm company. It's about doing things on a scale so massive it requires serious computer science ability, well above the "tradesman" level of expertise. Which is not to say that what it does is as "pure" as the work an academic interested in computability per se and defining new kinds of complexity classes, but that kind of work, isolated from its applications, is of such narrow interest it hardly justifies the existence of a department separate from the Mathematics department.
I do see the need for separate concentration areas or departments for computer science per se, software engineering and information science, although having employed a number of people with Masters' degrees in information science I have grave doubts about the academic quality of degree programs in that field. An academic degree should give you the intellectual tools to think about a problem, not necessarily the practical tools to work on it, which can be picked up other ways. The O-O paradigm fits into this framework. The requirement to learn a specific O-O language like C++ or Java is a different matter; somebody with a degree in C.S. should be able to pick any such language up because he should understand the *design* of the language.
I suspect we're seeing departmental politics here.
I don't remember it that way. It was a "big science/little science" fight, if I recall.
The whole SSC thing got started under the Reagan administration, and I *especially* remember the impact when Reagan came in, because I was a student at MIT and had jobs in many research labs around the institute. The Reagan administration did a huge reorientation of the national research program. The Reagan administration had an ideology about research that pulled the plug on a lot of applied research, because that should be done by the private sector. The exception was in DoD funded research, which got a lot *more* focused on immediate applications -- specifically things that were immediately applicable to making weapons -- and so even DoD funded researcher felt the pinch. Although I disagree with Reagan's science policy, it kind of makes sense from their point of view. Making and using weapons is a legitimate government function in their view, as was research that was so far from having practical application that it could not conceivably attract any kind of private sector investment.
The SSC was the kind of thing that the Reagan could get behind. It was by no stretch of the imagination *applied* research. It was a big and showy counterargument to the charge that the administration was "anti-science", and in the grand scheme of things, the $4.4 billion was a pittance to an administration that was going to build a 600 ship navy, and which actually *doubled* federal spending over its tenure. The problem is you can't conjure a direction change in a nation's research establishment overnight. People are in the middle of their careers, and you can't conjure new careers out of thin air. A generation of researchers had to scramble harder than ever for funding, and the funds for the SSC would have purchased a *lot* of small science.
One of the political drawbacks with the SSC is that the economic impact couldn't be spread around the way defense contractors do to build a support base in Congress. Somebody elsewhere suggested physicists near losing SSC sites lobbied their congressmen to kill the SSC, but that doesn't really make sense. Once SSC was killed, nobody was going to build another one. The jealous nuclear physicists who would supposedly have an ax to grid would be better off having the SSC built in Texas than not built at all. But I do think it's likely there was a lot of political opposition from scientists who were "small science" advocates. Not that scientists of any stripe individually or collectively have much clout, but if legislators heard opinions from scientists on the project, the bulk of opinions were likely critical. The kinds of problems any project on this scale would have could easily be spun as imminent disaster.
What can the French win at... let me see. France is internationally competitive in:
* Having names for various minor variations in sexual acts.
* Baking bread.
* Making wine.
* Taking vacation (30 per year legal minimum vacation plus 10 holidays).
* Smoking.
* Organizing nation-paralyzing strikes.
* Intellectual bullshit sessions.
Of course on the negative side is there's their world class national chauvinism (they invented the word, after all). In that respect the French are pretty much like Americans, but without the overwhelming military power and a with a more appealing lifestyle.
Unfortunately, humanity's inability to focus on problems (at least expensive ones) in advance means it has to rely on overreacting after the fact.
We can't say something like, "nuclear power involves risks that must be responsibly managed," because dealing with difficult to quantify terms like "responsible" is beyond our capability. Instead it must be "nuclear power is perfectly safe and there is nothing to worry about," or "nuclear power is a terror out of our darkest nightmares."
Actually, get enough people who think the same way to form a substantial majority and rampant self-righteousness is bound to take root. It doesn't matter where on the political or metaphysical landscape that consensus lies. Form a community of the squishiest, most sentimental liberals you can find and pretty soon they'll be organizing jihad against intolerant people.
I've thought for many years that legislative bodies should have some kind of electronic revision control system that requires changes to be authenticated wtih a legislator's digital signature. It's wouldn't be technically hard, and you'd know who put what feature into a bill. In this case we only know that the bill was put through with the connivance of the legislature's leading officers, but even so they'd be less ready to do that if the offensive language had their signature (or shall we say fingerprints?) on it.
Well, that's interesting, but not quite the same as saying that CRLs are broken. It just means you have to have reasonable expectations, which is where people often screw up. You can't expect a browser to check a certificate against a CRL if it can't access the CRL, but the when the browser *can* access the CRL it provides a useful service.
If the browser can't reach the certificate server to check against the list, there's no ideal policy to choose. You don't want the certificate servers to be a single point of failure from which a massive denial of service could be launched. But you don't want to have the problem to be totally ignored, as with IE. You'd want to give a user who was sufficiently paranoid a chance to not trust the suspect certificate.
Again, speaking of reasonable expectations, you can't expect most users to know what to do with a warning that the certificate can't be checked against the CRL, therefore the browsers must be patched. But an unpatched browser *should* tell the user the certificate is no good if it *can* check the CRL, and that's a good thing.
Well, *coding* the user interface is one of those things that seem daunting when you set out, but turns out to be no big deal after you've learned your way around a platform. The real challenge is *designing* a mobile user interface, which is especially hard for developers coming from a desktop app background. It's important not to transfer your keyboard/mouse/big ole display ways of doing things to a palmtop device. There aren't just disadvantages your app has to work around (e.g. the screen is really tiny) but there are advantages you need to exploit (less modality than a keyboard and mouse interface).
That's not to say that having a great interface builder isn't a convenience, or that the developers of such a thing don't deserve a hearty pat on the back. It's just that I would never choose a development platform, much less a *target* platform, based on how much I liked an interface builder. I'll do without a GUI for building the interface, so long as it's possible to get good looking results and the platform has other features that make my overall job easier.
Well, the summary at least brings up an interesting and important point. We all know that Google is a major innovator, but for a such a technology driven company they have relatively few patents. It may be that it simply doesn't take the throw the crap against the wall and see sticks approach to patenting. That's a good thing for society, but maybe not so good for Google.
Just because you ignore abusive patent practices doesn't mean those practices ignore *you*. One of the reasons companies amass huge patent portfolios is as defensive armor. You threaten to tie me up with BS lawsuits and I'll return the favor.
Think about that. Under the system of software patents we have now, you have to abuse the system to protect yourself from abuse of the system.
A threat is a possible action taken against you. A vulnerability is a specific avenue by which that threat can be realized. Threats and vulnerabilities exist in different ways. Threats represent things that *might* happen in the future. What you are worrying about is threats *materializing* as attacks. Vulnerabilities don't materialize -- they're there in the system all along.
The practical purpose of this distinction is that the actions you take in response to a vulnerability is different than than the actions you take in response to a threat, and the *results* are *vastly* different.
The response to a vulnerability is to *eliminate it*. Having no lock on a door is a vulnerability you eliminate by putting a lock on the door. Note that eliminating a vulnerability does not eliminate vulnerabilities as a class of concerns; in fact it may introduce a new vulnerability. By installing a lock you've eliminated the vulnerability of somebody simply walking into your house, but you've replaced it with the less serious vulnerability of having the lock picked.
The response to a threat is to *reduce your exposure to it*. Burglary is a threat; you can reduce your exposure to it by eliminating vulnerabilities (the lockless door, the piles of cash under your mattress), and taking steps to reduce the damage (buying insurance), but *eliminating* burglary is not a feasible goal.
It's a useful distinction because it separates concerns that you can eliminate with immediate, concrete actions from those you have to keep an eye on.
No, no, no! The strength of a window is a *feature* (or perhaps we should say a "property"); a bullet being fired through that window is the *vulnerability", which may or may not exist in all non-bullet proof windows. For example, a window put in an interior swinging door to prevent people from braining each other with the door may have the feature or characteristic of being not strong enough to deflect a bullet, but shots being fired through that window do not present a realistic vulnerability.
Arguably treats are often tied to features that are not in themselves vulnerabilities. The number of angels that can dance on the head of a pin is a *feature* of the pinhead. The Angel of Death getting pissed because he was left out and going Apocalyptic on your ass is a threat scenario triggered by that feature. The actual vulnerabilities in the scenario do not involve any features of the pin per se. Likewise the inability of some people to distinguish black from white does not mean the color features of a zebra crossing present a fatal vulnerability in themselves.
Well, I'm not sure the engineering trade-offs between a civilian nuke and civilian safety are the same as they are for nuclear powered warships. For one thing, the reactors on nuclear vessels are much smaller. Making a large civilian power plant as robust as a small military reactor might well mean it isn't economical. Capital ships tend to be cost-is-no-object items.
The worst case in a nuclear accident would be fire carrying radioactive material away from the reactor in a plume of smoke. In that worst case on a ship, you'd scuttle the ship. That's not environmentally desirable, of course, but it's better than letter her drift, uninhabitable and contaminating everything downwind. Chances are there would be no civilian casualties, and if it were in deep water no economic impact. The same accident on land would be an economic disaster.
The number of deaths due to a radiological accident after an attack have to be considered in light of the number of casualties from the attack per se, and then in the total strategic context. In other words, people die in attacks on warships, conventional or nuclear. The increased casualties due to radiological accidents have to be balanced against the overall reduction in casualties from the strategic benefits of powering capital ships with nuclear power.
So I don't think you can point to our choice of powering military vessels with reactors as proof that the technologies used in them is safe enough, cost effective, and scalable to civilian needs. We should be designing reactors specifically for the scale on which and the environment in which they'll be used.
Well, let's suppose the batteries are cheap enough to put in your car. Clearly they can handle a lot of current, in fact I'll bet they can discharge at high rates as well as charge. So what you do is you install a similar battery in your house and trickle charge it. At the "gas station" you'd have a massive flywheel that stores energy off the grid. That's how the Plasma Fusion Center at MIT does it. Some of the experiments they do would knock out the power grid if you tried the get the current spike they require directly from the power lines.
Wise man say: what goes around, comes around. The point is to give that angular momentum back. Nobody will be the wiser, except the guys at the naval observatory. When was the last time anyone thought of *them*, I ask you. First we take away their clubhouse so Dick Cheney can live there (well, OK, Nelson Rockefeller was the first), then we play bloody hell with the ephemeris.
Well, maybe. I agree this far: form factor is key in mobile technology, especially if you consider the trade-offs it forces, especially in battery life and performance.
I have been using laptops for twenty years now starting with a PowerBook 100. My last Mac laptop was a PowerBook 540c, still my favorite laptop of all time. I've been using laptops practically since the form factor existed, and it's important to remember this:
THE LAPTOP FORM FACTOR IS NOT ORDAINED BY FATE: IT IS THE PRODUCT OF ENGINEERING TRADE-OFFS.
The laptop form factor has many virtues. It is simple and especially rugged when transported in its closed position. While you can always push the envelope in making an amazing thin device, you're starting with a form factor you can stuff a lot of things into and still have a workable product. A laptop that was an inch and a half thick would be perfectly usable. You could go even thicker if you could convince buyers they were getting something for the bulk. That's not true of a tablet, whose usability is seriously compromised as it goes over a mere half an inch.
The biggest faults of the laptop format are ergonomic. You have room to put a couple of different pointing devices on it (I've had Thinkpads with a touchpad AND the eraser-like trackpoint), but none of them are as favored by most users as a mouse. The worst ergonomic fault is hinging the keyboard to the display, meaning that the display is either too low for comfort or the keyboard is too high, or both. If you use your laptop a lot, you will have neck problems. I carry a laptop stand and an external keyboard with me *so I might as well be using a tablet with a bluetooth keyboard*.
The tablet is now possible because of several developments: electronics and displays that can be made thin; improved batteries; and most especially experience with making effective touchscreen interfaces. It too represents a series of engineering and ergonomic trade-offs. The biggest engineering trade-off is that it has to provide a bright display and good performance while being thin and light enough it's never a bother for the user to handle it.
The big ergonomic trade-off is that a tablet favors retrieval and playback of information over entering information -- at least entering text. To make the most of that, you don't want just a *good* screen, you want a *wonderful* screen on your device, which is where many sub $300 Android tablets fall down. The big win is that the tablet is usable in places where you couldn't use a laptop, and for many applications (reading and playing video) it is more convenient even where you could use a laptop (e.g. on a plane).
The obvious next step is to make a convertible device that can function either as a laptop, a tablet, or a tablet with detached keyboard. It's already being done, mostly by small agile companies, but Motorola is getting into the act. I really like the concept of their Atrix dock, it pretty much converges the ways I use mobile technology: mainly phone, tablet for information retrieval, laptop for text entry. The only thing that would be better is if the display could be removed from the keyboard (like some small companies are doing with their designs). I'll be interested to see if it is a success in the market.
Let's make a web site that completely and entirely depends on some interface provided by large perpetually hungry company!
And compete with that company!
That's a high risk, but not necessarily a stupid strategy. The key is your exit strategy. If your exit strategy is "I'll keep doing this forever, dogging Amazon's heels and making money off of *their* business," then the overall strategy is obviously stupid. That's why I'm supposing their exit strategy looks like this: grow fast enough and become popular enough with Amazon customers that Amazon would rather buy you and expand your service than pull the plug and piss people off.
In this case Amazon pulled the plug before things got that far, but that's not game over. You take your know-how (and to some degree your customer base who being early adopters may have multiple eBook capable devices) and play footsie with Barnes and Noble, Google, and whomever else plays in this space. They don't have Amazon's clout, so they'll be delighted to offer something Amazon can't. Not only does that open up new exit routes with Amazon's competitors, you're *still* a thorn in Amazon's side.
And the worst case failure isn't the albatross around your neck it used to be. You walk away having made a solid effort and customers satisfied with *your* part in the affair. That means you have experience and credibility to bring to your next effort.
Sure, but let's not forget that what's causing the biggest concern at Fukushima right now is something that is supposed to be "walk away safe": the spent fuel pools. Which is not to say that "walk away safe" designs aren't worth pursuing. It just means our model for how something reacts to unusual circumstances is probably no reliable.
In a perfect world, we'd react to the prospect of peak oil by becoming more energy efficient, allowing our economy to grow as it transitions to sustainable energy sources (which will take a long time). I the world we actually live in, people will wait, demanding somebody to fix the problem of rising oil prices, and when it becomes absolutely clear even to people who haven't thought through the problem that it's not going to happen they'll demand a crash program of building nuclear plants. The anti-nuke crowd will point to the known inadequacies of the old boiling and pressurized water reactors, the pro-nuke crowd will get behind one of the new, walk-away-safe designs and we'll end up building lots of those and learning *that* design's unexpected inadequacies by experience.
What I think is we should start evaluating some of these new designs now and start building, not dozens of them, but one or two of the new designs. The important thing is that this will mobilize the anti-nuke people. Not the *dumb* ones, because they don't add to the process. The *smart* ones. We wouldn't *have* better designs if there weren't intelligent critics of LWR and PWR designs. The result will be another less than perfect world where peoples' pet ideas are shot down, nobody gets their way in entirety, at least right away, and we're forced to pay attention to a debate that feels like it will last forever because it's gone on for years. In other words a world that's much better prepared to go on a crash nuclear build-up if that's what's needed, and has thoroughly hashed over alternatives to that.
Well, they have done a pretty good job re-creating themselves along the lines of what they used to think capitalism was. Cozy relationship between the economic elite and high government officials? Check. Labor unions suppressed? Check. Psychological class warfare where workers are duped into working against their own interests by xenophobia and fear? Check. Meddling in economic outcome for the benefit of the politically connected, while maintaining a fig leaf of market freedom? Check. Imperialist policies under the false flags of national sovereignty and concern for the well-being of the natives? Check.
They've become everything they loathed about us. Unfortunately, so have we.
Not that the developers in India are any better. The developers in India are by in large crap. So are most American developers, and developers in any country you care to look for them. There just aren't enough good developers on Earth (much less great ones), and they're spread out in various places, surrounded by mediocre to bad talent.
The whole H1B program is half-assed, although the people who are afraid H1Bs take jobs away from Americans when they come here are mistaken. That doesn't happen until we send them back home. Competent programmers are net producers of jobs, not net consumers. That's why startups often locate in San Jose. They go were recruiting competency is easiest. Competent developers create new jobs; great ones create new industries.
The fact we kick out H1B workers after a few years is a tacit admission that the program doesn't for the most part bring to America skills and talent that America desperately needs. The program as structured is a technology transfer program that provides short term off-shoring windfalls for people at the top of the corporate feeding chain. If the program was designed to do what it is sold as doing, it would bring far fewer people in then keep them here as long as possible.
Well, what's the *value* of that certificate in the situation you're analyzing?
I recently interviewed at a company that provided web based apps that handled sensitive data. Things went really well until they started showing me how the system was built. It was so insecure it made my skin crawl. I raised various security concerns and the answer was always the same, "We don't have that problem." My reply was, "But how do you *know*? Any jackass can create security he can't break himself." (Needless to say I blew the interview, but I didn't really care at that point).
The information this outfit handled was sufficiently juicy it would have been well worth the while of certain parties to set up a man-in-the-middle attack, say a an unsecured wi-fi hotspot. Without going too much into the identity of this company and its clients, lets just say that leaking information from some of the clients could result in people getting killed. That alone justifies the cost of a certificate from a trusted authority. Otherwise you could always set up your own CA, but you'd have to convince your clients to trust you, which they probably should not.
Security is an afterthought, and HTTPS is not the default, and people don't get around to fixing that. In any case, web application security as we know it is a horrible, scary kludge. The only reason it's not a scandal is that we're *used* to this sorry state of affairs.
It's not just applications that make security an afterthought, frameworks, platforms and standards like TCP/IP have security bolted on after the fact. TLS is only one example. It patches two important security concerns, eavesdropping on network transmissions and (only if you get a certificate from a trusted CA) man in the middle. Client side authentication in TLS goes a lot further, but we're still subject to many exploits of the server's trust in the browser, or the browser's trust of executable content delivered by the server, even when one would not expect that.
I've been studying Web application security and Web Services security recently, and it occurred to me to ask: why has so much effort gone into building so many kinds of services and apps on top of a protocol that was designed for delivering static documents? Obviously because that was easier than building new protocols, but why is it easier to hack HTTP to do what we want instead of purpose-building new protocols? It's a bit like cut-and-paste coding.
I think the answer is that the standard TCP/IP protocol stack is missing something between the connection layer (TCP/IP) and the application layer (HTTP), a layer that provides a common set of services such as negotiating data encoding, managing objects and resources needed in a session, common messages to handle configuration or authorization problems, handling state updates between client-side objects and server resources, etc. We'd still need HTTP to handle the scalable distribution of static content of course. Rather than factoring out all the functionality we've kludged onto HTTP to create a new protocol or intermediate architectural layer, it's far quicker to use those facilities as-is, and since *everyone* does things this half-assed way, nobody gets blamed.
This is the lava flow anti-pattern on such a grand scale we can't *see* it because the entire field is *embedded* in it. The worst result of this is the automatic bias toward not just delivering, but running actually apps in the browser. The shared state and trust granted to the browser by the server is a key avenue of attack. The excessive power of HTML with embedded scripting for many applications is another. That's simply not the way you'd architect a system right from the start to deliver secure applications to thin clients. It's how you'd hack application delivery onto a document viewing infrastructure. That's an obviously stupid way to do things, but people were in a hurry and now we've accepted its shortcomings as the way things are and have to be.
If I had to architect the delivery of applications to thin clients, I'd make it possible to build and deploy user interfaces and interfaces through something like XUL or Flash, and have a generic data interchange and session management protocol that delivered strictly typed, non-executable content to and from the client. The application itself would be signed so no unforseen code ever gets executed. Each application would run in a different memory space and credentials and authorizations would be inaccessible from outside the app. If we did things that way, right off the bat a low-level code monkey would generate apps comparable in security to what the best web app designers can accomplish today, because the best practices would be factored out of the good designs and made the path of least resistance for the less capable designers.
That would be common sense, but it's not going t happen. Instead we'll get more demands for creating rich but kludgy and insecure Internet apps because of inertia.
Slashdot Mirror
You're talking about virtualization. I'm talking about things like the Java Virtual Machine or Microsoft's CLR, which provide an abstract model of idealized hardware.
To answer the question you posed: we're gullible. For that reason none of the solutions you pose would work, because any one of them could and would be used by a malicious party to exploit our gullibility. The only solution to the problem is to find some way of making people less gullible.
If you're interested, I have a cure for gullibility, and have started a multilevel marketing program to sell it. You could get in on the ground floor. I guarantee that the vast majority of participants will come out of my program less gullible than they went in (provided they aren't entirely hopeless cases).
Well, I'd agree with you if you this were a class in an O-O language, but it's a class in a major programming *paradigm*. And even theoreticians have to express themselves in code. If the summary is to be believed, the department is taking a stand against O-O programming based on what it sees as the paradigm's shortcomings. Let me tell you, thirty years ago you'd hear the same kinds of arguments in a computer science department about how bad virtual machines were. Virtual machines were an early, failed attempt at getting around the limitations of early compiler technology. C showed you could have a language which was nearly as fast as assembler (faster for most programmers), and easily portable across architectures. There was no reason to study virtual machines, they had no practical application. Well, it probably would have been a good idea to have them in the curriculum somewhere to study on a theoretical basis, because ideas in computer science have a way of re-emerging.
Computer science as a discipline embraces topics other than the theory of computability and complexity theory, which might as well be taught in the mathematics department. For example there is computer language design, hardware architecture, data communication theory, database theory, AI etc. Some of these could be put into other departments, I suppose, but an understanding of the core intellectual discipline *is* widely applicable to all the topics that commonly fall under the "computer science" rubric.
I think an empirical case for separating computer science from software engineering might have sounded convincing fifteen years ago, but Google, and the Internet in general, are strong disproofs of this. Google isn't a search company. It's an algorithm company. It's about doing things on a scale so massive it requires serious computer science ability, well above the "tradesman" level of expertise. Which is not to say that what it does is as "pure" as the work an academic interested in computability per se and defining new kinds of complexity classes, but that kind of work, isolated from its applications, is of such narrow interest it hardly justifies the existence of a department separate from the Mathematics department.
I do see the need for separate concentration areas or departments for computer science per se, software engineering and information science, although having employed a number of people with Masters' degrees in information science I have grave doubts about the academic quality of degree programs in that field. An academic degree should give you the intellectual tools to think about a problem, not necessarily the practical tools to work on it, which can be picked up other ways. The O-O paradigm fits into this framework. The requirement to learn a specific O-O language like C++ or Java is a different matter; somebody with a degree in C.S. should be able to pick any such language up because he should understand the *design* of the language.
I suspect we're seeing departmental politics here.
I don't remember it that way. It was a "big science/little science" fight, if I recall.
The whole SSC thing got started under the Reagan administration, and I *especially* remember the impact when Reagan came in, because I was a student at MIT and had jobs in many research labs around the institute. The Reagan administration did a huge reorientation of the national research program. The Reagan administration had an ideology about research that pulled the plug on a lot of applied research, because that should be done by the private sector. The exception was in DoD funded research, which got a lot *more* focused on immediate applications -- specifically things that were immediately applicable to making weapons -- and so even DoD funded researcher felt the pinch. Although I disagree with Reagan's science policy, it kind of makes sense from their point of view. Making and using weapons is a legitimate government function in their view, as was research that was so far from having practical application that it could not conceivably attract any kind of private sector investment.
The SSC was the kind of thing that the Reagan could get behind. It was by no stretch of the imagination *applied* research. It was a big and showy counterargument to the charge that the administration was "anti-science", and in the grand scheme of things, the $4.4 billion was a pittance to an administration that was going to build a 600 ship navy, and which actually *doubled* federal spending over its tenure. The problem is you can't conjure a direction change in a nation's research establishment overnight. People are in the middle of their careers, and you can't conjure new careers out of thin air. A generation of researchers had to scramble harder than ever for funding, and the funds for the SSC would have purchased a *lot* of small science.
One of the political drawbacks with the SSC is that the economic impact couldn't be spread around the way defense contractors do to build a support base in Congress. Somebody elsewhere suggested physicists near losing SSC sites lobbied their congressmen to kill the SSC, but that doesn't really make sense. Once SSC was killed, nobody was going to build another one. The jealous nuclear physicists who would supposedly have an ax to grid would be better off having the SSC built in Texas than not built at all. But I do think it's likely there was a lot of political opposition from scientists who were "small science" advocates. Not that scientists of any stripe individually or collectively have much clout, but if legislators heard opinions from scientists on the project, the bulk of opinions were likely critical. The kinds of problems any project on this scale would have could easily be spun as imminent disaster.
What can the French win at... let me see. France is internationally competitive in:
* Having names for various minor variations in sexual acts.
* Baking bread.
* Making wine.
* Taking vacation (30 per year legal minimum vacation plus 10 holidays).
* Smoking.
* Organizing nation-paralyzing strikes.
* Intellectual bullshit sessions.
Of course on the negative side is there's their world class national chauvinism (they invented the word, after all). In that respect the French are pretty much like Americans, but without the overwhelming military power and a with a more appealing lifestyle.
Sounds like a line of dialog from "Flash Gordon".
Unfortunately, humanity's inability to focus on problems (at least expensive ones) in advance means it has to rely on overreacting after the fact.
We can't say something like, "nuclear power involves risks that must be responsibly managed," because dealing with difficult to quantify terms like "responsible" is beyond our capability. Instead it must be "nuclear power is perfectly safe and there is nothing to worry about," or "nuclear power is a terror out of our darkest nightmares."
Actually, get enough people who think the same way to form a substantial majority and rampant self-righteousness is bound to take root. It doesn't matter where on the political or metaphysical landscape that consensus lies. Form a community of the squishiest, most sentimental liberals you can find and pretty soon they'll be organizing jihad against intolerant people.
I've thought for many years that legislative bodies should have some kind of electronic revision control system that requires changes to be authenticated wtih a legislator's digital signature. It's wouldn't be technically hard, and you'd know who put what feature into a bill. In this case we only know that the bill was put through with the connivance of the legislature's leading officers, but even so they'd be less ready to do that if the offensive language had their signature (or shall we say fingerprints?) on it.
Well, that's interesting, but not quite the same as saying that CRLs are broken. It just means you have to have reasonable expectations, which is where people often screw up. You can't expect a browser to check a certificate against a CRL if it can't access the CRL, but the when the browser *can* access the CRL it provides a useful service.
If the browser can't reach the certificate server to check against the list, there's no ideal policy to choose. You don't want the certificate servers to be a single point of failure from which a massive denial of service could be launched. But you don't want to have the problem to be totally ignored, as with IE. You'd want to give a user who was sufficiently paranoid a chance to not trust the suspect certificate.
Again, speaking of reasonable expectations, you can't expect most users to know what to do with a warning that the certificate can't be checked against the CRL, therefore the browsers must be patched. But an unpatched browser *should* tell the user the certificate is no good if it *can* check the CRL, and that's a good thing.
Well, *coding* the user interface is one of those things that seem daunting when you set out, but turns out to be no big deal after you've learned your way around a platform. The real challenge is *designing* a mobile user interface, which is especially hard for developers coming from a desktop app background. It's important not to transfer your keyboard/mouse/big ole display ways of doing things to a palmtop device. There aren't just disadvantages your app has to work around (e.g. the screen is really tiny) but there are advantages you need to exploit (less modality than a keyboard and mouse interface).
That's not to say that having a great interface builder isn't a convenience, or that the developers of such a thing don't deserve a hearty pat on the back. It's just that I would never choose a development platform, much less a *target* platform, based on how much I liked an interface builder. I'll do without a GUI for building the interface, so long as it's possible to get good looking results and the platform has other features that make my overall job easier.
Well, the summary at least brings up an interesting and important point. We all know that Google is a major innovator, but for a such a technology driven company they have relatively few patents. It may be that it simply doesn't take the throw the crap against the wall and see sticks approach to patenting. That's a good thing for society, but maybe not so good for Google.
Just because you ignore abusive patent practices doesn't mean those practices ignore *you*. One of the reasons companies amass huge patent portfolios is as defensive armor. You threaten to tie me up with BS lawsuits and I'll return the favor.
Think about that. Under the system of software patents we have now, you have to abuse the system to protect yourself from abuse of the system.
A threat is a possible action taken against you. A vulnerability is a specific avenue by which that threat can be realized. Threats and vulnerabilities exist in different ways. Threats represent things that *might* happen in the future. What you are worrying about is threats *materializing* as attacks. Vulnerabilities don't materialize -- they're there in the system all along.
The practical purpose of this distinction is that the actions you take in response to a vulnerability is different than than the actions you take in response to a threat, and the *results* are *vastly* different.
The response to a vulnerability is to *eliminate it*. Having no lock on a door is a vulnerability you eliminate by putting a lock on the door. Note that eliminating a vulnerability does not eliminate vulnerabilities as a class of concerns; in fact it may introduce a new vulnerability. By installing a lock you've eliminated the vulnerability of somebody simply walking into your house, but you've replaced it with the less serious vulnerability of having the lock picked.
The response to a threat is to *reduce your exposure to it*. Burglary is a threat; you can reduce your exposure to it by eliminating vulnerabilities (the lockless door, the piles of cash under your mattress), and taking steps to reduce the damage (buying insurance), but *eliminating* burglary is not a feasible goal.
It's a useful distinction because it separates concerns that you can eliminate with immediate, concrete actions from those you have to keep an eye on.
No, no, no! The strength of a window is a *feature* (or perhaps we should say a "property"); a bullet being fired through that window is the *vulnerability", which may or may not exist in all non-bullet proof windows. For example, a window put in an interior swinging door to prevent people from braining each other with the door may have the feature or characteristic of being not strong enough to deflect a bullet, but shots being fired through that window do not present a realistic vulnerability.
Arguably treats are often tied to features that are not in themselves vulnerabilities. The number of angels that can dance on the head of a pin is a *feature* of the pinhead. The Angel of Death getting pissed because he was left out and going Apocalyptic on your ass is a threat scenario triggered by that feature. The actual vulnerabilities in the scenario do not involve any features of the pin per se. Likewise the inability of some people to distinguish black from white does not mean the color features of a zebra crossing present a fatal vulnerability in themselves.
Well, I'm not sure the engineering trade-offs between a civilian nuke and civilian safety are the same as they are for nuclear powered warships. For one thing, the reactors on nuclear vessels are much smaller. Making a large civilian power plant as robust as a small military reactor might well mean it isn't economical. Capital ships tend to be cost-is-no-object items.
The worst case in a nuclear accident would be fire carrying radioactive material away from the reactor in a plume of smoke. In that worst case on a ship, you'd scuttle the ship. That's not environmentally desirable, of course, but it's better than letter her drift, uninhabitable and contaminating everything downwind. Chances are there would be no civilian casualties, and if it were in deep water no economic impact. The same accident on land would be an economic disaster.
The number of deaths due to a radiological accident after an attack have to be considered in light of the number of casualties from the attack per se, and then in the total strategic context. In other words, people die in attacks on warships, conventional or nuclear. The increased casualties due to radiological accidents have to be balanced against the overall reduction in casualties from the strategic benefits of powering capital ships with nuclear power.
So I don't think you can point to our choice of powering military vessels with reactors as proof that the technologies used in them is safe enough, cost effective, and scalable to civilian needs. We should be designing reactors specifically for the scale on which and the environment in which they'll be used.
True. On Slashdot car analogies lead to off-topic threads...
Oh, wait.
Well, let's suppose the batteries are cheap enough to put in your car. Clearly they can handle a lot of current, in fact I'll bet they can discharge at high rates as well as charge. So what you do is you install a similar battery in your house and trickle charge it. At the "gas station" you'd have a massive flywheel that stores energy off the grid. That's how the Plasma Fusion Center at MIT does it. Some of the experiments they do would knock out the power grid if you tried the get the current spike they require directly from the power lines.
Wise man say: what goes around, comes around. The point is to give that angular momentum back. Nobody will be the wiser, except the guys at the naval observatory. When was the last time anyone thought of *them*, I ask you. First we take away their clubhouse so Dick Cheney can live there (well, OK, Nelson Rockefeller was the first), then we play bloody hell with the ephemeris.
Well, maybe. I agree this far: form factor is key in mobile technology, especially if you consider the trade-offs it forces, especially in battery life and performance.
I have been using laptops for twenty years now starting with a PowerBook 100. My last Mac laptop was a PowerBook 540c, still my favorite laptop of all time. I've been using laptops practically since the form factor existed, and it's important to remember this:
THE LAPTOP FORM FACTOR IS NOT ORDAINED BY FATE: IT IS THE PRODUCT OF ENGINEERING TRADE-OFFS.
The laptop form factor has many virtues. It is simple and especially rugged when transported in its closed position. While you can always push the envelope in making an amazing thin device, you're starting with a form factor you can stuff a lot of things into and still have a workable product. A laptop that was an inch and a half thick would be perfectly usable. You could go even thicker if you could convince buyers they were getting something for the bulk. That's not true of a tablet, whose usability is seriously compromised as it goes over a mere half an inch.
The biggest faults of the laptop format are ergonomic. You have room to put a couple of different pointing devices on it (I've had Thinkpads with a touchpad AND the eraser-like trackpoint), but none of them are as favored by most users as a mouse. The worst ergonomic fault is hinging the keyboard to the display, meaning that the display is either too low for comfort or the keyboard is too high, or both. If you use your laptop a lot, you will have neck problems. I carry a laptop stand and an external keyboard with me *so I might as well be using a tablet with a bluetooth keyboard*.
The tablet is now possible because of several developments: electronics and displays that can be made thin; improved batteries; and most especially experience with making effective touchscreen interfaces. It too represents a series of engineering and ergonomic trade-offs. The biggest engineering trade-off is that it has to provide a bright display and good performance while being thin and light enough it's never a bother for the user to handle it.
The big ergonomic trade-off is that a tablet favors retrieval and playback of information over entering information -- at least entering text. To make the most of that, you don't want just a *good* screen, you want a *wonderful* screen on your device, which is where many sub $300 Android tablets fall down. The big win is that the tablet is usable in places where you couldn't use a laptop, and for many applications (reading and playing video) it is more convenient even where you could use a laptop (e.g. on a plane).
The obvious next step is to make a convertible device that can function either as a laptop, a tablet, or a tablet with detached keyboard. It's already being done, mostly by small agile companies, but Motorola is getting into the act. I really like the concept of their Atrix dock, it pretty much converges the ways I use mobile technology: mainly phone, tablet for information retrieval, laptop for text entry. The only thing that would be better is if the display could be removed from the keyboard (like some small companies are doing with their designs). I'll be interested to see if it is a success in the market.
Let's make a web site that completely and entirely depends on some interface provided by large perpetually hungry company!
And compete with that company!
That's a high risk, but not necessarily a stupid strategy. The key is your exit strategy. If your exit strategy is "I'll keep doing this forever, dogging Amazon's heels and making money off of *their* business," then the overall strategy is obviously stupid. That's why I'm supposing their exit strategy looks like this: grow fast enough and become popular enough with Amazon customers that Amazon would rather buy you and expand your service than pull the plug and piss people off.
In this case Amazon pulled the plug before things got that far, but that's not game over. You take your know-how (and to some degree your customer base who being early adopters may have multiple eBook capable devices) and play footsie with Barnes and Noble, Google, and whomever else plays in this space. They don't have Amazon's clout, so they'll be delighted to offer something Amazon can't. Not only does that open up new exit routes with Amazon's competitors, you're *still* a thorn in Amazon's side.
And the worst case failure isn't the albatross around your neck it used to be. You walk away having made a solid effort and customers satisfied with *your* part in the affair. That means you have experience and credibility to bring to your next effort.
Sure, but let's not forget that what's causing the biggest concern at Fukushima right now is something that is supposed to be "walk away safe": the spent fuel pools. Which is not to say that "walk away safe" designs aren't worth pursuing. It just means our model for how something reacts to unusual circumstances is probably no reliable.
In a perfect world, we'd react to the prospect of peak oil by becoming more energy efficient, allowing our economy to grow as it transitions to sustainable energy sources (which will take a long time). I the world we actually live in, people will wait, demanding somebody to fix the problem of rising oil prices, and when it becomes absolutely clear even to people who haven't thought through the problem that it's not going to happen they'll demand a crash program of building nuclear plants. The anti-nuke crowd will point to the known inadequacies of the old boiling and pressurized water reactors, the pro-nuke crowd will get behind one of the new, walk-away-safe designs and we'll end up building lots of those and learning *that* design's unexpected inadequacies by experience.
What I think is we should start evaluating some of these new designs now and start building, not dozens of them, but one or two of the new designs. The important thing is that this will mobilize the anti-nuke people. Not the *dumb* ones, because they don't add to the process. The *smart* ones. We wouldn't *have* better designs if there weren't intelligent critics of LWR and PWR designs. The result will be another less than perfect world where peoples' pet ideas are shot down, nobody gets their way in entirety, at least right away, and we're forced to pay attention to a debate that feels like it will last forever because it's gone on for years. In other words a world that's much better prepared to go on a crash nuclear build-up if that's what's needed, and has thoroughly hashed over alternatives to that.
Well, they have done a pretty good job re-creating themselves along the lines of what they used to think capitalism was. Cozy relationship between the economic elite and high government officials? Check. Labor unions suppressed? Check. Psychological class warfare where workers are duped into working against their own interests by xenophobia and fear? Check. Meddling in economic outcome for the benefit of the politically connected, while maintaining a fig leaf of market freedom? Check. Imperialist policies under the false flags of national sovereignty and concern for the well-being of the natives? Check.
They've become everything they loathed about us. Unfortunately, so have we.
Not that the developers in India are any better. The developers in India are by in large crap. So are most American developers, and developers in any country you care to look for them. There just aren't enough good developers on Earth (much less great ones), and they're spread out in various places, surrounded by mediocre to bad talent.
The whole H1B program is half-assed, although the people who are afraid H1Bs take jobs away from Americans when they come here are mistaken. That doesn't happen until we send them back home. Competent programmers are net producers of jobs, not net consumers. That's why startups often locate in San Jose. They go were recruiting competency is easiest. Competent developers create new jobs; great ones create new industries.
The fact we kick out H1B workers after a few years is a tacit admission that the program doesn't for the most part bring to America skills and talent that America desperately needs. The program as structured is a technology transfer program that provides short term off-shoring windfalls for people at the top of the corporate feeding chain. If the program was designed to do what it is sold as doing, it would bring far fewer people in then keep them here as long as possible.
Well, what's the *value* of that certificate in the situation you're analyzing?
I recently interviewed at a company that provided web based apps that handled sensitive data. Things went really well until they started showing me how the system was built. It was so insecure it made my skin crawl. I raised various security concerns and the answer was always the same, "We don't have that problem." My reply was, "But how do you *know*? Any jackass can create security he can't break himself." (Needless to say I blew the interview, but I didn't really care at that point).
The information this outfit handled was sufficiently juicy it would have been well worth the while of certain parties to set up a man-in-the-middle attack, say a an unsecured wi-fi hotspot. Without going too much into the identity of this company and its clients, lets just say that leaking information from some of the clients could result in people getting killed. That alone justifies the cost of a certificate from a trusted authority. Otherwise you could always set up your own CA, but you'd have to convince your clients to trust you, which they probably should not.
Security is an afterthought, and HTTPS is not the default, and people don't get around to fixing that. In any case, web application security as we know it is a horrible, scary kludge. The only reason it's not a scandal is that we're *used* to this sorry state of affairs.
It's not just applications that make security an afterthought, frameworks, platforms and standards like TCP/IP have security bolted on after the fact. TLS is only one example. It patches two important security concerns, eavesdropping on network transmissions and (only if you get a certificate from a trusted CA) man in the middle. Client side authentication in TLS goes a lot further, but we're still subject to many exploits of the server's trust in the browser, or the browser's trust of executable content delivered by the server, even when one would not expect that.
I've been studying Web application security and Web Services security recently, and it occurred to me to ask: why has so much effort gone into building so many kinds of services and apps on top of a protocol that was designed for delivering static documents? Obviously because that was easier than building new protocols, but why is it easier to hack HTTP to do what we want instead of purpose-building new protocols? It's a bit like cut-and-paste coding.
I think the answer is that the standard TCP/IP protocol stack is missing something between the connection layer (TCP/IP) and the application layer (HTTP), a layer that provides a common set of services such as negotiating data encoding, managing objects and resources needed in a session, common messages to handle configuration or authorization problems, handling state updates between client-side objects and server resources, etc. We'd still need HTTP to handle the scalable distribution of static content of course. Rather than factoring out all the functionality we've kludged onto HTTP to create a new protocol or intermediate architectural layer, it's far quicker to use those facilities as-is, and since *everyone* does things this half-assed way, nobody gets blamed.
This is the lava flow anti-pattern on such a grand scale we can't *see* it because the entire field is *embedded* in it. The worst result of this is the automatic bias toward not just delivering, but running actually apps in the browser. The shared state and trust granted to the browser by the server is a key avenue of attack. The excessive power of HTML with embedded scripting for many applications is another. That's simply not the way you'd architect a system right from the start to deliver secure applications to thin clients. It's how you'd hack application delivery onto a document viewing infrastructure. That's an obviously stupid way to do things, but people were in a hurry and now we've accepted its shortcomings as the way things are and have to be.
If I had to architect the delivery of applications to thin clients, I'd make it possible to build and deploy user interfaces and interfaces through something like XUL or Flash, and have a generic data interchange and session management protocol that delivered strictly typed, non-executable content to and from the client. The application itself would be signed so no unforseen code ever gets executed. Each application would run in a different memory space and credentials and authorizations would be inaccessible from outside the app. If we did things that way, right off the bat a low-level code monkey would generate apps comparable in security to what the best web app designers can accomplish today, because the best practices would be factored out of the good designs and made the path of least resistance for the less capable designers.
That would be common sense, but it's not going t happen. Instead we'll get more demands for creating rich but kludgy and insecure Internet apps because of inertia.