Microsoft chose to continue along the monolithic path, because the modular path pushed out the deadline by a year.
The other reason is that Microsoft has business reasons for making its software monolithic. This became apparent during the DOJ trial when Microsoft had its staff swear in court that it would be impossible to remove IE from the system. It just couldn't do anything about the fact that it had, throughout the design of the operating system, ignored one of the most basic principles of engineering.
Ergo, this was not an engineering decision, but one driven by some other consideration. We're not obliged to infer that this was anticompetitive, though the court did conclude in this case that Microsoft was systematically engaging in anticompetitive practices, and other courts in other jurisdictions have done so as well. But we can certainly conclude that the practice of building monolithic systems is straightforward bad engineering. It's no surprise that Microsoft is in trouble because of it.
I did my first work as a system programmer on mainframes. I can tell you that even today the data centre culture is nothing like the PC desktop culture. This is not a statement about professional competence - because God knows that people can make idiotic decisions in any professional setting - but about accepted norms.
Data centres are, by nature, bureacratic and conservative. Whether an initiative is good or bad, there are a lot of places where it can lose momentum or stall completely. So a point technology that's just barely good enough for the desktop is not likely to overcome the legitimate objections which will be raised at numerous points against its deployment in the data centre.
What generally does succeed in adoption, as another poster pointed out, are integrated solutions. The data centre knows exactly what it requires for a vendor to play in this space, and if any vendor can serve as an example it would be IBM. If there is a perfect example of what you would not want in a solutions provider, it would be Microsoft. To move through a conservative bureaucracy requires overcoming a lot of objections. That's hard when the vendor and its products have established a reputation of being intrinsically objectionable.
I agree that IBM used to play very dirty indeed, as Microsoft does now in the desktop space, but IBM was there when the industry was forming. So it took awhile for the industry to build up a response, but when it did, IBM got smacked down hard. Amazingly, it does seem to have undergone real reforms since then. I haven't seen dirty tricks from IBM in years, and therefore I'll happily invite it to compete in any significant request for proposal. It will win or lose on its merits, and I can still go for a beer with the IBM rep, and I don't have to worry about inappropriate calls to the CEO, or reprisals, or threats of any kind. My personal turning point was when I began buying SCSI drives from IBM. It was fantastic hardware, and no strings attached.
So IBM is back in the game. Once Microsoft develops a track record of honorable conduct, when it makes interoperable products, and when it actually functions as an integrator and not as a parasite on the industry, then the time will have come to let it into the game as well. This is just a personal opinion, and I'm just one guy in the data centre, but Microsoft has to get past half a dozen groups with guys like me in them. Microsoft, exactly like IBM before it, doesn't understand that this is not about how much weight you can throw around.
Well, the answer goes to the heart of the discussion at hand.
Many people in this field are attracted by interesting work. What makes work interesting is the opportunity of learning and developing new insights. For technical people, the focus of interest is primarily technical.
A manager who can lead staff to these insights is worth gold. I have the enormous fortune of working for one. He knows the subject matter comprehensively, so I can go to him for advice and insight, and I can trust his judgement in areas where I have to take his judgement on faith. He hires extremely capable people, so I'm surrounded by colleagues who also contribute toward an effort based on merit and collegiality.
He also understands how to manage people, and he does it very generously. This is, of course, a very important characteristic to have in a manager, but my point is that it is not sufficient in a technical manager. A really competent technical manager can afford to lay back a bit because he will have a complete read of the situation, not just a fractional one based primarily on a feel for personality.
Naturally enough, managers who lack technical ability tend to discount any suggestion that it really matters. How could they do otherwise and still persist in their profession? But that state of denial is exactly the problem. Sure, I've had a couple of managers who were not technically strong, but were really decent. Because of their humanity, those situations were quite tolerable. They were, however, not excellent. I would not take a pay cut for them.
You're right to suggest that there are several ways in which some particular open source software could be compromised.
The standard counterargument for most of them is "A similar potential exists in proprietary software also, but is less easy to detect and repair."
I don't want to flog this point too vigorously, because it's clear that in practice the quality and security of any software is derivative of many factors, both in the development environment and during its installation and operation.
We know that open source is, in principle, subject to extensive peer review, but as with proprietary software, the effectiveness of that review is not guaranteed. What's more significant to security, in my view, is that open source encourages forms of installation which can be directly repaired, and complementarily, encourages a culture of system administration which values deep expertise. Proprietary software, on the other hand, tends to be monolithic, and in my experience tends to attract an insufficiently expert sort of system administration for consideration of security.
The peer review model is not a perfect sieve, but it has proven effective in science for centuries. So fundamentally I think we're on the right track with open source. In practical terms, I think there's some interesting work ahead of us. One area, for example, is the authentication and validation required for highly distributed development. Progress in this area would benefit both open source and proprietary development models, with the greatest benefit, however, accruing to open source.
Work on the modularity of system components is another area of ongoing benefit to security. It's simply the continued application of known software engineering principles, and it stands to benefit both open source and proprietary software by encouraging interoperability. Interoperability means choice, which can be choice in favor of more reliable and secure modules over lesser ones. In practice, open source developers seem to be generally in favor of interoperabilty whereas proprietary developers are often encouraged to defeat it.
2. Commit to teaching users proper ways to set up their data and desktops
Put users in charge of an essential part of your computing environment and you get what you deserve: an environment about which you can guarantee nothing. By definition, you have introduced a population of rogue systems. This would be true regardless of platform.
Realistically, it seems like there are really two ways to go here. Either build an environment in which all elements can be rigorously locked down and validated, or be prepared to contain the effects of allowing people to attach foreign equipment such as laptops or other systems that they maintain to their own standards.
Security comes down to defining the conditions of ownership and trust at each point in the computing environment. That's something agreed at the policy level, but then enforced through all the technical mechanisms we know and love.
So you're right to talk about policy, but try to step up one level of abstraction. From a policy perspective, a dual boot system and a laptop are both examples of foreign, volatile equipment. If you forbid one, it makes no sense to allow the other. If you allow either, somebody has to fund the additional risk containment.
This article tries to conclude "there is no open source community."...
So is there an Open-Source Community? Yes, of course.
Reminds me a bit of that inflammatory comment by Nicholas Carr in the Economist a couple of years ago that "IT is not strategic".
These are both deliberately polarizing statements, and only defensible by invoking some special definition of their subject. Carr got a lot of wiggle room out of using the term "strategic" to mean something quite a bit more narrow than what we would expect it to mean. Walker, or his editors, are engaging in a similar exercise of rhetoric. See, "community" doesn't mean community in the sense of lots of different participants having only a very imprecise and accidental relationship to each other.
Then there would be no argument, only scope for nuanced understanding. And that doesn't sell media eyeballs nearly as well.
Let's think about portability and functionality for a second.
The Unix variants make an attractive development target in part because they deliberately embody many common concepts and interfaces. The effect is not perfect, but it's far and away the best thing going.
Why is this important? Because it takes extra effort to write portable code, you want to target an environment that will minimize that effort and maximize the various benefits, all of which happen to be indirect. You will have to design and implement more abstractly, you will have to test more extensively, and yet the result will be functionally no different than nonportable code.
One superficial benefit to portability is to reach a broader market, but the real benefit that it encourages thoughtful design. That should lead to software which is easier to maintain and extend, and which uses system capabilities very deliberately, not just because some developer wanted to play with them. So I'm arguing that the net effect of writing for Unix is to make your applications at least partially future-proof. If new operating system cababilities were to emerge, your software would be in a good position to exploit them.
That said, all this talk about "video-based OS" seems a bit strange to me. Do people imagine there's some kind of magic required to process video, something that requires a complete architectural rethink? It's just data. Its realtime processing requirements are qualitatively no different than audio, or banking transactions for that matter. It basically depends on having sufficiently fast hardware, and an operating system that can efficiently support realtime events.
This is hardly new ground. Unix lends itself to be extended in this way. The Solaris kernel had realtime scheduling ten years ago. Today you can go out and add realtime video to your Linux system for a hundred bucks. Your current hardware isn't fast enough to do a lot of realtime image processing such as edge detection, but that's not because anything is fundamentally missing from the operating system.
I once overheard one of the local winemakers say "oak is not a condiment." So from that perspective you're on the right track.
Everything depends what your particular vintage is capable of expressing. Beyond that, it's a matter of exercising sound judgement in guiding it toward that outcome.
My view is that any computational form of this process will amount to a very elaborate expert system. It will be driven by a small number of objective measurements such as Brix and TA, as well as a large number of rather subjective or imprecise ones such as fruit intensity, overall aroma and flavor characteristics present in the crush, weather and vine conditions throughout the growing season, and so on. The problem is that if you knew how to communicate such impressions accurately to the expert system, you probably wouldn't need the system anyway.
It would be an interesting exercise to build this kind of system, but human beings come eminently equipped with the same capabilities and more already. I get much more pleasure out of developing and applying my own expertise, and I expect you do too. If you proceed systematically with your experiments (say by reserving some unoaked wine for comparison or later blending) you will gain a profound and personal knowledge about wine which no amount of reading or expert advice can replace. It will not only make you a better winemaker, but will add to your depth of appreciation for commercial wines as well.
Winemakers at your scale of production rarely find themselves saying, "I have no idea what happened to this vintage." You have to be really obstinately stupid to not get quite good at making predictably great wine. The main thing is the grapes, and they are a product of nature, not engineering.
Irony: "We can't compete because someone else makes the OS and we don't have full access to it."
It says something about the extent of the doublethink that it must take to get through a day working at Microsoft.
All that stuff you learn in introductory software engineering courses about modularity, cooperating subsystems? Forget all of it. For one thing, it's a very corrupting concept, cooperation. It leads to terrible things like interoperability, you know, where one component could actually be replaced by another, functionally equivalent, one? Maybe one made by a competitor or something, maybe more secure, maybe more scalable, all much too risky to bear thinking about. Don't go there.
So while you're toiling away, dreaming up more useless features, practicing not thinking about modularity, of course your first impulse when developing an application will be to maximize how much of the operating system needs to be conformed around the desired level of cuteness you want for the application. Then you get what Steve Ballmer proudly calls "integrated innovation" meaning the rules are whatever we say they are.
So, you don't get to keep your job by developing a web browser that just competently and securely renders web pages like any other graphical application. The real focus must always remain squarely on innovation. You know, like ActiveX. Where's the ActiveX in MacOS? It's like, useless. The system is not integrated at all.
The problem is that there is a hidden cost to having all of these features: Security, or rather a lack thereof.
Well said. And of course the risk lies not so much in the number of features as in the complexity and scope of their behavior. Support for multiple image types can introduce implementation vulnerabilities, but nothing like the design vulnerabilities inherent in supporting arbitrary computations on the client.
The owner of a Web client certainly can't count on the quality of content delivered by the Web server. It's enlightening run to your browser with JavaScript turned off, and notice how inconsistently simple hyperlinks are treated, in many cases even on a single menu bar on one page of one site. Some links will use address tags, others JavaScript methods. If Web developers can't distinguish something so trivial, we should probably not expect much from them in the way of more sophisticated security hygeine, especially when we have to trust the behavior of their code on our client.
So you can see why the W3C would like to replace some of the arbitrary procedural complexity of executable content with the declarative simplicity and restraint of markup and stylesheets. Let the developers declare what style to present on hover; there should be no need to fire an arbitrary method just to achieve a simple cosmetic effect like highlighting. Cosmetic behaviors which can only be achieved procedurally tend to be excessively cute anyway. Who asked for them?
Here I part ways with the topic article when it complains that Web pages are limited to clunky text boxes and radio buttons for user input. What do you want as user input? Shoot the dancing bear in 3D? Come on. Maybe if I'm teleoperating a robot with force feedback I might want something beyond the standard repertoire of interface elements, but this is the Web, after all. It's not intended for realtime performance or even to push the limits of graphics technology. It's intended for ubiquity. Don't compromise that for the sake of cuteness.
This goes back to the central design principle of the Web. Let the server decide what content to deliver. Let the client decide how to present it. That single principle is what is causing the Web interface to displace all other user interface models. There are just too many interoperability problems otherwise.
What's wrong with Windows may very well be something that doesn't exist at Microsoft: elegance, simplicity and modularity of design.
And these are precisely the design factors which have the greatest impact on security.
[sips tea]
Pity, really.
Microsoft is driven by marketing, not engineering. The campaign which Steve Ballmer calls "integrated innovation" is just its latest attempt to sell monolithic design as a feature rather than as an egregious failure to attend to basic engineering principles.
The only rational justification would be to lock in customers and lock out competition. Oh, but that's a good thing, isn't it? Sorry, I forgot myself there for a second.
very few of us may have a need to send mail from the command line
Anyone who administers Unix systems should challenge this statement. It's the most basic way to have the system to page you or send you a text message.
Why should I have to register it with the OS in order to do so?
It's apparent that Greg Raiz doesn't "get" Unix, and so his choice of language is open to criticism. Unix is not a monolithic black box intended for narrowly defined use. It's an extensible workbench written by developers for developers.
That said, Greg has made an intuitive connection with an idea which is very important for any modular operating system, and that is that it should be possible for the modules to be managed in a structured way, taking into account authentication, dependencies, versioning, installation, and removal.
It's not like this is a new idea. Package management has been in Unix for a decade or two at least, and for example in Solaris the entire operating system install is managed in terms of packages. We don't have a package standard that is common across all Unix and Linux variants, though we have several candidates. I often wish we could converge on one of them because it would be very helpful for site management, especially at heterogenous sites.
Greg is profoundly misguided in suggesting that such package management must be (a) centralized or (b) mandatory. Those are classic weaknesses of the Microsoft approach which Unix developers have prudently managed to avoid. On the contrary, package management should support a distributed model which sites can define to suit their particular requirements. And certainly it makes no sense in a development environment to mandate that all software be "installed" under the same restrictive conditions as might be desired for production software.
The reason we have Linux is because it turns out that the world is not just made up of software "consumers". Some of us actually prefer to work within a development environment. We'll tend to choose development tools that give us more, not less, control over our systems.
If you're an academic researcher or student, chances are that you can arrange access on one of the many clusters that are available to the research community.
If you're a Canadian researcher, for example, you can get a free account on WestGrid, simply in return for acknowledging its contribution in your published work, and for periodically reporting that research to WestGrid so that it in turn can build a case for continued funding. One of the Principal Investigators at WestGrid happens to be specifically interested in search.
In the United States there is TeraGrid and many other excellent cluster facilities, and so also in a number of other countries.
Researchers do not need to pay for commercial solutions which are only trying to catch up to what the research community has already been doing for several years!
"Modern interactive communication systems can include more than two people in a session and people can move fluidly from role-to-role, including: initiating contact; joining communication in progress; accepting contact; terminating communication in progress; refusing contact."
This needs to be explained?
As a security person, I should think so, yeah. Because if we don't explicitly model these activities, then we may end up leaning heavily on weak or even false assumptions for our security. Worse, any points of vulnerability which they introduce will be hidden. It's another application of the "weakest link" principle, and as such, it resembles any kind of science. If you're not clear about your facts, you end up with a flaky theory. Often, the "facts" themselves are pretty obvious. Often, the implications are not.
If you'd like a more established example, consider the variety of man-in-the-middle exploits that potentially exist on a public network. Of course it's "obvious" that information on a network passes through many intermediate points where it might be observed or transformed. But when our focus is on something else, we might overlook the obvious.
I notice that a lot of people don't get what makes signed certificates different from public keys, and it's exactly this example which motivates the difference. Otherwise a man in the middle could just substitute its public key in place of the end parties while the session is being established. Well, what if the man in the middle is actually a man in the middle, because we never allowed for the possibility that there might be more than two people involved in a session? To design a secure solution for this scenario will call for some form of authenticated handoff in midsession, not a trivial exercise at all.
Sorry that I have to disagree with your argument in each of its points.
A key function of an OS is to... manage... resources
The point is illustrates a common misperception. Viruses are not system resources. They are bitstrings which strictly originate outside the system. As such, they're benign unless the system fails to provide for this distinction.
Anti-virus needs to run at a privilege level above most user and admin processes.
Not at all. Virus detection is strictly a pattern match, which can easily function at the application level.
The OS vendor is... most likely... to understand these vulnerabilities
This comment, while true, doesn't support your argument that virus detection belongs in the operating system. Ordinarily, a system is secure without virus detection in the first place, as discussed above. If it's not secure, adding virus detection doesn't make it secure, it just adds complexity, which is the enemy of security.
Defense against malware should be a default-feature of the OS
The phrase you're looking for is secure by default. If a system is secure by default, it doesn't need virus detection.
I switched to Privoxy a couple of years ago, and have found it very solid.
The supplied filters and actions are very useful as examples, but I'd rather make my own explicit choices about what content to exclude. So I began with an empty set of action patterns, and over time added to the set whenever I encountered any content I deemed offensive.
That effort was a bit of a distraction for the first week or two, but has converged very nicely, to the point where I now very rarely have to edit the patterns.
My ethical position on all of this is in part a consequence of having made these explicit choices. I began this process by looking at all the unfiltered web content as originally presented. While I'm prepared to look at it once, as a reasonable person I can be expected to develop a lasting judgement based on that experience. My subsequent filtering choices are a specific expression of that judgement. Purchasing decisions are another. I'm not rejecting ads, I'm rejecting content which, through personal experience and upon due reflection, I have found offensive.
Kind of a radical sentiment, but I find it hard to find fault with it.
Rackets like protection, extortion, and graft have a common strategy of manipulating the mark into a situation in which it appears compellingly less expensive to submit than to escape. Blackmail, drug addiction, and even domestic abuse are also subject to this sort of manipulation.
It seems that such despicable activities express a recurring potential in human relationship. There's always that risk whenever the strong are in a position to dominate the weak. We have to acknowledge that in some parts of the world, and at some periods in history, they have formed the primary basis for commerce.
But our industry is not yet in such a helpless position. We could institutionalize graft, but I think that would only be a temporary and symptomatic relief which gives the exploitation more time to invade systemically.
Take those ROI studies that Microsoft has been funding. Notice what they're really saying? It costs more to leave Microsoft than to just keep on paying the graft, as if that were an advantage. On the much superior ROI of not going along with Microsoft in the first place, they are conspicuously silent.
I think, to be precise, that anonymous posting is the exercise of a right. You can have the right to bear children, but that does not guarantee that you're biologically equipped to do so. If it happens that you can, great.
Likewise, there is no right to post anonymously and consequent obligation on forum proviers. But if it happens that you can, then what you say is, within limits, constitutionally protected speech.
In most cultures, the distinction doesn't need to be made, because this splitting of hairs would be considered farcical. In the United States, however, there is serious money riding on it, and the telemarketing industry is only the tip of the iceberg.
You could say that the US is ahead of the world in putting this matter to the judicial test, or you could say that something is deeply wrong with American culture that it needs such basic considerations spelled out for it. Either way, it behooves us to be careful with our language. Orwell was on to something there.
Slashdot Mirror
The other reason is that Microsoft has business reasons for making its software monolithic. This became apparent during the DOJ trial when Microsoft had its staff swear in court that it would be impossible to remove IE from the system. It just couldn't do anything about the fact that it had, throughout the design of the operating system, ignored one of the most basic principles of engineering.
Ergo, this was not an engineering decision, but one driven by some other consideration. We're not obliged to infer that this was anticompetitive, though the court did conclude in this case that Microsoft was systematically engaging in anticompetitive practices, and other courts in other jurisdictions have done so as well. But we can certainly conclude that the practice of building monolithic systems is straightforward bad engineering. It's no surprise that Microsoft is in trouble because of it.
Data centres are, by nature, bureacratic and conservative. Whether an initiative is good or bad, there are a lot of places where it can lose momentum or stall completely. So a point technology that's just barely good enough for the desktop is not likely to overcome the legitimate objections which will be raised at numerous points against its deployment in the data centre.
What generally does succeed in adoption, as another poster pointed out, are integrated solutions. The data centre knows exactly what it requires for a vendor to play in this space, and if any vendor can serve as an example it would be IBM. If there is a perfect example of what you would not want in a solutions provider, it would be Microsoft. To move through a conservative bureaucracy requires overcoming a lot of objections. That's hard when the vendor and its products have established a reputation of being intrinsically objectionable.
I agree that IBM used to play very dirty indeed, as Microsoft does now in the desktop space, but IBM was there when the industry was forming. So it took awhile for the industry to build up a response, but when it did, IBM got smacked down hard. Amazingly, it does seem to have undergone real reforms since then. I haven't seen dirty tricks from IBM in years, and therefore I'll happily invite it to compete in any significant request for proposal. It will win or lose on its merits, and I can still go for a beer with the IBM rep, and I don't have to worry about inappropriate calls to the CEO, or reprisals, or threats of any kind. My personal turning point was when I began buying SCSI drives from IBM. It was fantastic hardware, and no strings attached.
So IBM is back in the game. Once Microsoft develops a track record of honorable conduct, when it makes interoperable products, and when it actually functions as an integrator and not as a parasite on the industry, then the time will have come to let it into the game as well. This is just a personal opinion, and I'm just one guy in the data centre, but Microsoft has to get past half a dozen groups with guys like me in them. Microsoft, exactly like IBM before it, doesn't understand that this is not about how much weight you can throw around.
Well, the answer goes to the heart of the discussion at hand.
Many people in this field are attracted by interesting work. What makes work interesting is the opportunity of learning and developing new insights. For technical people, the focus of interest is primarily technical.
A manager who can lead staff to these insights is worth gold. I have the enormous fortune of working for one. He knows the subject matter comprehensively, so I can go to him for advice and insight, and I can trust his judgement in areas where I have to take his judgement on faith. He hires extremely capable people, so I'm surrounded by colleagues who also contribute toward an effort based on merit and collegiality.
He also understands how to manage people, and he does it very generously. This is, of course, a very important characteristic to have in a manager, but my point is that it is not sufficient in a technical manager. A really competent technical manager can afford to lay back a bit because he will have a complete read of the situation, not just a fractional one based primarily on a feel for personality.
Naturally enough, managers who lack technical ability tend to discount any suggestion that it really matters. How could they do otherwise and still persist in their profession? But that state of denial is exactly the problem. Sure, I've had a couple of managers who were not technically strong, but were really decent. Because of their humanity, those situations were quite tolerable. They were, however, not excellent. I would not take a pay cut for them.
The standard counterargument for most of them is "A similar potential exists in proprietary software also, but is less easy to detect and repair."
I don't want to flog this point too vigorously, because it's clear that in practice the quality and security of any software is derivative of many factors, both in the development environment and during its installation and operation.
We know that open source is, in principle, subject to extensive peer review, but as with proprietary software, the effectiveness of that review is not guaranteed. What's more significant to security, in my view, is that open source encourages forms of installation which can be directly repaired, and complementarily, encourages a culture of system administration which values deep expertise. Proprietary software, on the other hand, tends to be monolithic, and in my experience tends to attract an insufficiently expert sort of system administration for consideration of security.
The peer review model is not a perfect sieve, but it has proven effective in science for centuries. So fundamentally I think we're on the right track with open source. In practical terms, I think there's some interesting work ahead of us. One area, for example, is the authentication and validation required for highly distributed development. Progress in this area would benefit both open source and proprietary development models, with the greatest benefit, however, accruing to open source.
Work on the modularity of system components is another area of ongoing benefit to security. It's simply the continued application of known software engineering principles, and it stands to benefit both open source and proprietary software by encouraging interoperability. Interoperability means choice, which can be choice in favor of more reliable and secure modules over lesser ones. In practice, open source developers seem to be generally in favor of interoperabilty whereas proprietary developers are often encouraged to defeat it.
0. systems not designed for security
2. Commit to teaching users proper ways to set up their data and desktops
Put users in charge of an essential part of your computing environment and you get what you deserve: an environment about which you can guarantee nothing. By definition, you have introduced a population of rogue systems. This would be true regardless of platform.
Realistically, it seems like there are really two ways to go here. Either build an environment in which all elements can be rigorously locked down and validated, or be prepared to contain the effects of allowing people to attach foreign equipment such as laptops or other systems that they maintain to their own standards.
Security comes down to defining the conditions of ownership and trust at each point in the computing environment. That's something agreed at the policy level, but then enforced through all the technical mechanisms we know and love.
So you're right to talk about policy, but try to step up one level of abstraction. From a policy perspective, a dual boot system and a laptop are both examples of foreign, volatile equipment. If you forbid one, it makes no sense to allow the other. If you allow either, somebody has to fund the additional risk containment.
Reminds me a bit of that inflammatory comment by Nicholas Carr in the Economist a couple of years ago that "IT is not strategic".
These are both deliberately polarizing statements, and only defensible by invoking some special definition of their subject. Carr got a lot of wiggle room out of using the term "strategic" to mean something quite a bit more narrow than what we would expect it to mean. Walker, or his editors, are engaging in a similar exercise of rhetoric. See, "community" doesn't mean community in the sense of lots of different participants having only a very imprecise and accidental relationship to each other.
Then there would be no argument, only scope for nuanced understanding. And that doesn't sell media eyeballs nearly as well.
The Unix variants make an attractive development target in part because they deliberately embody many common concepts and interfaces. The effect is not perfect, but it's far and away the best thing going.
Why is this important? Because it takes extra effort to write portable code, you want to target an environment that will minimize that effort and maximize the various benefits, all of which happen to be indirect. You will have to design and implement more abstractly, you will have to test more extensively, and yet the result will be functionally no different than nonportable code.
One superficial benefit to portability is to reach a broader market, but the real benefit that it encourages thoughtful design. That should lead to software which is easier to maintain and extend, and which uses system capabilities very deliberately, not just because some developer wanted to play with them. So I'm arguing that the net effect of writing for Unix is to make your applications at least partially future-proof. If new operating system cababilities were to emerge, your software would be in a good position to exploit them.
That said, all this talk about "video-based OS" seems a bit strange to me. Do people imagine there's some kind of magic required to process video, something that requires a complete architectural rethink? It's just data. Its realtime processing requirements are qualitatively no different than audio, or banking transactions for that matter. It basically depends on having sufficiently fast hardware, and an operating system that can efficiently support realtime events.
This is hardly new ground. Unix lends itself to be extended in this way. The Solaris kernel had realtime scheduling ten years ago. Today you can go out and add realtime video to your Linux system for a hundred bucks. Your current hardware isn't fast enough to do a lot of realtime image processing such as edge detection, but that's not because anything is fundamentally missing from the operating system.
I once overheard one of the local winemakers say "oak is not a condiment." So from that perspective you're on the right track.
Everything depends what your particular vintage is capable of expressing. Beyond that, it's a matter of exercising sound judgement in guiding it toward that outcome.
My view is that any computational form of this process will amount to a very elaborate expert system. It will be driven by a small number of objective measurements such as Brix and TA, as well as a large number of rather subjective or imprecise ones such as fruit intensity, overall aroma and flavor characteristics present in the crush, weather and vine conditions throughout the growing season, and so on. The problem is that if you knew how to communicate such impressions accurately to the expert system, you probably wouldn't need the system anyway.
It would be an interesting exercise to build this kind of system, but human beings come eminently equipped with the same capabilities and more already. I get much more pleasure out of developing and applying my own expertise, and I expect you do too. If you proceed systematically with your experiments (say by reserving some unoaked wine for comparison or later blending) you will gain a profound and personal knowledge about wine which no amount of reading or expert advice can replace. It will not only make you a better winemaker, but will add to your depth of appreciation for commercial wines as well.
Winemakers at your scale of production rarely find themselves saying, "I have no idea what happened to this vintage." You have to be really obstinately stupid to not get quite good at making predictably great wine. The main thing is the grapes, and they are a product of nature, not engineering.
It says something about the extent of the doublethink that it must take to get through a day working at Microsoft.
All that stuff you learn in introductory software engineering courses about modularity, cooperating subsystems? Forget all of it. For one thing, it's a very corrupting concept, cooperation. It leads to terrible things like interoperability, you know, where one component could actually be replaced by another, functionally equivalent, one? Maybe one made by a competitor or something, maybe more secure, maybe more scalable, all much too risky to bear thinking about. Don't go there.
So while you're toiling away, dreaming up more useless features, practicing not thinking about modularity, of course your first impulse when developing an application will be to maximize how much of the operating system needs to be conformed around the desired level of cuteness you want for the application. Then you get what Steve Ballmer proudly calls "integrated innovation" meaning the rules are whatever we say they are.
So, you don't get to keep your job by developing a web browser that just competently and securely renders web pages like any other graphical application. The real focus must always remain squarely on innovation. You know, like ActiveX. Where's the ActiveX in MacOS? It's like, useless. The system is not integrated at all.
Well said. And of course the risk lies not so much in the number of features as in the complexity and scope of their behavior. Support for multiple image types can introduce implementation vulnerabilities, but nothing like the design vulnerabilities inherent in supporting arbitrary computations on the client.
The owner of a Web client certainly can't count on the quality of content delivered by the Web server. It's enlightening run to your browser with JavaScript turned off, and notice how inconsistently simple hyperlinks are treated, in many cases even on a single menu bar on one page of one site. Some links will use address tags, others JavaScript methods. If Web developers can't distinguish something so trivial, we should probably not expect much from them in the way of more sophisticated security hygeine, especially when we have to trust the behavior of their code on our client.
So you can see why the W3C would like to replace some of the arbitrary procedural complexity of executable content with the declarative simplicity and restraint of markup and stylesheets. Let the developers declare what style to present on hover; there should be no need to fire an arbitrary method just to achieve a simple cosmetic effect like highlighting. Cosmetic behaviors which can only be achieved procedurally tend to be excessively cute anyway. Who asked for them?
Here I part ways with the topic article when it complains that Web pages are limited to clunky text boxes and radio buttons for user input. What do you want as user input? Shoot the dancing bear in 3D? Come on. Maybe if I'm teleoperating a robot with force feedback I might want something beyond the standard repertoire of interface elements, but this is the Web, after all. It's not intended for realtime performance or even to push the limits of graphics technology. It's intended for ubiquity. Don't compromise that for the sake of cuteness.
This goes back to the central design principle of the Web. Let the server decide what content to deliver. Let the client decide how to present it. That single principle is what is causing the Web interface to displace all other user interface models. There are just too many interoperability problems otherwise.
And these are precisely the design factors which have the greatest impact on security.
[sips tea]
Pity, really.
Microsoft is driven by marketing, not engineering. The campaign which Steve Ballmer calls "integrated innovation" is just its latest attempt to sell monolithic design as a feature rather than as an egregious failure to attend to basic engineering principles.
The only rational justification would be to lock in customers and lock out competition. Oh, but that's a good thing, isn't it? Sorry, I forgot myself there for a second.
Anyone who administers Unix systems should challenge this statement. It's the most basic way to have the system to page you or send you a text message.
Unfortunately it hasn't been updated for some years, but it's a good starting point for someone looking to put together a more complete bibliography.
It's apparent that Greg Raiz doesn't "get" Unix, and so his choice of language is open to criticism. Unix is not a monolithic black box intended for narrowly defined use. It's an extensible workbench written by developers for developers.
That said, Greg has made an intuitive connection with an idea which is very important for any modular operating system, and that is that it should be possible for the modules to be managed in a structured way, taking into account authentication, dependencies, versioning, installation, and removal.
It's not like this is a new idea. Package management has been in Unix for a decade or two at least, and for example in Solaris the entire operating system install is managed in terms of packages. We don't have a package standard that is common across all Unix and Linux variants, though we have several candidates. I often wish we could converge on one of them because it would be very helpful for site management, especially at heterogenous sites.
Greg is profoundly misguided in suggesting that such package management must be (a) centralized or (b) mandatory. Those are classic weaknesses of the Microsoft approach which Unix developers have prudently managed to avoid. On the contrary, package management should support a distributed model which sites can define to suit their particular requirements. And certainly it makes no sense in a development environment to mandate that all software be "installed" under the same restrictive conditions as might be desired for production software.
The reason we have Linux is because it turns out that the world is not just made up of software "consumers". Some of us actually prefer to work within a development environment. We'll tend to choose development tools that give us more, not less, control over our systems.
If you're a Canadian researcher, for example, you can get a free account on WestGrid, simply in return for acknowledging its contribution in your published work, and for periodically reporting that research to WestGrid so that it in turn can build a case for continued funding. One of the Principal Investigators at WestGrid happens to be specifically interested in search.
In the United States there is TeraGrid and many other excellent cluster facilities, and so also in a number of other countries.
Researchers do not need to pay for commercial solutions which are only trying to catch up to what the research community has already been doing for several years!
This needs to be explained?
As a security person, I should think so, yeah. Because if we don't explicitly model these activities, then we may end up leaning heavily on weak or even false assumptions for our security. Worse, any points of vulnerability which they introduce will be hidden. It's another application of the "weakest link" principle, and as such, it resembles any kind of science. If you're not clear about your facts, you end up with a flaky theory. Often, the "facts" themselves are pretty obvious. Often, the implications are not.
If you'd like a more established example, consider the variety of man-in-the-middle exploits that potentially exist on a public network. Of course it's "obvious" that information on a network passes through many intermediate points where it might be observed or transformed. But when our focus is on something else, we might overlook the obvious.
I notice that a lot of people don't get what makes signed certificates different from public keys, and it's exactly this example which motivates the difference. Otherwise a man in the middle could just substitute its public key in place of the end parties while the session is being established. Well, what if the man in the middle is actually a man in the middle, because we never allowed for the possibility that there might be more than two people involved in a session? To design a secure solution for this scenario will call for some form of authenticated handoff in midsession, not a trivial exercise at all.
I wish you'd been around to contribute your perspective to this dialogue. It might have led a more enlightening outcome.
You might like to know that John Dvorak wrote yesterday about the Microsoft Protection Racket
A key function of an OS is to ... manage ... resources
The point is illustrates a common misperception. Viruses are not system resources. They are bitstrings which strictly originate outside the system. As such, they're benign unless the system fails to provide for this distinction.
Anti-virus needs to run at a privilege level above most user and admin processes.
Not at all. Virus detection is strictly a pattern match, which can easily function at the application level.
The OS vendor is ... most likely ... to understand these vulnerabilities
This comment, while true, doesn't support your argument that virus detection belongs in the operating system. Ordinarily, a system is secure without virus detection in the first place, as discussed above. If it's not secure, adding virus detection doesn't make it secure, it just adds complexity, which is the enemy of security.
Defense against malware should be a default-feature of the OS
The phrase you're looking for is secure by default. If a system is secure by default, it doesn't need virus detection.
The supplied filters and actions are very useful as examples, but I'd rather make my own explicit choices about what content to exclude. So I began with an empty set of action patterns, and over time added to the set whenever I encountered any content I deemed offensive. That effort was a bit of a distraction for the first week or two, but has converged very nicely, to the point where I now very rarely have to edit the patterns.
My ethical position on all of this is in part a consequence of having made these explicit choices. I began this process by looking at all the unfiltered web content as originally presented. While I'm prepared to look at it once, as a reasonable person I can be expected to develop a lasting judgement based on that experience. My subsequent filtering choices are a specific expression of that judgement. Purchasing decisions are another. I'm not rejecting ads, I'm rejecting content which, through personal experience and upon due reflection, I have found offensive.
Rackets like protection, extortion, and graft have a common strategy of manipulating the mark into a situation in which it appears compellingly less expensive to submit than to escape. Blackmail, drug addiction, and even domestic abuse are also subject to this sort of manipulation.
It seems that such despicable activities express a recurring potential in human relationship. There's always that risk whenever the strong are in a position to dominate the weak. We have to acknowledge that in some parts of the world, and at some periods in history, they have formed the primary basis for commerce.
But our industry is not yet in such a helpless position. We could institutionalize graft, but I think that would only be a temporary and symptomatic relief which gives the exploitation more time to invade systemically.
Take those ROI studies that Microsoft has been funding. Notice what they're really saying? It costs more to leave Microsoft than to just keep on paying the graft, as if that were an advantage. On the much superior ROI of not going along with Microsoft in the first place, they are conspicuously silent.
I think, to be precise, that anonymous posting is the exercise of a right. You can have the right to bear children, but that does not guarantee that you're biologically equipped to do so. If it happens that you can, great.
Likewise, there is no right to post anonymously and consequent obligation on forum proviers. But if it happens that you can, then what you say is, within limits, constitutionally protected speech.
In most cultures, the distinction doesn't need to be made, because this splitting of hairs would be considered farcical. In the United States, however, there is serious money riding on it, and the telemarketing industry is only the tip of the iceberg.
You could say that the US is ahead of the world in putting this matter to the judicial test, or you could say that something is deeply wrong with American culture that it needs such basic considerations spelled out for it. Either way, it behooves us to be careful with our language. Orwell was on to something there.
Not in a million years. It's just an application.