I'm sure that people in Somalia will be shocked at your suggestion that their court has no jurisdiction elsewhere in the world. Come on, they are the centre of the universe. Everybody knows that.
I wonder, can the human eye even see such high resolution
Not all at once, of course. The point of having higher resolution is so that when you attend to one part of the scene, you won't perceive a reduction in image quality.
There are certainly tech support jobs out there which consist primarily of what we might call solving puzzles.
Generally, however, a technical person needs to be broadly competent, needs to have strengths in both analysis and design, needs to communicate well, needs to be able to manage relationships effectively, needs to be able to organize and prioritize effectively under directions which can be incomplete or ambiguous.
The best technical people are not just able to address the issues in front of them, they use them to generate leverage in making progress toward larger goals. They have to articulate and negotiate for those larger goals, which means they have to be sensitive to interests of other individuals, and to the potential for alignment and conflict among them.
These requirements hold especially for more senior positions. It's fine to be able to solve puzzles, but that's not most of the job. And as anyone with hiring experience knows, it's far more successful to gain senior people by letting them rise through the ranks than it is to hire them from outside the organization. Unless you make a point of attracting and hiring people who have that potential, you can risk ending up mostly with a whole bunch of puzzle solvers.
Even scientific research, which obviously tries to solve some very hard puzzles, is mostly driven by collaboration. I've seen generations of compuer science grad students come and go, and the ones that go furthest are invariably the most collaborative. Out of the practice of collaboration they seem to have an easier time understanding their work in context, and they seem able to pick up all the other necessary management skills along the way.
Actually, these are primarily infrastructure decisions, and they are properly based on cost/benefit over the lifetime of the infrastructure. It's incorrect to suggest that such decisions are either pro- or anti- education. They are neutral with respect to education.
More correct than the tired auto analogy, I think, would be if the decision were to standardize on a certain type of lighting system for school buildings which only lets students read books printed on compatible paper made only by the same company that makes the lights. The alternative would be a lighting system made from commonplace parts which works with paper whose formulation is widely understood and available from many different suppliers.
I wouldn't characterize this as a decision in which educators need to be involved at all. Typically we're not teaching students how to make paper, we're teaching subject material that just happens to be delivered on paper. And given that we have limited funds to replace lighting systems and books, we'd like to make a decision that doesn't lock us into a single expensive solution that also makes us dependent on a certain brand of paper.
Sure, in the short term we might lose access to certain desirable book titles because they're only printed on that special paper. That can be a problem, but not a fundamental one, and therefore not one which weighs greatly in the long term when we're talking about building infrastructure. There's no reason that any book title cannot be printed on ordinary paper, and it's in the nature of economics that if the market wants it, sooner or later the market will get it.
Some time ago we left behind the idea that computers were in schools in order to educate students about computers. You and I might be personally interested in that subject, but it's really not driving a lot of decisions. And yes, as a personal preference I'd rather learn everything about an open system than just the surface information about a closed system. There's a reason why Unix took off so dramatically in university computer science curricula, why it appears in so many research papers on operating system design, and so on. You want to design a different process scheduler, or filesystem, or security model? Off you go. Unix won't stop you in any technical sense, and open source won't stop you in any legal sense.
So within this narrower area of education I'd say that open source very much wins in terms of promoting education. It's hard to get around the issue that proprietary systems necessarily promote ignorance.
My money is on nVidia buying up the IP once SGI is gone
I'm with you, as long as nVidia doesn't lock it up and throw away the key.
I have a longstanding fondness for OpenGL but it doesn't work if it stays on just one graphics platform either. It's for portability. So by that reckoning, Apple would make a better steward. Apple has good reason not to tie itself to any one component vendor, and OpenGL helps it in that purpose.
Yep, that plus a bit of homegrown SNMP management for the switches and you've got the problem basically under control. Host connectivity is controllable remotely.
The day will come when devices identify by certificate rather than by MAC, and that will make this architecture firmly secure.
Correct. The service providers persist in trying to revert the Internet into an old-economy vehicle for delivering a narrow selection of services. That was acceptable when there really was a need for separate telephone and video service to the premises, but it no longer makes sense.
The situation is reminiscent of the time when city streets were obscured by the number of overhead wires carrying competing telephone services. Since services did not interoperate, this situation did not scale and was not sustainable. It eventually collapsed under economic and public pressures. In Canada, at least, it eventually became a small number of regulated monopolies overseen by the CRTC, and even these are now obliged to carry each others' services.
But even this carries a useless residue of old-economy thinking. It's suboptimal, and not in the public interest, for information content providers to control, even indirectly, a differentiation in how information is delivered to the premises.
A more appropriate model for information delivery, and one which we can already see actively taking form in many regions, would be municipal power or water or gas. All three cases are much more similar to each other than any of them are to some narrow service such as telephone or television. There is nothing to differentiate one bit, or one molecule, or one coulomb, from another. They're universal resources, period.
If you want to build an industry that depends on these resources, in the way that home electronics depends on power, you no longer have to take it upon yourself to run power transmission lines to the home. A hundred years ago, yes, it was an issue. Now, you can assume that the power is already being delivered, and if your device happens to need 5VDC, you convert it at the device. We're rapidly going that way with information, as well we should.
Old-economy providers ignore this at their peril. As a friend of mine used to say, you can be part of the solution, or part of the precipitate.
There's nothing like a good old-fashioned false dichotomy to start off a shameless product promotion. Kind of reminds me of those late-night informercials for "Y-Bron" hosted by the Man from U.N.C.L.E. himself. Anyone see those? Viagra has made the whole argument kind of redundant, but it was gruesomely presented. Your first option against "male impotency", as I think it was called, is a very nasty looking penis implant and inflation device. Well, doctor, that seems a bit severe. Is there any alternative? Um, why that's a very good question. As it happens, there is. You could take Y-Bron, made from all natural products, only fifty bucks per bottle.
Not that I have anything in principle against the concept of unified security management, except for the little matter that security is an emergent property of the entire system under consideration and not something that can be separated out into an external appliance, no matter how nice and easy that might seem. For example, the "emerging threat from viruses" represented in the article is due to choices in system design which egregiously ignore the problems that might result from installing any random blob of data as system software.
Indeed, perimeter security has never been regarded as sufficient, merely convenient. Many uses of networks have no natural perimeter, university campuses for example. The alternative concept of defense in depth has been the subject of ongoing discussion for at least a decade now, but it does require some effort to model what is allowed to communicate with what, and that in turn forces the question of identity. All of that is sort of hard. Not impossible, but you have to think about what you're doing, and maybe stop doing some of the bad stuff. You can't just take a pill to make it go away.
The issue with turbine power for ground vehicles historically has been how to harness it efficiently under highly varying loads. That and the RPM mismatch means that direct coupling of a turbine into the powertrain doesn't work very well.
It seems like an elegant idea to use the turbine to generate electric power instead, especially since we've seen so much parallel improvement recently in electric powertrains for smaller vehicles.
I don't know why there has been no mention of this either, if only to point out where the losses would have to be reduced in order to break even with competing forms of power delivery.
Look at what happened to SGI, for example, and then tell me I'm exaggerating. It only took one bright new CEO to do more than half of what I wrote above, and set SGI on a downwards spiral from which it never recovered.
Yes indeed, though I don't know who exactly was driving the process at SGI, I saw it all unfold.
SGI performed very well in the era when it dominated the graphical Unix workstation market. It had a superior product in an expanding market. The market was strong in significant degree because there was a healthy mix of other Unix platforms which interoperated fairly well together, and it was an exciting time for both hardware engineering and operating system design. Then two things happened.
The first development was that the industry became fractious as the commercial Unix vendors began to get grandiose ideas of dominance. Unix interoperation began to suffer and the market became distinctly less shiny because of all the dust in the air. Other changes were affecting the industry as a whole, but this one touched SGI particularly, because IRIX was not extremely great at interoperation to begin with, and it was frankly a pain to look after on a large scale. So customer loyalty was becoming a bit fragile at that point.
The second development was that SGI chose that moment to undertake a major change of strategy. Rather than competing as a supplier of graphical Unix workstations, it tried to move up the stack and reposition itself as a supplier of unique graphics applications, the platform now being regarded as somewhat incidental. Unsurprisingly, this proved to be a much smaller market than before, and not especially receptive to the product suite which SGI had to offer.
The Unix market rapidly lost interest in SGI thereafter. A second repositioning by SGI around shared-memory supercomputing was technically interesting but again somewhat off on the sidelines where economies of scale are smaller and development costs higher.
Is this anything like the Microsoft story? I can't see many parallels, myself, except perhaps for internal morale issues which are not unique to these two, that's for sure. Certainly, Microsoft enters lots of markets where it does badly and wastes a lot of money, and through hubris it has been late to the party at almost every interesting development in the industry, from system design principles to the graphical interface and from security to networking. But those are ventures, and at least, whatever risk it takes on them, Microsoft continues always to sit heavily on its core market. I think what hurt SGI most was confusion over what its core market should be.
Maybe the issue was that you were trying to run an unsanctioned Wiki on your laptop in order to manage corporate information. You seem bitter about it, but in retrospect, what part of doing that do you think was actually not clueless?
I don't offer these comments unkindly. The fact that you had the will to make things better is praiseworthy. But making things better is not just about your indulging your personal opinion. A Wiki exists to serve the needs of a community, after all. Now that you know who will be the stakeholders in such a project, you can see how much more sucessful the project is likely to be if you gain their support beforehand.
It's unlikely that anyone wanted your Wiki shut down in order to make your life miserable. Thinking about it from a less narcissistic point of view, it seems likely that people, especially people responsible for network security, don't support the idea of developing a Wiki that lives on someone's laptop. It's a bad idea. Just because it's your bad idea doesn't necessarily mean it's all about you. You could be a nice guy who had a bad idea. We all do occasionally.
What is this bizarre compulsion to brand a random selection of software development activities as if they were all key elements of some elaborate Master Plan? Isn't the work interesting enough in itself without the hyperbole of trying to turn it into some new kind of Klondike?
It's as stupid in its way as people "discovering" the Internet a few years ago. In their haste to stake claims all over it, they neglected to notice that it was actually a set of artifacts created, with considerable effort, by people who came before them.
And didn't we hear this once already with something called Web Services? Let's transport everything over Port 80, that's really innovative. If we must call it anything, let's call it Hubris 2.0. Maybe, like Madonna, it will eventually go away if we just ignore it.
Some people here still expect beta to mean beta, which is conventionally intended to identify bugs in an otherwise stable product. A beta release is not, as you suggest, an invitation to change the feature set, though that has never prevented Microsoft from bending the rules at its convenience.
To be charitable, I can imagine that with this Vista beta, the codebase might indeed be as stable as what we ordinarily expect from a beta release, and so what we're looking at now is just a matter of tuning the configuration parameters so that it prompts at the right thresholds. And, on the principle of security by default, the system will initially tend toward maximum prompting. However, thinking more soberly, a secure system will have fully addressed these issues at the design level, and prompting will not be excessive but appropriate and meaningful. If it's not, that's a clear sign that the design has deeper problems than can be fixed just by changing the prompting parameters. Pardon my cynicism, but in my experience, that would be entirely typical of Microsoft.
The frustrating thing is that most people don't see how identity plays a critical role in establishing secure communications. Your "secret" communication is not very secret if there is a man in the middle.
You're right that this requires active involvement, like say by network and other service providers at various points. Of course, no provider could possibly be persuaded to do that, but as you point out, it's not necessary to make it easy.
Anyway, the identity part is something that possibly needs to be talked about more often. Any community can develop a useful public key infrastructure, and I think doing so brings several advantages over the sort of one-to-one key exchange you're describing. For one thing, it scales better, and for another, it allows parties to identify each other without previously having established trust out of band.
Of course, it does require trusting some third party as a certificate authority or introducer, but that's a reflection of ordinary life. There's no getting around having to ground identity in something, and as a general thing I'd rather be sure that I know who I'm building a secure channel with than want to insist on some kind of anonymity for myself. And anonymous identities can be created if that specifically is required.
Yep, the thing about having lots of components is that failures scale too. But you've been quite misled to think that applications have to be aware of this, or that "custom" software is required. Typically the cluster nodes have internal redundancy so that disk failures do not bring them down, and the cluster scheduler automatically takes care of node failure so that computations run to completion. And of course there is a fault management system which makes the cluster operator aware of failures as they develop.
You don't have much of a cluster without these features, so it would be more accurate to call them standard cluster capabilities. It's indeed true that when you get up to a thousand nodes or so, it takes a fair bit of staff time out of every day just for swapping out bad drives and so on. But this is the nature of mechanical devices. A mainframe is not somehow magically free of these issues. At the same scale, it will have the same number of disk spindles and memory chips. Only the apparent granularity of failure is different to the system operators, and of course the solutions tend to be much more proprietary.
I think that the picture from Google is necessarily unique. Google has built itself a highly specialized computing environment out of commodity components. A lot of the elements required of a general purpose HPC facility have been bypassed for the sake of efficiency in this specialized context. In short, practically the whole thing is system, and what you would classically call the application layer actually resides on the client browser.
Hmm. You're making the case that all mainframe architectures are open? Or are we talking about just this one striking exception?
As you say, that one exception came about because it was imposed as a response to tactics which were so egregiously proprietary that the courts had to intervene. Prior to that time, IBM would cut off your air supply if you dared to put hardware from someone else in the machine room. I saw it done, believe me. And legislation was not enough by itself. Until Gene Amdahl came along with a plan B, the money you'd save on peripherals just wasn't worth the risk. It would be fair, I think, to call that environment "proprietary" in every sense that human ingenuity could devise.
I was talking about architectural portability, which is at quite the other end of the spectrum. Architecture concerns something more than just hardware, or operating systems for that matter. It involves the whole stack of relationships between services and resources. To make a reductio sort of argument, you don't get a portable architecture just by opening the machine instruction set. At best you get to buy into a very limited status quo.
I know, I know, the IBM thing was about interconnects and all kinds of stuff too, but in those days people smoked all day at work, and they still thought it was normal and healthy to program applications in assembler, too. If you wanted to port your application to another environment, you had big work to do.
It's a whole different story if you develop for a cluster environment. Of course you can still hoop yourself if you try very hard, but the environment isn't deliberately set up so you'll tend to do that. People forget that this has not been historically so where mainframes are concerned, and that many of the design decisions made then carry through today. Caveat emptor.
So, a Linux cluster would know what to do with a StorageTek SL8500?
Not to detract from your argument, but actually, it would.
WestGrid, for example, where I used to work, has a storage cluster with a HFS which I recall supported 30 TB on disk and 200TB on tape. That was a couple of years ago, and it may have been augmented since then, given the amount of data from CERN that we expected to process. A lot of research infrastructure funding is going in this direction, because what makes these facilities especially valuable is the variety of different kinds of research they can support.
Some of it is certainly very CPU/FPU intensive, but you may be surprised to learn that a substantial component of high performance computing is raw data movement, in particular ad hoc search of massive, sparse, typically nonuniform datasets. As I understand, the nuclear experiments now coming onstream are expected to generate in the order of 20 PB per event. Genome work likewise produces voluminous data of potentially very high value, though obviously not all of it will be equally valuable and therefore efficient search is a critical factor in storage design. Undersea sensing projects such as Neptune are expected to generate more data than they can possibly store, which presents some very interesting challenges for storage architecture given that sensors will have to be switched on and off on demand.
So, to return to my original point, if I had to invest effort in developing software for a high performance environment of any kind, I'd want that environment to be a very general, very versatile one, with a minimum of proprietary features and APIs. Not, in other words, so much like a typical mainframe environment as like a typical cluster environment.
There is a strong movement toward cluster computing as a way of sharing the costs and benefits entailed by massive compute resources.
It turns out to be a lot like mainframe computing in terms of physical infrastructure and administration, and in fact often takes over disused mainframe computing centres, at least in the university space.
Unlike the mainframe environment, anyone with Unix/Linux experience is already equipped to take full advantage of cluster and grid computing. Either enviroment provides specialized resources that you have to learn how to access, but to me, the advantage goes to whichever environment provides the most universal expression of those resources, and is least likely to lock my efforts into one particular architecture.
A mainframe is an especially proprietary architecture. Portability has never been its strong point. Conversely, most cluster computations that I've seen have been quite trivially ported from one cluster environment to another. And to some degree it's in every vendor's interest to make it so.
The exceptions are interesting but, at this point, surprisingly rare. Relatively few researchers are decomposing problems in a way which requires either MPI or shared memory. Perhaps the field is not mature enough for that yet, much less for the sorts of computation envisioned by the Grid community, though that day will eventually arrive.
What I mean is, the biggest market for massive computation is always going to be driven by ordinary computation which happens to operate at a massive scale. And for that, the plainer, more symmetric, and more standardized the architecture, the better, because development and testing costs are not going to go down in the face of massive computing resources, they're going to go up.
The perfect mainframe, in other words, is one node in a Beowulf cluster. And that's fine. Just don't go running MQ Series on it, okay?
I read recently that the Tacoma bridge failure was due to a characteristic of suspended structures that could only have been modelled using chaos theory.
In other words, you're right that the engineering standards in place at the time were not entirely adequate, but there was no adequate alternative either. One would not emerge for about thirty years, at which point engineering practice would be revised.
It seems to me that this pattern of progress is mostly okay. It should give us a big dose of humility when we're contemplating building nuclear reactors, which is why they talk about the Tacoma bridge in engineering classes. On the other hand, an imperfect document standard, say, is quite a bit better than no standard at all.
"The commission said in 2004 that it decided not to settle with Microsoft because it wanted to set a precedent," Bellis told the court in his closing remarks. "Already, the commission is seeking to apply its precedent to features for Windows Vista - the new version of the operating system - such as a new feature that will protect Windows users from spyware infections."
This language is of course the same old veiled threat from Microsoft that we've seen used so many times before. If I'm bad, Santa might not bring me a new toy. And it's a really cool toy, really it is. Well, it will be. Well, it might arrive just a little bit late, but it will still be super cool. So I'd better not do anything bad to Microsoft, or else.
Whatever. It's not new language. And it demonstrates that Microsoft still does not have the first clue about security. Hello, everyone turn to page one. You can't get security by adding "features" to a bad design.
Absolutely right. Passwords are a way for humans to authenticate, not the only way and not even the best way. Identity is quite another matter. In an identity sense, passwords hold the same position as symmetric keys, trivial to replay if ever captured. For this reason, they're terrible as a way for systems to identify to each other.
What you really want for identity is a token that is easy for the owner to create, easy to validate, and very hard to capture and replay. Beyond Kerberos, X.509 certificates do this very well, and PGP/GPG has similar capabilities if you prefer a nonhierarchical certificate infrastructure.
People sometimes forget that SSL is capable of identifying both server and client. That's an example of X.509 mediating identity between parties in a session, which is often all we want. Of course these certificates can be used by other protocols as well, and unlike passwords, they don't have to be taken at face value because they can be validated through a trusted third party.
There is also the concept of an X.509 "proxy certificate" which Globus uses for grid transactions. The idea is that your computation can be securely passed around the grid because its identity is established by its accompanying proxy cert. I imagine this is similiar to using a Kerberos ticket as a proxy, but I stand to be corrected. The problem with any proxy is that, being preauthenticated, it can get away from you, and that aspect has to be balanced against possible convenience. The usual practice with Globus proxy certs is to give them a short lifetime so they can do their work on the grid and then expire.
Slashdot Mirror
You're joking, of course. It's a language specification.
If you insist on having a condensed version, it would read:
Conceivably, these sorts of questions could give rise to interesting debate. Or you could get a life.
I'm sure that people in Somalia will be shocked at your suggestion that their court has no jurisdiction elsewhere in the world. Come on, they are the centre of the universe. Everybody knows that.
Not all at once, of course. The point of having higher resolution is so that when you attend to one part of the scene, you won't perceive a reduction in image quality.
There are certainly tech support jobs out there which consist primarily of what we might call solving puzzles.
Generally, however, a technical person needs to be broadly competent, needs to have strengths in both analysis and design, needs to communicate well, needs to be able to manage relationships effectively, needs to be able to organize and prioritize effectively under directions which can be incomplete or ambiguous.
The best technical people are not just able to address the issues in front of them, they use them to generate leverage in making progress toward larger goals. They have to articulate and negotiate for those larger goals, which means they have to be sensitive to interests of other individuals, and to the potential for alignment and conflict among them.
These requirements hold especially for more senior positions. It's fine to be able to solve puzzles, but that's not most of the job. And as anyone with hiring experience knows, it's far more successful to gain senior people by letting them rise through the ranks than it is to hire them from outside the organization. Unless you make a point of attracting and hiring people who have that potential, you can risk ending up mostly with a whole bunch of puzzle solvers.
Even scientific research, which obviously tries to solve some very hard puzzles, is mostly driven by collaboration. I've seen generations of compuer science grad students come and go, and the ones that go furthest are invariably the most collaborative. Out of the practice of collaboration they seem to have an easier time understanding their work in context, and they seem able to pick up all the other necessary management skills along the way.
Actually, these are primarily infrastructure decisions, and they are properly based on cost/benefit over the lifetime of the infrastructure. It's incorrect to suggest that such decisions are either pro- or anti- education. They are neutral with respect to education.
More correct than the tired auto analogy, I think, would be if the decision were to standardize on a certain type of lighting system for school buildings which only lets students read books printed on compatible paper made only by the same company that makes the lights. The alternative would be a lighting system made from commonplace parts which works with paper whose formulation is widely understood and available from many different suppliers.
I wouldn't characterize this as a decision in which educators need to be involved at all. Typically we're not teaching students how to make paper, we're teaching subject material that just happens to be delivered on paper. And given that we have limited funds to replace lighting systems and books, we'd like to make a decision that doesn't lock us into a single expensive solution that also makes us dependent on a certain brand of paper.
Sure, in the short term we might lose access to certain desirable book titles because they're only printed on that special paper. That can be a problem, but not a fundamental one, and therefore not one which weighs greatly in the long term when we're talking about building infrastructure. There's no reason that any book title cannot be printed on ordinary paper, and it's in the nature of economics that if the market wants it, sooner or later the market will get it.
Some time ago we left behind the idea that computers were in schools in order to educate students about computers. You and I might be personally interested in that subject, but it's really not driving a lot of decisions. And yes, as a personal preference I'd rather learn everything about an open system than just the surface information about a closed system. There's a reason why Unix took off so dramatically in university computer science curricula, why it appears in so many research papers on operating system design, and so on. You want to design a different process scheduler, or filesystem, or security model? Off you go. Unix won't stop you in any technical sense, and open source won't stop you in any legal sense.
So within this narrower area of education I'd say that open source very much wins in terms of promoting education. It's hard to get around the issue that proprietary systems necessarily promote ignorance.
I got it, even if nobody else did. Mod funny for sure.
I'm with you, as long as nVidia doesn't lock it up and throw away the key.
I have a longstanding fondness for OpenGL but it doesn't work if it stays on just one graphics platform either. It's for portability. So by that reckoning, Apple would make a better steward. Apple has good reason not to tie itself to any one component vendor, and OpenGL helps it in that purpose.
The day will come when devices identify by certificate rather than by MAC, and that will make this architecture firmly secure.
The situation is reminiscent of the time when city streets were obscured by the number of overhead wires carrying competing telephone services. Since services did not interoperate, this situation did not scale and was not sustainable. It eventually collapsed under economic and public pressures. In Canada, at least, it eventually became a small number of regulated monopolies overseen by the CRTC, and even these are now obliged to carry each others' services.
But even this carries a useless residue of old-economy thinking. It's suboptimal, and not in the public interest, for information content providers to control, even indirectly, a differentiation in how information is delivered to the premises.
A more appropriate model for information delivery, and one which we can already see actively taking form in many regions, would be municipal power or water or gas. All three cases are much more similar to each other than any of them are to some narrow service such as telephone or television. There is nothing to differentiate one bit, or one molecule, or one coulomb, from another. They're universal resources, period.
If you want to build an industry that depends on these resources, in the way that home electronics depends on power, you no longer have to take it upon yourself to run power transmission lines to the home. A hundred years ago, yes, it was an issue. Now, you can assume that the power is already being delivered, and if your device happens to need 5VDC, you convert it at the device. We're rapidly going that way with information, as well we should.
Old-economy providers ignore this at their peril. As a friend of mine used to say, you can be part of the solution, or part of the precipitate.
Not that I have anything in principle against the concept of unified security management, except for the little matter that security is an emergent property of the entire system under consideration and not something that can be separated out into an external appliance, no matter how nice and easy that might seem. For example, the "emerging threat from viruses" represented in the article is due to choices in system design which egregiously ignore the problems that might result from installing any random blob of data as system software.
Indeed, perimeter security has never been regarded as sufficient, merely convenient. Many uses of networks have no natural perimeter, university campuses for example. The alternative concept of defense in depth has been the subject of ongoing discussion for at least a decade now, but it does require some effort to model what is allowed to communicate with what, and that in turn forces the question of identity. All of that is sort of hard. Not impossible, but you have to think about what you're doing, and maybe stop doing some of the bad stuff. You can't just take a pill to make it go away.
It seems like an elegant idea to use the turbine to generate electric power instead, especially since we've seen so much parallel improvement recently in electric powertrains for smaller vehicles.
I don't know why there has been no mention of this either, if only to point out where the losses would have to be reduced in order to break even with competing forms of power delivery.
Yes indeed, though I don't know who exactly was driving the process at SGI, I saw it all unfold.
SGI performed very well in the era when it dominated the graphical Unix workstation market. It had a superior product in an expanding market. The market was strong in significant degree because there was a healthy mix of other Unix platforms which interoperated fairly well together, and it was an exciting time for both hardware engineering and operating system design. Then two things happened.
The first development was that the industry became fractious as the commercial Unix vendors began to get grandiose ideas of dominance. Unix interoperation began to suffer and the market became distinctly less shiny because of all the dust in the air. Other changes were affecting the industry as a whole, but this one touched SGI particularly, because IRIX was not extremely great at interoperation to begin with, and it was frankly a pain to look after on a large scale. So customer loyalty was becoming a bit fragile at that point.
The second development was that SGI chose that moment to undertake a major change of strategy. Rather than competing as a supplier of graphical Unix workstations, it tried to move up the stack and reposition itself as a supplier of unique graphics applications, the platform now being regarded as somewhat incidental. Unsurprisingly, this proved to be a much smaller market than before, and not especially receptive to the product suite which SGI had to offer.
The Unix market rapidly lost interest in SGI thereafter. A second repositioning by SGI around shared-memory supercomputing was technically interesting but again somewhat off on the sidelines where economies of scale are smaller and development costs higher.
Is this anything like the Microsoft story? I can't see many parallels, myself, except perhaps for internal morale issues which are not unique to these two, that's for sure. Certainly, Microsoft enters lots of markets where it does badly and wastes a lot of money, and through hubris it has been late to the party at almost every interesting development in the industry, from system design principles to the graphical interface and from security to networking. But those are ventures, and at least, whatever risk it takes on them, Microsoft continues always to sit heavily on its core market. I think what hurt SGI most was confusion over what its core market should be.
I don't offer these comments unkindly. The fact that you had the will to make things better is praiseworthy. But making things better is not just about your indulging your personal opinion. A Wiki exists to serve the needs of a community, after all. Now that you know who will be the stakeholders in such a project, you can see how much more sucessful the project is likely to be if you gain their support beforehand.
It's unlikely that anyone wanted your Wiki shut down in order to make your life miserable. Thinking about it from a less narcissistic point of view, it seems likely that people, especially people responsible for network security, don't support the idea of developing a Wiki that lives on someone's laptop. It's a bad idea. Just because it's your bad idea doesn't necessarily mean it's all about you. You could be a nice guy who had a bad idea. We all do occasionally.
It's as stupid in its way as people "discovering" the Internet a few years ago. In their haste to stake claims all over it, they neglected to notice that it was actually a set of artifacts created, with considerable effort, by people who came before them.
And didn't we hear this once already with something called Web Services? Let's transport everything over Port 80, that's really innovative. If we must call it anything, let's call it Hubris 2.0. Maybe, like Madonna, it will eventually go away if we just ignore it.
Some people here still expect beta to mean beta, which is conventionally intended to identify bugs in an otherwise stable product. A beta release is not, as you suggest, an invitation to change the feature set, though that has never prevented Microsoft from bending the rules at its convenience.
To be charitable, I can imagine that with this Vista beta, the codebase might indeed be as stable as what we ordinarily expect from a beta release, and so what we're looking at now is just a matter of tuning the configuration parameters so that it prompts at the right thresholds. And, on the principle of security by default, the system will initially tend toward maximum prompting. However, thinking more soberly, a secure system will have fully addressed these issues at the design level, and prompting will not be excessive but appropriate and meaningful. If it's not, that's a clear sign that the design has deeper problems than can be fixed just by changing the prompting parameters. Pardon my cynicism, but in my experience, that would be entirely typical of Microsoft.
Definition of beta at: Wikipedia.
For usability see: Whitten and Tygar.
You're right that this requires active involvement, like say by network and other service providers at various points. Of course, no provider could possibly be persuaded to do that, but as you point out, it's not necessary to make it easy.
Anyway, the identity part is something that possibly needs to be talked about more often. Any community can develop a useful public key infrastructure, and I think doing so brings several advantages over the sort of one-to-one key exchange you're describing. For one thing, it scales better, and for another, it allows parties to identify each other without previously having established trust out of band.
Of course, it does require trusting some third party as a certificate authority or introducer, but that's a reflection of ordinary life. There's no getting around having to ground identity in something, and as a general thing I'd rather be sure that I know who I'm building a secure channel with than want to insist on some kind of anonymity for myself. And anonymous identities can be created if that specifically is required.
David Lorge Parnas
He was at Chapel Hill for quite some time also.
You don't have much of a cluster without these features, so it would be more accurate to call them standard cluster capabilities. It's indeed true that when you get up to a thousand nodes or so, it takes a fair bit of staff time out of every day just for swapping out bad drives and so on. But this is the nature of mechanical devices. A mainframe is not somehow magically free of these issues. At the same scale, it will have the same number of disk spindles and memory chips. Only the apparent granularity of failure is different to the system operators, and of course the solutions tend to be much more proprietary.
I think that the picture from Google is necessarily unique. Google has built itself a highly specialized computing environment out of commodity components. A lot of the elements required of a general purpose HPC facility have been bypassed for the sake of efficiency in this specialized context. In short, practically the whole thing is system, and what you would classically call the application layer actually resides on the client browser.
As you say, that one exception came about because it was imposed as a response to tactics which were so egregiously proprietary that the courts had to intervene. Prior to that time, IBM would cut off your air supply if you dared to put hardware from someone else in the machine room. I saw it done, believe me. And legislation was not enough by itself. Until Gene Amdahl came along with a plan B, the money you'd save on peripherals just wasn't worth the risk. It would be fair, I think, to call that environment "proprietary" in every sense that human ingenuity could devise.
I was talking about architectural portability, which is at quite the other end of the spectrum. Architecture concerns something more than just hardware, or operating systems for that matter. It involves the whole stack of relationships between services and resources. To make a reductio sort of argument, you don't get a portable architecture just by opening the machine instruction set. At best you get to buy into a very limited status quo.
I know, I know, the IBM thing was about interconnects and all kinds of stuff too, but in those days people smoked all day at work, and they still thought it was normal and healthy to program applications in assembler, too. If you wanted to port your application to another environment, you had big work to do.
It's a whole different story if you develop for a cluster environment. Of course you can still hoop yourself if you try very hard, but the environment isn't deliberately set up so you'll tend to do that. People forget that this has not been historically so where mainframes are concerned, and that many of the design decisions made then carry through today. Caveat emptor.
Not to detract from your argument, but actually, it would.
WestGrid, for example, where I used to work, has a storage cluster with a HFS which I recall supported 30 TB on disk and 200TB on tape. That was a couple of years ago, and it may have been augmented since then, given the amount of data from CERN that we expected to process. A lot of research infrastructure funding is going in this direction, because what makes these facilities especially valuable is the variety of different kinds of research they can support.
Some of it is certainly very CPU/FPU intensive, but you may be surprised to learn that a substantial component of high performance computing is raw data movement, in particular ad hoc search of massive, sparse, typically nonuniform datasets. As I understand, the nuclear experiments now coming onstream are expected to generate in the order of 20 PB per event. Genome work likewise produces voluminous data of potentially very high value, though obviously not all of it will be equally valuable and therefore efficient search is a critical factor in storage design. Undersea sensing projects such as Neptune are expected to generate more data than they can possibly store, which presents some very interesting challenges for storage architecture given that sensors will have to be switched on and off on demand.
So, to return to my original point, if I had to invest effort in developing software for a high performance environment of any kind, I'd want that environment to be a very general, very versatile one, with a minimum of proprietary features and APIs. Not, in other words, so much like a typical mainframe environment as like a typical cluster environment.
It turns out to be a lot like mainframe computing in terms of physical infrastructure and administration, and in fact often takes over disused mainframe computing centres, at least in the university space.
Unlike the mainframe environment, anyone with Unix/Linux experience is already equipped to take full advantage of cluster and grid computing. Either enviroment provides specialized resources that you have to learn how to access, but to me, the advantage goes to whichever environment provides the most universal expression of those resources, and is least likely to lock my efforts into one particular architecture.
A mainframe is an especially proprietary architecture. Portability has never been its strong point. Conversely, most cluster computations that I've seen have been quite trivially ported from one cluster environment to another. And to some degree it's in every vendor's interest to make it so.
The exceptions are interesting but, at this point, surprisingly rare. Relatively few researchers are decomposing problems in a way which requires either MPI or shared memory. Perhaps the field is not mature enough for that yet, much less for the sorts of computation envisioned by the Grid community, though that day will eventually arrive.
What I mean is, the biggest market for massive computation is always going to be driven by ordinary computation which happens to operate at a massive scale. And for that, the plainer, more symmetric, and more standardized the architecture, the better, because development and testing costs are not going to go down in the face of massive computing resources, they're going to go up.
The perfect mainframe, in other words, is one node in a Beowulf cluster. And that's fine. Just don't go running MQ Series on it, okay?
In other words, you're right that the engineering standards in place at the time were not entirely adequate, but there was no adequate alternative either. One would not emerge for about thirty years, at which point engineering practice would be revised.
It seems to me that this pattern of progress is mostly okay. It should give us a big dose of humility when we're contemplating building nuclear reactors, which is why they talk about the Tacoma bridge in engineering classes. On the other hand, an imperfect document standard, say, is quite a bit better than no standard at all.
This language is of course the same old veiled threat from Microsoft that we've seen used so many times before. If I'm bad, Santa might not bring me a new toy. And it's a really cool toy, really it is. Well, it will be. Well, it might arrive just a little bit late, but it will still be super cool. So I'd better not do anything bad to Microsoft, or else.
Whatever. It's not new language. And it demonstrates that Microsoft still does not have the first clue about security. Hello, everyone turn to page one. You can't get security by adding "features" to a bad design.
What you really want for identity is a token that is easy for the owner to create, easy to validate, and very hard to capture and replay. Beyond Kerberos, X.509 certificates do this very well, and PGP/GPG has similar capabilities if you prefer a nonhierarchical certificate infrastructure.
People sometimes forget that SSL is capable of identifying both server and client. That's an example of X.509 mediating identity between parties in a session, which is often all we want. Of course these certificates can be used by other protocols as well, and unlike passwords, they don't have to be taken at face value because they can be validated through a trusted third party.
There is also the concept of an X.509 "proxy certificate" which Globus uses for grid transactions. The idea is that your computation can be securely passed around the grid because its identity is established by its accompanying proxy cert. I imagine this is similiar to using a Kerberos ticket as a proxy, but I stand to be corrected. The problem with any proxy is that, being preauthenticated, it can get away from you, and that aspect has to be balanced against possible convenience. The usual practice with Globus proxy certs is to give them a short lifetime so they can do their work on the grid and then expire.