The restrictions which you're describing are general ones, not ones implemented only by schools and certainly not in any sense because the schools are part of a "socialized education" system.
All insurers do is apply actuarial data to risk management. If one software product is found to present unacceptable risks, its use will not be indemnified.
This is why Bruce Schneier predicts that the pressure for code assurance will ultimately be brought by insurers, because it's a matter of risk management, which is what insurers offer.
Just like an insurer will not offer a policy on an uncertified structure, the day may come when insurers will not indemnify for losses involving the use of uncertified software.
Have you ever made a grammatical error? Reading your post, I can say yes.
Care to point it out for us? You raise an interesting idea, but throwing false accusations around is not a great way to gain favor for it.
Neither is scorn. Too bad for your interesting idea. Oh well, it was pretty much based on hyperbole anyway. Let me restate it for you, just to be sure we're all on the same page.
The nonexistence of bugs in a given body of code is not provable. Some bugs constitute security exposures. Therefore security is not a provable property of code. Therefore complainers are ignorant and should shut up.
If we followed your reasoning, we would make no effort to improve code, since perfection is impossible. But as the parent correctly noted, the top-rated security errors are quite characteristic. This is not at all the case as you make it out to be for doing nothing, it appears, but rudely telling people to shut up.
Everyone's entitled to their opinion, but your defeatism pretends to insight and maturity that it plainly lacks. Go to the back of the class.
Thanks for your comments. I seem to be chatting a lot on this thread, but perhaps I could make one more contribution.
Indeed, there have been a lot of changes since I started programming in 1972, though I must say that they are essentially cosmetic ones. I've learned a lot, and I continue to learn a lot. In other words, the learning process itself is pretty much unchanged. The results of mathematics and computer science have not been overturned. I especially like to point this out because it helps to reinforce the message that there are areas of knowledge worthy of career investment. I don't necessarily mean formal computer science either, but perhaps areas which will ultimately be formalized. I always tell people to look for the underlying principles and design patterns, however they may present themselves, and master them. This is true whether you're developing software, doing systems architecture or security or operations or whatever. Watch for the deep principles.
People who don't do this are in for a short career lifetime. I think this is what you mean by people not having kept up - but I don't think it's about technology changes so much as whether a person is stuck in surface appearances or able to see past them. For example, apart from surface appearance, XML is no different than the S-expressions that interested John McCarthy in the 1950s. It's easy to adapt to new technologies when you can anticipate most of how they're going to work from first principles. And so it's easy to keep up.
Things are just more convenient now. That's the main difference. I've never seen an IDE that will do the thinking for me. Naïve people can produce bad designs more quickly, but fortunately, experienced people can produce good designs more quickly as well. It follows, therefore, that at every level you still need to be able to distinguish between good and bad design. Simply having fancy tools means nothing, but then, it never did.
In that all-important sense, software design has not changed at all. Nor has the management of software designers. You still have to sift the effective people from the not-so-effective. You still have to ask "why" at every point where a design decision has been made. I can separate the competent from the incompetent in five minutes of discussion that way.
It's true that the competent people make a smaller pile, but that's statistically inevitable. Despite the abundant frustrations which people report in this career, I think that the outlook for competent people over the long term is excellent. Merit, ultimately, is what differentiates between good outcomes and bad outcomes. Management which sees this will be more successful than management which doesn't. It may be a slow and bumpy road, but that's where we're headed.
And finally, there is the matter of literacy. In my view, this is a huge factor. As the common level of computer literacy gradually rises, people who are not literate are just not as credible as they used to be. It's inevitable. For some time they've been drifting into easier careers. That raises the bar still further. And it's great news for the rest of us.
I take your point, of course, but I think you're quibbling with terminology in order to make it.
You object to the way I've characterized software as a "medium"? A medium is defined as stuff we work with. We're speaking of its properties: in other words, what's computationally possible.
Metallurgists work with the properties of metal. Fluid mechanics is concerned with the properties of fluids. However, scientists don't work with the properties of science, because science is not a medium but a methodology.
I agree with your core idea. Science is unbounded, to the extent that the universe is a big place with lots to teach us. Each new answer seems to raise further questions, though it doesn't necessarily follow that this process can continue indefinitely in physical science.
A further difference is that in software development we're chiefly concerned with producing usable artifacts. That's what we've been talking about today. Sure, it's merely applied science, but its unboundedness is of a different order: creative rather than analytic.
There are quantitative differences as well. If I build an artifact in iron alloy, say, the practical range of options available to me is rather constrained. The science of metallurgy helps me to understand those constraints, just as computer science helps me to understand what is and is not computable. But quantitatively, the range of options available to me in software development is far greater. It's my own cognitive limitations which dominate what I can do, not the medium itself.
Thank you! I think we're in general agreement, but let's explore the implications a bit further.
Is there any substantive dividing line between design and implementation? If there were one, then people could indeed be left languishing on the wrong side of it. But I don't see one. I think that to impose one is entirely artificial.
If you're designing and writing specifications without thinking about implementation, you're not giving your best. If you're implementing a spec without regard for principles of design, well, that's just stupid.
But more than that, it's often the case that the exercise of building something sheds significant light on its design. There's a lot of natural interplay between these two perspectives, in other words. When we discount that interplay we end up with development processes that don't work well at all, because they're not fully informed.
I need to backtrack a bit here. The problem comes from applying processing concepts to software development that were evolved from the manufacturing industry. In manufacturing, you know what needs to be made; you just have to figure out how to scale up the volume of production. We don't have that situation in software. Far and away the hardest part is expressing what needs to be made, because it's unique each time. The fabrication is trivial.
Of course there are huge varieties of class libraries and operating system features on hand to provide the nuts and bolts when developing software, but that resource doesn't touch what makes software design a cognitive challenge, and it merely shifts where the cognitive effort of implementation has to be applied. We're still fundamentally conditioned by the two factors I cited before: competence and time.
To get back to your point, I believe we agree that value is minimized when anyone is asked to function merely as a code monkey. I'm arguing to do away with the distinction. This partitioning of the problem space is pure artifice, a residue of thinking carried over from the Industrial Revolution. I've found that the way to get the most out of people is to let them participate across the broadest range in which they're presently capable. As their capabilities grow, reward them with more involvement and more responsibility. And don't forget to pay them accordingly.
That's how to address the problem of "languishing" that you rightly identified. But senior developers must not be taken out of the coding process. That's a huge mistake. Yes, they have to divide their attention across many areas, but that's what qualifies them as senior. If you don't expose the junior people to mature ways of thinking, you're throwing away huge opportunities for motivation, mentoring, and just plain knowledge transfer. Worst of all, you end up with a pool of junior people who are disconnected from the rest of the development organization. I see it all the time, and it's toxic.
When I look around, the most limiting factor I see in any enterprise computing environment is the quality of software in use. Multiple teams of people and multiple layers of management are required just to keep it working. Any upgrade plan sends ripples of alarm racing back and forth. And why is there such a status quo of vast inefficiency? Because software is as complex and flawed a contraption as inexperienced programmers can make it.
It takes an extraordinary person, one having both breadth and depth of experience as well as innate clarity of thought, to design even a moderately large system that's simple and sufficient, modular and extensible. Such people aren't to be found in anyone's junior staff. They don't have the experience. And their talents are lost if they should move into management or some other career.
It's not a question of "beyond" where programming is concerned. Unlike any other field, the medium in which we work imposes no ceiling on what we can do with it, Gödel incompleteness notwithstanding. There is no "beyond".
This is such an elementary insight. Since the field itself is not a constraint, what we can achieve is constrained by two factors: our own competence in the field, and time. Given two people of the same natural ability, the one with more experience will be more competent than the one with less experience. That's because, in effect, the experienced one has already put in the time.
Of course, inexperienced people might not know this.
Building and maintaining this hypothetical ideal environent takes resources. In the absence of policy which identifies the extent of the resource commitment, you don't even know what you should be building.
Well, it's obvious that you must decide whether to trust any entity which supplies your operating system kernel. That's just as true whether you acquire the kernel using a DVD or over the net. If somebody puts a backdoor or a key logger into the system, how are you going to know? Walk the code before you accept it?
The only difference with dynamically updating the kernel is one of degree, not kind. It might cause us to think more explicitly about the nature of trust and validation. We might decide that the installer is too critical a system component to be provided by any single supplier. It might be good to have some kind of community process for certifying it. But this requirement holds for the kernel as a whole.
At several places I've worked, I established a particular time window in the week for system maintenance. Whenever possible, we'd reboot systems and conduct other scheduled activity during the scheduled time.
Users would be advised in advance of possible impacts, and had an official channel to raise concerns, suggest mitigations or request rescheduling. In my experience, once everyone gets used to the regime, it works very well.
More complex environments may need more complex treatement. The organization may decide to identify mission-critical services that must not be interrupted, or special procedures to follow for particular systems. That's all to the good.
What we have then is the very desirable situation where operational policy and its implementation are separated in an explicit and agreed way. And once you have this policy framework, it can be extended to security considerations as well.
How can an application install ever conceivably require a reboot of the operating system?
I guess it depends on the operating system. If it provides no modularity and does no privilege separation, I suppose that the whole tangled mess could fall over unless it were rebooted.
Just don't blame the application. All it wants to do is supply the code. It's the system that determines where it goes.
Participants were placed in identical, undecorated jail cells with gray walls and ceilings. Each cell was bare except for a 1kg bar of metallic sodium and a 1gal cardboard milk carton containing gasoline. And a box of wooden matches. And some razor blades.
Why should average users have control over their computer? Isn't this what got us the virus nightmare in Windows?
No, it isn't. If it were, then there would be an even worse virus nightmare with Linux, OpenBSD, et cetera since these environments offer the users much more control over their systems than Windows does.
The virus nightmare in Windows is therefore due to something else. Let's call it being defective by design. What idiots would design a system without privilege containment? What idiots would design a system to automatically execute whatever content crosses its path? Those issues have been identified and resolved ever since batch processing systems became popular in the 1960s.
But Microsoft deliberately ignored industry practice and went ahead to build systems which it knew were vulnerable. And I don't mean should have known, I mean knew. I corresponded with Bill Gates on this subject in the early 1980s, when he was still answering his own emails. His response? It's not something that consumers are asking for.
Of course, the drop in cost of hardware, and its rapid turnover, has a lot to do with that change in perception. People infer (falsely) that everything else must be similarly cheap and disposable. They don't get that most infrastructure design decisions are more enduring, and the payoff of such decisions cumulatively far more significant, than any particular iteration of hardware.
Some people do get it, even if they're in the minority, and even if their approach is a bit hyperbolic. The Long Now Foundation is a charming example. These people are writing years in five digits!
But in another sense even these worthy people are not being entirely true to their own principles. What, five digits written with leading zeroes? Come on, how theatrical is that, and how needlessly brittle? I'll fix their ass. I'm gonna store my dates as bignums.
Having a home computer is only the most recent way that people have been able to gain access to computing resources.
When I got started 38 years ago, what kids did was to demonstrate sufficient enthusiasm and talent to be granted access to a research computer somewhere. It was a serious privilege, but with it came contact with professionals - mathematicians, computer scientists, systems programmers, and electrical engineers - who very much knew what they were doing, and who actually had time to share their insights. These people were routinely tasked with writing things like kernels and schedulers and device drivers and compilers, and they could always use help with various lesser aspects of design and implementation.
That's how I got started in the years before you were born. Then I earned my degree and learned the formal computer science to back up that practical experience. And you know what? It's all still completely relevant. I've lost count of the generations of technology and hype that have come and gone. That's all just surface appearance and deserving only of passing attention. The underlying principles haven't changed a bit, and they're as fascinating and challenging as ever.
They have no inherent properties of extensibility or composability. A certain amount of design attention can productively go into icons, just as font design has an important role in readability. But to stop there is just about as smart as sticking with Roman numerals.
Icons, also, don't translate into speech. Who here has not at one time or another had to walk someone over the phone through a user interface by saying something like, "Okay, before you go ahead and click on the icon with the two little arrows going in a circle, you should first click on the one which looks like a little diskette. You see the popup window that just appeared? Oh, okay, that can happen too. The red icon with the X through it means that the operation isn't allowed right now. Now I need you to go to the top of the screen and click on another icon that looks like a little diskette. No, it means something different there."
Writing documentation around these sorts of interfaces is equally nasty. So people don't. Or if they do, it's so shallow as to be nearly useless. It typically provides a text equivalent for each icon, and not much else. For clarity of documentation, give me a CLI any day. Even better, any decent CLI can be wrapped in a scripting language which does support composability. So instead of telling you the fifteen steps required to do a task, I can give you a script that does the whole thing. I can parameterize it. And if circumstances warrant, I can attach that script to a button on a web page somewhere. Try doing any of that with a GUI.
It's really an enormous triumph of design to arrive at a successful user interface based purely on icons. The fact that it can be achieved sometimes doesn't imply that it will work most of the time.
These are great examples, but if they're your best shot at arguing that interfaces can be "intuitive" then we can all go home now.
Instead you've made an excellent case that usability is correlated with social convention and not with intuition at all. Clearly the labels "Reply", "Cancel", and "Options" are not intuitive. They're just apparently random arrangements of line segments. Specific cultural knowledge is required in order to make sense of them. That's not intuitive but conventional.
Likewise, the symbolism of color is not innate but socially cued. For example, black signifies mourning in western cultures but the social convention in China uses white instead. We don't always recognize the cultural particularity of these conventions because they're so ancient. Some, like your example of red and green, may have been assigned by association with the physical world, perhaps red with blood and green with vegetation. So that's not to suggest that we don't have some imprecise visceral reaction to color as well, but it takes a really big leap to get from there to effective symbolism. Symbolism requires social consensus consensus.
Well, when I read "airport profiling" I thought how convenient it would be to be able to avoid all the suspicious airports during my travels. A profile of airport conditions would be nice to have.
I mean, seriously, that's what it's coming down to. How can I minimize the risk of undue and irrational harassment while en route to my destination? As it is, I try to avoid travel through the United States entirely, and that's a shame, because it's a nice place once you get away from all the people waving guns around.
They don't actually have to verify that the site in question is using their cert for good, but just that they are who they say they are.
I hate to shatter your innocent faith, but they don't do even that. The verification performed by most CAs is as follows:
Did you give us the right amount of money?
Okay, here's your cert.
The procedure for Extended Validation certs is of course much more rigorous, as well as more costly. It goes:
Did you give us the right amount of money?
Did you send a photocopy of someone's driver's license?
Okay, here's your cert.
No verification of the identity document is made. That would be easy, but there's no point. Neither is verification made that the applicant is entitled to the cert, for example by being an authorized agent of the organization which owns the domain name which is to appear in the cert. That would be hard. So it's not done.
You don't have to come to the States just hop on a plane to some other countries around the world and actually see what's out there.
Hey. What a great idea!
Come to think of it, I do that already. And, not being American nor living in the United States, I have the additional benefit of neutrality when I compare my experiences of travelling in all of these different countries, the US being just one on a long list. It also helps in reducing bias, I think, to speak several languages.
So, what can I report? Well, I find that Americans, as people, are absolutely great. They're genuinely friendly and candid and pretty decent for the most part. They remind me a lot of Austrians, and Israelis, and rural French, and Fijians, and Germans definitely, and Moroccans, and the Canadians and English too, come to think of it.
I find that as people, we're all a fairly similar mix. There's a lot of goodwill, but there's often also some weird shit going on when you dig a little deeper, and unlike the universality that I've just been describing, this weirdness seems very specifically cultural. As just one example, I notice a special and profound sort of ignorance, even by educated Americans, of the world outside their own ideology. Other cultures have their weirdnesses too, don't get me wrong, but this one is particularly vexing because it underpins the matter under discussion.
I can also report that the United States, as a government, presents one of the most repressive faces of any I have seen on my travels. Even in the days of the Soviet Union and Intourist, I was never handled with the same sort of contempt as I have found commonplace among American officials in their treatment of visitors. The Soviet officials were just coldly going about their jobs. The American ones seem to be exercising a kind of personal righteousness.
Now, I know this is not representative of the American people. The United States has been struggling with itself ever since the Civil War. You tend to mistrust your own government in ways which make a sad kind of sense to me, but you have to understand that other countries aren't generally like that. Even the nasty ones, strange to say.
If it isn't the utopia you pictured then try the US and see if it's as bad as you thought.
Ahem. Don't fool yourselves. Not only has it been bad for a long time, it's getting worse.
Slashdot Mirror
The restrictions which you're describing are general ones, not ones implemented only by schools and certainly not in any sense because the schools are part of a "socialized education" system.
This is what happens when you have socialized education
If this claim were true, then we would see such repression all over the world, since many countries support public education.
But all indications are that the effect is instead particularly an American one. So no, it isn't about "socialized education".
There is no analogy being presented here.
All insurers do is apply actuarial data to risk management. If one software product is found to present unacceptable risks, its use will not be indemnified.
Thank you. That certainly rates as one error.
This is why Bruce Schneier predicts that the pressure for code assurance will ultimately be brought by insurers, because it's a matter of risk management, which is what insurers offer.
Just like an insurer will not offer a policy on an uncertified structure, the day may come when insurers will not indemnify for losses involving the use of uncertified software.
Care to point it out for us? You raise an interesting idea, but throwing false accusations around is not a great way to gain favor for it.
Neither is scorn. Too bad for your interesting idea. Oh well, it was pretty much based on hyperbole anyway. Let me restate it for you, just to be sure we're all on the same page.
If we followed your reasoning, we would make no effort to improve code, since perfection is impossible. But as the parent correctly noted, the top-rated security errors are quite characteristic. This is not at all the case as you make it out to be for doing nothing, it appears, but rudely telling people to shut up.
Everyone's entitled to their opinion, but your defeatism pretends to insight and maturity that it plainly lacks. Go to the back of the class.
Thanks for your comments. I seem to be chatting a lot on this thread, but perhaps I could make one more contribution.
Indeed, there have been a lot of changes since I started programming in 1972, though I must say that they are essentially cosmetic ones. I've learned a lot, and I continue to learn a lot. In other words, the learning process itself is pretty much unchanged. The results of mathematics and computer science have not been overturned. I especially like to point this out because it helps to reinforce the message that there are areas of knowledge worthy of career investment. I don't necessarily mean formal computer science either, but perhaps areas which will ultimately be formalized. I always tell people to look for the underlying principles and design patterns, however they may present themselves, and master them. This is true whether you're developing software, doing systems architecture or security or operations or whatever. Watch for the deep principles.
People who don't do this are in for a short career lifetime. I think this is what you mean by people not having kept up - but I don't think it's about technology changes so much as whether a person is stuck in surface appearances or able to see past them. For example, apart from surface appearance, XML is no different than the S-expressions that interested John McCarthy in the 1950s. It's easy to adapt to new technologies when you can anticipate most of how they're going to work from first principles. And so it's easy to keep up.
Things are just more convenient now. That's the main difference. I've never seen an IDE that will do the thinking for me. Naïve people can produce bad designs more quickly, but fortunately, experienced people can produce good designs more quickly as well. It follows, therefore, that at every level you still need to be able to distinguish between good and bad design. Simply having fancy tools means nothing, but then, it never did.
In that all-important sense, software design has not changed at all. Nor has the management of software designers. You still have to sift the effective people from the not-so-effective. You still have to ask "why" at every point where a design decision has been made. I can separate the competent from the incompetent in five minutes of discussion that way.
It's true that the competent people make a smaller pile, but that's statistically inevitable. Despite the abundant frustrations which people report in this career, I think that the outlook for competent people over the long term is excellent. Merit, ultimately, is what differentiates between good outcomes and bad outcomes. Management which sees this will be more successful than management which doesn't. It may be a slow and bumpy road, but that's where we're headed.
And finally, there is the matter of literacy. In my view, this is a huge factor. As the common level of computer literacy gradually rises, people who are not literate are just not as credible as they used to be. It's inevitable. For some time they've been drifting into easier careers. That raises the bar still further. And it's great news for the rest of us.
I take your point, of course, but I think you're quibbling with terminology in order to make it.
You object to the way I've characterized software as a "medium"? A medium is defined as stuff we work with. We're speaking of its properties: in other words, what's computationally possible.
Metallurgists work with the properties of metal. Fluid mechanics is concerned with the properties of fluids. However, scientists don't work with the properties of science, because science is not a medium but a methodology.
I agree with your core idea. Science is unbounded, to the extent that the universe is a big place with lots to teach us. Each new answer seems to raise further questions, though it doesn't necessarily follow that this process can continue indefinitely in physical science.
A further difference is that in software development we're chiefly concerned with producing usable artifacts. That's what we've been talking about today. Sure, it's merely applied science, but its unboundedness is of a different order: creative rather than analytic.
There are quantitative differences as well. If I build an artifact in iron alloy, say, the practical range of options available to me is rather constrained. The science of metallurgy helps me to understand those constraints, just as computer science helps me to understand what is and is not computable. But quantitatively, the range of options available to me in software development is far greater. It's my own cognitive limitations which dominate what I can do, not the medium itself.
Thank you! I think we're in general agreement, but let's explore the implications a bit further.
Is there any substantive dividing line between design and implementation? If there were one, then people could indeed be left languishing on the wrong side of it. But I don't see one. I think that to impose one is entirely artificial.
If you're designing and writing specifications without thinking about implementation, you're not giving your best. If you're implementing a spec without regard for principles of design, well, that's just stupid.
But more than that, it's often the case that the exercise of building something sheds significant light on its design. There's a lot of natural interplay between these two perspectives, in other words. When we discount that interplay we end up with development processes that don't work well at all, because they're not fully informed.
I need to backtrack a bit here. The problem comes from applying processing concepts to software development that were evolved from the manufacturing industry. In manufacturing, you know what needs to be made; you just have to figure out how to scale up the volume of production. We don't have that situation in software. Far and away the hardest part is expressing what needs to be made, because it's unique each time. The fabrication is trivial.
Of course there are huge varieties of class libraries and operating system features on hand to provide the nuts and bolts when developing software, but that resource doesn't touch what makes software design a cognitive challenge, and it merely shifts where the cognitive effort of implementation has to be applied. We're still fundamentally conditioned by the two factors I cited before: competence and time.
To get back to your point, I believe we agree that value is minimized when anyone is asked to function merely as a code monkey. I'm arguing to do away with the distinction. This partitioning of the problem space is pure artifice, a residue of thinking carried over from the Industrial Revolution. I've found that the way to get the most out of people is to let them participate across the broadest range in which they're presently capable. As their capabilities grow, reward them with more involvement and more responsibility. And don't forget to pay them accordingly.
That's how to address the problem of "languishing" that you rightly identified. But senior developers must not be taken out of the coding process. That's a huge mistake. Yes, they have to divide their attention across many areas, but that's what qualifies them as senior. If you don't expose the junior people to mature ways of thinking, you're throwing away huge opportunities for motivation, mentoring, and just plain knowledge transfer. Worst of all, you end up with a pool of junior people who are disconnected from the rest of the development organization. I see it all the time, and it's toxic.
"Beyond" programming?
When I look around, the most limiting factor I see in any enterprise computing environment is the quality of software in use. Multiple teams of people and multiple layers of management are required just to keep it working. Any upgrade plan sends ripples of alarm racing back and forth. And why is there such a status quo of vast inefficiency? Because software is as complex and flawed a contraption as inexperienced programmers can make it.
It takes an extraordinary person, one having both breadth and depth of experience as well as innate clarity of thought, to design even a moderately large system that's simple and sufficient, modular and extensible. Such people aren't to be found in anyone's junior staff. They don't have the experience. And their talents are lost if they should move into management or some other career.
It's not a question of "beyond" where programming is concerned. Unlike any other field, the medium in which we work imposes no ceiling on what we can do with it, Gödel incompleteness notwithstanding. There is no "beyond".
This is such an elementary insight. Since the field itself is not a constraint, what we can achieve is constrained by two factors: our own competence in the field, and time. Given two people of the same natural ability, the one with more experience will be more competent than the one with less experience. That's because, in effect, the experienced one has already put in the time.
Of course, inexperienced people might not know this.
That's fine, but you're missing the point a bit.
Building and maintaining this hypothetical ideal environent takes resources. In the absence of policy which identifies the extent of the resource commitment, you don't even know what you should be building.
Well, it's obvious that you must decide whether to trust any entity which supplies your operating system kernel. That's just as true whether you acquire the kernel using a DVD or over the net. If somebody puts a backdoor or a key logger into the system, how are you going to know? Walk the code before you accept it?
The only difference with dynamically updating the kernel is one of degree, not kind. It might cause us to think more explicitly about the nature of trust and validation. We might decide that the installer is too critical a system component to be provided by any single supplier. It might be good to have some kind of community process for certifying it. But this requirement holds for the kernel as a whole.
At several places I've worked, I established a particular time window in the week for system maintenance. Whenever possible, we'd reboot systems and conduct other scheduled activity during the scheduled time.
Users would be advised in advance of possible impacts, and had an official channel to raise concerns, suggest mitigations or request rescheduling. In my experience, once everyone gets used to the regime, it works very well.
More complex environments may need more complex treatement. The organization may decide to identify mission-critical services that must not be interrupted, or special procedures to follow for particular systems. That's all to the good.
What we have then is the very desirable situation where operational policy and its implementation are separated in an explicit and agreed way. And once you have this policy framework, it can be extended to security considerations as well.
How can an application install ever conceivably require a reboot of the operating system?
I guess it depends on the operating system. If it provides no modularity and does no privilege separation, I suppose that the whole tangled mess could fall over unless it were rebooted.
Just don't blame the application. All it wants to do is supply the code. It's the system that determines where it goes.
It only lasted a week.
Participants were placed in identical, undecorated jail cells with gray walls and ceilings. Each cell was bare except for a 1kg bar of metallic sodium and a 1gal cardboard milk carton containing gasoline. And a box of wooden matches. And some razor blades.
Why should average users have control over their computer? Isn't this what got us the virus nightmare in Windows?
No, it isn't. If it were, then there would be an even worse virus nightmare with Linux, OpenBSD, et cetera since these environments offer the users much more control over their systems than Windows does.
The virus nightmare in Windows is therefore due to something else. Let's call it being defective by design. What idiots would design a system without privilege containment? What idiots would design a system to automatically execute whatever content crosses its path? Those issues have been identified and resolved ever since batch processing systems became popular in the 1960s.
But Microsoft deliberately ignored industry practice and went ahead to build systems which it knew were vulnerable. And I don't mean should have known, I mean knew. I corresponded with Bill Gates on this subject in the early 1980s, when he was still answering his own emails. His response? It's not something that consumers are asking for.
Interesting ethics there.
Mod that man up.
Of course, the drop in cost of hardware, and its rapid turnover, has a lot to do with that change in perception. People infer (falsely) that everything else must be similarly cheap and disposable. They don't get that most infrastructure design decisions are more enduring, and the payoff of such decisions cumulatively far more significant, than any particular iteration of hardware.
Some people do get it, even if they're in the minority, and even if their approach is a bit hyperbolic. The Long Now Foundation is a charming example. These people are writing years in five digits!
But in another sense even these worthy people are not being entirely true to their own principles. What, five digits written with leading zeroes? Come on, how theatrical is that, and how needlessly brittle? I'll fix their ass. I'm gonna store my dates as bignums.
Having a home computer is only the most recent way that people have been able to gain access to computing resources.
When I got started 38 years ago, what kids did was to demonstrate sufficient enthusiasm and talent to be granted access to a research computer somewhere. It was a serious privilege, but with it came contact with professionals - mathematicians, computer scientists, systems programmers, and electrical engineers - who very much knew what they were doing, and who actually had time to share their insights. These people were routinely tasked with writing things like kernels and schedulers and device drivers and compilers, and they could always use help with various lesser aspects of design and implementation.
That's how I got started in the years before you were born. Then I earned my degree and learned the formal computer science to back up that practical experience. And you know what? It's all still completely relevant. I've lost count of the generations of technology and hype that have come and gone. That's all just surface appearance and deserving only of passing attention. The underlying principles haven't changed a bit, and they're as fascinating and challenging as ever.
Icons are semantically shallow.
They have no inherent properties of extensibility or composability. A certain amount of design attention can productively go into icons, just as font design has an important role in readability. But to stop there is just about as smart as sticking with Roman numerals.
Icons, also, don't translate into speech. Who here has not at one time or another had to walk someone over the phone through a user interface by saying something like, "Okay, before you go ahead and click on the icon with the two little arrows going in a circle, you should first click on the one which looks like a little diskette. You see the popup window that just appeared? Oh, okay, that can happen too. The red icon with the X through it means that the operation isn't allowed right now. Now I need you to go to the top of the screen and click on another icon that looks like a little diskette. No, it means something different there."
Writing documentation around these sorts of interfaces is equally nasty. So people don't. Or if they do, it's so shallow as to be nearly useless. It typically provides a text equivalent for each icon, and not much else. For clarity of documentation, give me a CLI any day. Even better, any decent CLI can be wrapped in a scripting language which does support composability. So instead of telling you the fifteen steps required to do a task, I can give you a script that does the whole thing. I can parameterize it. And if circumstances warrant, I can attach that script to a button on a web page somewhere. Try doing any of that with a GUI.
It's really an enormous triumph of design to arrive at a successful user interface based purely on icons. The fact that it can be achieved sometimes doesn't imply that it will work most of the time.
These are great examples, but if they're your best shot at arguing that interfaces can be "intuitive" then we can all go home now.
Instead you've made an excellent case that usability is correlated with social convention and not with intuition at all. Clearly the labels "Reply", "Cancel", and "Options" are not intuitive. They're just apparently random arrangements of line segments. Specific cultural knowledge is required in order to make sense of them. That's not intuitive but conventional.
Likewise, the symbolism of color is not innate but socially cued. For example, black signifies mourning in western cultures but the social convention in China uses white instead. We don't always recognize the cultural particularity of these conventions because they're so ancient. Some, like your example of red and green, may have been assigned by association with the physical world, perhaps red with blood and green with vegetation. So that's not to suggest that we don't have some imprecise visceral reaction to color as well, but it takes a really big leap to get from there to effective symbolism. Symbolism requires social consensus consensus.
But don't hold your breath.
For example: http://www.citypages.com/content/printVersion/1247085
Well, when I read "airport profiling" I thought how convenient it would be to be able to avoid all the suspicious airports during my travels. A profile of airport conditions would be nice to have.
I mean, seriously, that's what it's coming down to. How can I minimize the risk of undue and irrational harassment while en route to my destination? As it is, I try to avoid travel through the United States entirely, and that's a shame, because it's a nice place once you get away from all the people waving guns around.
I hate to shatter your innocent faith, but they don't do even that. The verification performed by most CAs is as follows:
The procedure for Extended Validation certs is of course much more rigorous, as well as more costly. It goes:
No verification of the identity document is made. That would be easy, but there's no point. Neither is verification made that the applicant is entitled to the cert, for example by being an authorized agent of the organization which owns the domain name which is to appear in the cert. That would be hard. So it's not done.
You don't have to come to the States just hop on a plane to some other countries around the world and actually see what's out there.
Hey. What a great idea!
Come to think of it, I do that already. And, not being American nor living in the United States, I have the additional benefit of neutrality when I compare my experiences of travelling in all of these different countries, the US being just one on a long list. It also helps in reducing bias, I think, to speak several languages.
So, what can I report? Well, I find that Americans, as people, are absolutely great. They're genuinely friendly and candid and pretty decent for the most part. They remind me a lot of Austrians, and Israelis, and rural French, and Fijians, and Germans definitely, and Moroccans, and the Canadians and English too, come to think of it.
I find that as people, we're all a fairly similar mix. There's a lot of goodwill, but there's often also some weird shit going on when you dig a little deeper, and unlike the universality that I've just been describing, this weirdness seems very specifically cultural. As just one example, I notice a special and profound sort of ignorance, even by educated Americans, of the world outside their own ideology. Other cultures have their weirdnesses too, don't get me wrong, but this one is particularly vexing because it underpins the matter under discussion.
I can also report that the United States, as a government, presents one of the most repressive faces of any I have seen on my travels. Even in the days of the Soviet Union and Intourist, I was never handled with the same sort of contempt as I have found commonplace among American officials in their treatment of visitors. The Soviet officials were just coldly going about their jobs. The American ones seem to be exercising a kind of personal righteousness.
Now, I know this is not representative of the American people. The United States has been struggling with itself ever since the Civil War. You tend to mistrust your own government in ways which make a sad kind of sense to me, but you have to understand that other countries aren't generally like that. Even the nasty ones, strange to say.
If it isn't the utopia you pictured then try the US and see if it's as bad as you thought.
Ahem. Don't fool yourselves. Not only has it been bad for a long time, it's getting worse.