Getting a computer science degree isn't about understanding every technology that's been built out there.
Exactly! Any technology is just a collection of artifacts. Effective technology is based on good science, and this holds just as true for computer science as for other fields.
So where does this bizarre expectation come from that computer scientists are the product of technology training? Is our 21st century culture really that ignorant of science?
I don't think this level of misunderstanding exists in other fields. For example, I don't hear people claiming that a degree in biochemistry is a series of training courses in how to operate the latest line of Bruker NMR spectrometers, or ABI capillary gene sequencers, or the like. Of course, the curriculum probably touches somewhere on the principles of spectrometry, and certainly in great detail on genetics. But nobody seems to confuse those subjects with technology.
So why does computer science come in for different treatment?
We have a set of papers that are pretty light on the details of what is required for a computer to be certified for secret information
This seems incongruous to me. You've either (a) been given a set of security requirements under the terms of your contract, or (b) you haven't.
a)
If you have, then you have the means of deciding whether to build or buy a solution which meets them. There's no point in asking Slashdot for guidance when we don't know what your requirements are. At best, you'll just get speculative nonsense.
b)
Conversely, though it seems unlikely that there would be no specific security requirements in a DoD contract, if that's the case, then you would be free to use your own judgement when developing a solution. Of course, if you judge wrong you'll end up with an unhappy client.
What I was really trying to ask was, "In your experience, is the extra money going into a vendor worth it or, is it better just to by a chassis and setup a machine yourself?"
Well, that answer would depend on the specific requirements, wouldn't it?
Man didn't cause the desertification of the Sahara region, but it happened...
[I'm late coming to this, but I happened to see your comment while I was metamoderating.]
According to historical records, what is now the Sahara desert was fertile cropland during the Roman Empire. Its ensuing salinification and loss of soils marks the first widespread environmental disaster directly attributable to human activity.
Psychopathology, like all pathologies, is by definition a trait that operates destructively.
Yes, the trait is in the gene pool because it works, but it need only benefit the organism itself, consequences to others be damned.
A herbivore might say that carnivores are pathological. Parasites are likewise destructive of an individual host organism. You're arguing that this process is "often" good for the victim population. It may be in some cases (the "cull the weak and diseased" scenario) and thus effect natural selection, but it may equally kill a healthy individual, and it can ultimately lead to the destruction of entire species.
From an evolutionary perspective, it would be hard to argue that such effects are to the good. The beauty, and evolutionary value, of each species is its distinctive solution to a set of natural constraints. But if too many constraints are imposed, the solution disappears, for a net loss in biodiversity.
Of course pathological behavior works, for the predator or parasite. How not, when there's such a concentration of energy ready to be harvested? So it's not surprising that humans find themselves with such creatures within their own species. Sometimes they kill us by the millions, more often they're just a drag on our energy. And once in awhile, as you say, they may be uniquely able to break through some kind of impasse and thus, accidentally, do some good.
We need authenticatable (if there is such a word) emails, IMs etc yesterday.
Sure, fine, we all know that. But the practical question is how do you start up such a communication in the first place? In other words, how do two parties share a secret without communicating it, and thereby risking its exposure?
The answer is not to share a secret, but instead to use an asymmetric key pair and only communicate the public key. But this only solves part of the problem. Now you can communicate in secret, but you can't be sure who is on the other end.
The answer to this second problem is for both parties to register with a trusted third party. This is why organizations such as Verisign exist, and likewise why PGP has the concept of a "ring of trust". Got it?
There's nothing wrong with using cookies to prevent me from having to logon to Slashdot 10 times a day.
Yes, single signon is nice. Though cookies are not exactly the most secure way to implement it.
And there is nothing wrong with cookies telling Amazon.com that people who buy Movie X also like to buy Book Y.
No, in this example, cookies are completely superfluous.
Amazon already had to manage your account information when you bought Movie X and Book Y. Its invoicing and shipping process depends on such data. So it's already correlated that you bought Movie X and Book Y. It would be a bizarre implementation indeed that ignored all that data and instead went off and parsed uncorrelated cookies instead!
I don't need any help in remembering my ID, password, or credit card number, thank you.
And if you did, the most secure place to set it up would under control of your browser. Firefox has a form manager which does this quite well already.
But the nature of forms, or cookies for that matter, is that similar information has to be passed again and again to many different servers.
A useful browser enhancement would be to have a configuration window where such information could be recorded canonically against a set of tags. Then to fill in a new form, you'd just supply the appropriate tag. Later, if you needed, say, to change an account number or an address, you'd only do it in one place, the configuration window. Neither cookies nor server-side databases can do that for you!
But speaking of security, something potentially much more important would be enabled by this model. You could configure not only form data but also XML data in the same way. Now you have an extensible means of supplying digital certificates, crytographic tokens, or any other object that you care to define. If security is a concern, you may elect not to pass certain objects in cleartext, or to require confirmation by the browser. The point is, such behavior is entirely local and under your control.
It could even be used to generate data such as digital signatures under conditions of your choosing. Since you manage this information directly, the entire process can be much more secure than putting it under the care of some remote server.
Yep, the "science" part of Science Fiction is actually quite hard to do.
Science is concerned with investigating properties of the universe, or of mathematics, that we don't presently understand. Pretty much by definition, that means that we don't know what will result from scientific discovery.
Generally speaking, however, science tends to confirm in greater detail what we already know. Ho hum. At that rate, reality seems a pretty boring thing to investigate. Of course it's not, but it takes a certain discipline to appreciate the more subtle kind of discovery that science typically delivers.
People tend to react with anger when their expectations are not met. For that reason, I think it's most unfortunate that, as a society, we've suddenly come upon science and have elected to treat it like a giant video game. We're bound to be disappointed, just as we were in the dot com bubble.
People who encountered the Internet for the first time thought that they were witnessing a sudden explosion of technology. They had no idea, and evidently no interest in acquiring the idea, that the Internet was the result of gradual development that had gone on for decades before that, right back to Von Neumann if you like. They didn't care to see that the rate of development over this period was about as rapid as human industry could make it.
Dot com investors, however, thought they were seeing a radically shorter timeline, thus a steeper growth rate, thus unrealistic expectations that such a rate would continue or even accelerate, thus all sorts of crazy excesses, thus harsh disappointment and a sudden retreat of capital. All of this proved catastrophic for a lot of us in what had, until that time, been a stable industry.
The actual rate of progress continues to be about as rapid as we can make it. We simply have to be satisfied with that. Science is not a consumer product, and wanting a thing very, very, very much does not magically make it possible. Science fiction is a valuable form of speculation, but the physical properties of the universe are not likely to change through greed or wishful thinking.
Let's take a lesson from Easter Island. It's now a barren outcropping of rock, treeless and desperately uninhabitable, though dotted with large stone statues that suggest it once supported a flourishing civilization. Unfortunately, it seems that civilization got a bit carried away with the technology of carving statues and transporting them using log rollers. There came a time when the last tree was cut down, the last animal hunted to exinction. The remaining inhabitants turned their fury on the statues, smashing and defacing them, but it was too late. Lacking materials from which to build boats, they had no means to escape the island.
A car's internal combustion engine will generate a LOT more pollution per unit of energy than a power plant.
I've heard this claim before, but can you actually provide any sort of proof to back it up? I suspect you can't, but I'd like to be proven wrong.
I don't have any numbers to offer, but just consider the design constraints.
For example, car engines have to deliver rapid acceleration. They have to be lightweight. They have to be cheap. Power plants are stationary, so weight is not a concern. They don't need to accelerate under load, and since they have a very long planned lifetime, a very different tradeoff can be made between capital cost and operating efficiency.
Power plants can be tuned for maximum efficiency under specified conditions. Car engines have to deliver high performance under a much wider range of conditions, which makes many aspects of their design less efficient.
That said, power plants are not perfectly efficient. For example, as others have noted, losses will be incurred in electrical generation, transmission, and transformation. There will be further losses if storage is involved, and if not, there's always the challenge of handling peak loads on the power grid.
I once visited some friends in Scotland who have retired to an old farming estate. About a hundred years ago, the former owner had dammed one of the becks, built a power house, and installed a generator. With the massive stone building, cast iron turbine, porcelain insulators, giant knife switches, exposed wire, and water dripping everywhere, it was quite something to behold.
It must have been a significant investment, but must also have been considered worthwhile in its day. My point is that both technology and economics play into the equation. Local stationary power generation was once the best deal going, and probably still is under some conditions.
Licensing aside, it's a good practice when designing a system to think about portability. It buys a certain amount of "future-proofing" and it also tends to improve the design. There's also that old wisdom within the IETF about wanting to see at least two working implementations of a thing. These might have been considerations for Google.
When I write applications for Unix, my primary concern is that they work correctly in both Linux and Solaris. That nicely exercises most of the portability issues, and as Unix APIs go, they're not very far from the ideal center of mass. I find that when I do this, I can adapt to other Unix variants quite easily, whereas I end up doing a lot of grumbling and fiddly refactoring of IFDEFs if I go the other way around.
I think it is a question of mentality rather than logic.
In fact, there was nothing wrong with using Apache as an example. Clearly the world is with you on this one.
Now, if some third party such as Oracle wants to make a customized version of Apache, that can only mean one of two things:
It needs to add some specialized functionality. Fantastic! That's one of the great advantages of open source, that it empowers every organization and individual to do this. This would not be possible without open source.
It needs to fix some general problem, add some general functionality or security. In the spirit of open source, those sorts of changes should be given back to the community so that the entire codebase becomes more functional and more secure. It obviously benefits everyone, including Oracle, when this happens. This would not be possible without open source.
So it seems to me that, working with your example, your aunt has given you a logically compelling argument in favor of open source. Of course, she might not understand this, but then that's the usual problem, isn't it?
Transitioning from one platform to another can be incredibly expensive.
Particularly when the platform has been deliberately designed to lock you in. That means you lose out not only on less expensive alternatives but also on more interoperable or more secure ones. In any industry, having a single supplier for any critical resource is bad news.
Moral: do everything possible to avoid this type of platform in the first place. It's a trap.
I'm the sysadmin at a ~25 person architecture firm, and an architect, too.
...
FWIW, we spend ~$45k per year, which works out to be ~2.5 - 3.5 % of revenue.
That's equivalently about $2K/person/year for the complete IT infrastructure, which is another way to derive a bottom line for purposes of cost management. Both ways are useful, but for different reasons.
If you doubled the number of employees, a rough prediction would be to double this cost as well. You'd get some economies of scale, but you might also max out some technologies (server or backup capacity, firewall or network bandwidth, performance of shared filesystems) and have to move to a more expensive tier. Anyway, the point is that even a rough idea of scale is very useful along this dimension, and it's very easy to present.
Budgetting according to revenue is more subtle, because bits are not consumables in the same way as auto parts are to the auto industry, for example. Revenue is not directly an input to infrastructure calculation. If the company generates more revenue, it could be an opportunity to improve the infrastructure, but that depends on the state of the infrastructure relative to the expected effect of improvements on productivity, both of which are hard to quantify numerically and hard to estimate even qualitatively.
Improving the infrastructure should have some effect on productivity, and it should help to attract and retain better employees, and it should make a better impression on clients in various ways. Those are issues which deserve debate, and of course buying new stuff is always fun. But there are no guarantees. The usual problem, in my experience, is not in getting management interested in this kind of discussion, but making sure that the bread and butter costs are not overlooked because of it.
Plus, you're probably not interested in stars that only shine when the sun is out!
The LED idea seems like it would be very effective, anyway, easy to build, and cheap too. Stars are effectively point sources, so you're right to choose small light elements. LEDs are available in some fairly small standard packages, and I've also seen them where the lens is an even smaller cylinder protruding from the main molding.
Sounds like fun. Now, if only you could get the ceiling to rotate through the seasons...
Ordinary reflective materials like mylar are quite lossy. That's not a big problem when the light path is fairly straight and only a few meters long, which I expect would be true in many residential applications. But if you want to go long distances or direct a lot of light energy around corners, you would need more efficient transmission.
But you're right that light fibers aren't exactly big news for illumination. And they're not the only medium with low transmission losses, either. About 20 years ago, a friend of mine started up a company called TIR Systems to commercialize a light pipe technology that he developed in grad school. It works approximately like optical fiber but the prism light guide is much larger, and also requires less elaborate manufacture. The early materials that I saw were pressed out of large slabs of acrylic or something. At any rate, it seems much better suited to architectural application than bundles of optical fiber. And that's old news too.
Genera, unless I'm mistaken, was based on Zetalisp (LispMachine Lisp) with an object system named "Flavors", a message-passing system with mix-ins loosely based on Smalltalk.
You're correct. The Genera operating system, GUI, and applications were originally written in Zetalisp. As the Common Lisp standard emerged, the stack was ported to Common Lisp, which triggered the development of something called CLOS to replace the Flavors object system.
It's a very appealing concept to have a computing environment which unifies everything under one common notation, so that system calls are really no different whether invoked by an application, or on the command line, or bound to some key sequence in the editor or to some object displayed in the GUI. And the code quality in Genera is an absolutely outstanding example of what can happen when brilliant programmers go to work in an extremely expressive programming environment.
So why has Genera become a historical footnote rather than an enduring model for software development? Well, chiefly of course, its platform never achieved a competitive economy of scale. It proved to be too exotic, and far too expensive, for all but the most advanced research projects.
But market forces aside, I suspect that Genera would have been in for a very rough ride anyway. Yes, the concept was elegant, the design was inspired, and the code was beautiful. But system crashes in the early years of a new system are not uncommon, and what you saw in the debugger during a crash was not at all like what you were led to expect from the Genera documentation.
System calls in Genera typically turned out to be macros, which expanded as often as not into multiple methods invoked from multiply inherited superclasses embedded in wrappers and whoppers and ever more macro expansions, so that there might be a dozen mysterious frames on the stack, along with another dozen mysterious object classes, for any one documented system call. Yes, there is a certain natural complexity in the problem domain that has to be reflected in the code, but what you saw on the stack was heavily dominated by implementation artifact. Maybe for the implementors this situation would have been attractive, but in terms of site operations it really did not reward anything short of obsessive commitment to the platform. Sites found that they made more practical advances, far more cheaply, using Unix workstations which the regular programming crowd could straightforwardly use and understand.
So what's the moral here? I've been pondering this question for years, and I still don't know exactly what to conclude. In terms of experimental result, the story does seem to be telling us that pure creative excellence and a clean slate does not necessarily win out over the dull, prosaic, conservative grind by which systems slowly accumulate functionality over time. You accumulate nasty artifacts with both approaches. I wish it weren't so.
Yep, the strategy which Microsoft originally used to get ahead of the competition was to ignore the calls for security that everyone else was spending effort on at the time. Not having a login at all, for example, was one way to make a statement about where security fit into product design.
Sure, you can always add this stuff later to a given design, but at that point it's not just a massive rewriting effort. For one thing, you have to somehow find and fix all the design assumptions arising from lax security in the code. I'm not talking about implementation problems like buffer overflows, which are easy and transparent to fix, I'm talking about design tradeoffs which promote features such as executable content without regard for security.
Any system gives rise to dependencies among its various explicit and tacit behaviors. It pays to proceed carefully from the start, rather than being cavalier about security. It's hard to get the genie back into the bottle. And, as the LUA effect illustrates, after awhile those assumptions are no longer just in your code base, they're out in the marketplace as well. It's no longer merely a technical matter, or a feat of changing corporate culture, you have to convince an entire industry to back up and try again.
Sxip is not now in stealth mode, but the publications just started flowing a few months ago.
Sxip itself has been running for a couple of years. During that time, if you landed on the Sxip website, you'd see a notice saying "We are running in stealth mode right now. Check back later."
And when a problem is suited to scripting, it's also simple to implement over distributed systems. True scripting languages are inherently serialized, hence there is no issue with passing objects between systems.
You can't do everything this way, but there are many useful cases when you can, remote system management being one example. Then what you don't want is to find yourself stuck with yet another bloated vendor language that gets in the way of clean interoperability.
Since two out of two followups have both mistakenly assumed that I speak for Sxip Networks, I offer a clarification.
I'm not associated with Sxip in any way. I happen to be interested in identity management, that's all. Sxip is a player in that space.
Also, while we're at it:
Identity management is not a meaningless buzzword but is instead an established field of software engineering. It delivers one critical element required to securely integrate and extend a set of distributed systems. It can be a challenging area to work within, since its principles require a broad knowledge of security and architecture, and in practice integration of systems which were never designed to a common identity model tends to be a very messy business. But it's interesting.
None of this is related in the least to CMS. Identity management is about identity, often introduced for simplicity as the identity of humans, but more broadly about the identity of abstract agents, whether they happen to be embodied as humans or systems. And it's only a simple concept if you approach it simplistically.
A third followup suggests that Sxip is a horrible example because he hasn't seen it in production. As I say, I'm not associated with Sxip, and I'm not defending its business plan. However, identity management is inherently infrastructural, and you have to play by those rules to stay in the game. Success doesn't happen overnight, or even as a necessary result of massive corporate resources, as Microsoft Passport illustrated some years ago. Sxip is approaching the matter in a very different way, as a small startup operating initially in stealth mode. At this point, we don't know whether its specific strategy and choice of technology will lead to success or failure. For that specific reason, I suggest that it's a good startup to watch.
Take for example Sxip which is developing an identity management infrastructure.
Sxip operated in stealth mode for about two years while it was ramping up. All discussion of merit aside, sometimes it takes that long to get the ideas and the team solid. Identity management is a good example of the old saying, "Things of quality have no fear of time."
This is simply another trap being laid by Sun and MS against Linux.
It may be. I know a very bright Microsoft zealot who thinks it is, and couldn't be more delighted at the prospect.
I don't think it is, myself. For one thing, the internal cultures of these two organizations, and the personalities they attract to senior positions, could not be more different. You just have to look at their past conduct to see this. Microsoft does lay traps, systematically, all the time. Sun is a corporate player too, thus in the game for profit, but its strategies are much more symbiotic in their essential character.
When Sun puts someone on a standards committee, it's to make the standard more valuable for everyone, on the express theory that it's better to share a growing market than have all of a stagnant one. When Microsoft puts someone on the same committee, it's to "embrace and extend" the standard so as to exclude competition, and the expressed goal is to eliminate all competition.
Another thing worth remembering is that an organization as big as Sun has substantial internal struggles from time to time. Such was the case with Solaris on X86. The project took off energetically at first, but it was a risky venture which happened to fall out of political favor just at the point when driver support was becoming most critical. The result was not a strategic withdrawl, it was a conspicuous fumble which cost Sun a lot of internal morale, hurt its reputation, and lost it a golden opportunity whose extent has only become more apparent in recent years.
So yes, it could all happen again, but not because of some nefarious strategy on the part of Sun Microsystems. Sun does not have a history of executing that way.
It might only be a minor point, but it's one which goes against any claims which might underly the "cease and desist" email.
According to the cdfreaks website, the PxLinux software simply uses a series of SCSI commands to retrieve statistical data from the drive. The same principle would also apply to ATAPI.
The SCSI command set is a set of published specifications specifically intended for such purposes. It cannot reasonably be the case that Plextor, the drive manufacturer, by following these specifications, expected to restrict the use of SCSI commands for drive control.
It's possible that there is some sort of exclusive software development agreement between Plextor and Shinano Kenshi, but that agreement is not binding on other parties.
It would also be possible, in principle, to sell these drives under condition not to use them except as strictly specified, but again such an agreement would not be binding on other parties.
In no case is it reasonable to seek damages against some third party who independently develops a means to use a manufactured device as intended. An impossible situation would clearly develop for both industry and the public at large if courts were to award such damages.
[I am not a lawyer, and the foregoing does not constitute legal advice.]
Yes. It's a question of putting the incentive close to where the action will be direct, effective, and habitual. The reward has to justify the effort involved.
In the case of beverage containers, it makes sense to collect and refund a deposit from the consumer, because the choice point occurs at the moment the container becomes empty. The incentive works because it's possible for a consumer to get into a pattern of thinking that the cans have enough value to be worth collecting.
In the case of recyclable packaging, on the other hand, the consumer is not involved in the packaging decision, but is already effective in separating the package from the product. So passing costs to the consumer exerts no incentive. But the retailer is involved, because the system can only work if retailers accept packaging to be recycled.
The challenge for electronics disposal is different again, because it's intimately related to product design. There would be little point in collecting electronics only to produce landfill in a different place. Therefore the incentive has to be applied where it will influence design most directly, and it's a hard problem.
But similar programs have become very successful for building materials. Awards and rewards for "green" designs help architects and builders stand out from the competition, and they have helped to seed an entire secondary industry in recycled materials. It works because there are strong economic advantages to the reuse of certain materials such as clear timbers.
Whether we can achieve a similar effect with electronics components is hard to predict. As long as designs keep becoming obsolete, the value of a component is no more than the value of its raw materials less the cost of extracting them.
Slashdot Mirror
Exactly! Any technology is just a collection of artifacts. Effective technology is based on good science, and this holds just as true for computer science as for other fields.
So where does this bizarre expectation come from that computer scientists are the product of technology training? Is our 21st century culture really that ignorant of science?
I don't think this level of misunderstanding exists in other fields. For example, I don't hear people claiming that a degree in biochemistry is a series of training courses in how to operate the latest line of Bruker NMR spectrometers, or ABI capillary gene sequencers, or the like. Of course, the curriculum probably touches somewhere on the principles of spectrometry, and certainly in great detail on genetics. But nobody seems to confuse those subjects with technology.
So why does computer science come in for different treatment?
This seems incongruous to me. You've either (a) been given a set of security requirements under the terms of your contract, or (b) you haven't.
a) If you have, then you have the means of deciding whether to build or buy a solution which meets them. There's no point in asking Slashdot for guidance when we don't know what your requirements are. At best, you'll just get speculative nonsense.
b) Conversely, though it seems unlikely that there would be no specific security requirements in a DoD contract, if that's the case, then you would be free to use your own judgement when developing a solution. Of course, if you judge wrong you'll end up with an unhappy client.
What I was really trying to ask was, "In your experience, is the extra money going into a vendor worth it or, is it better just to by a chassis and setup a machine yourself?"
Well, that answer would depend on the specific requirements, wouldn't it?
[I'm late coming to this, but I happened to see your comment while I was metamoderating.]
According to historical records, what is now the Sahara desert was fertile cropland during the Roman Empire. Its ensuing salinification and loss of soils marks the first widespread environmental disaster directly attributable to human activity.
Oh, yeah. So your car follows the ones in front of it instead of driving into the oncoming lane. I get it now. Smart.
A herbivore might say that carnivores are pathological. Parasites are likewise destructive of an individual host organism. You're arguing that this process is "often" good for the victim population. It may be in some cases (the "cull the weak and diseased" scenario) and thus effect natural selection, but it may equally kill a healthy individual, and it can ultimately lead to the destruction of entire species.
From an evolutionary perspective, it would be hard to argue that such effects are to the good. The beauty, and evolutionary value, of each species is its distinctive solution to a set of natural constraints. But if too many constraints are imposed, the solution disappears, for a net loss in biodiversity.
Of course pathological behavior works, for the predator or parasite. How not, when there's such a concentration of energy ready to be harvested? So it's not surprising that humans find themselves with such creatures within their own species. Sometimes they kill us by the millions, more often they're just a drag on our energy. And once in awhile, as you say, they may be uniquely able to break through some kind of impasse and thus, accidentally, do some good.
Sure, fine, we all know that. But the practical question is how do you start up such a communication in the first place? In other words, how do two parties share a secret without communicating it, and thereby risking its exposure?
The answer is not to share a secret, but instead to use an asymmetric key pair and only communicate the public key. But this only solves part of the problem. Now you can communicate in secret, but you can't be sure who is on the other end.
The answer to this second problem is for both parties to register with a trusted third party. This is why organizations such as Verisign exist, and likewise why PGP has the concept of a "ring of trust". Got it?
Yes, single signon is nice. Though cookies are not exactly the most secure way to implement it.
And there is nothing wrong with cookies telling Amazon.com that people who buy Movie X also like to buy Book Y.
No, in this example, cookies are completely superfluous.
Amazon already had to manage your account information when you bought Movie X and Book Y. Its invoicing and shipping process depends on such data. So it's already correlated that you bought Movie X and Book Y. It would be a bizarre implementation indeed that ignored all that data and instead went off and parsed uncorrelated cookies instead!
And if you did, the most secure place to set it up would under control of your browser. Firefox has a form manager which does this quite well already.
But the nature of forms, or cookies for that matter, is that similar information has to be passed again and again to many different servers. A useful browser enhancement would be to have a configuration window where such information could be recorded canonically against a set of tags. Then to fill in a new form, you'd just supply the appropriate tag. Later, if you needed, say, to change an account number or an address, you'd only do it in one place, the configuration window. Neither cookies nor server-side databases can do that for you!
But speaking of security, something potentially much more important would be enabled by this model. You could configure not only form data but also XML data in the same way. Now you have an extensible means of supplying digital certificates, crytographic tokens, or any other object that you care to define. If security is a concern, you may elect not to pass certain objects in cleartext, or to require confirmation by the browser. The point is, such behavior is entirely local and under your control.
It could even be used to generate data such as digital signatures under conditions of your choosing. Since you manage this information directly, the entire process can be much more secure than putting it under the care of some remote server.
Science is concerned with investigating properties of the universe, or of mathematics, that we don't presently understand. Pretty much by definition, that means that we don't know what will result from scientific discovery.
Generally speaking, however, science tends to confirm in greater detail what we already know. Ho hum. At that rate, reality seems a pretty boring thing to investigate. Of course it's not, but it takes a certain discipline to appreciate the more subtle kind of discovery that science typically delivers.
People tend to react with anger when their expectations are not met. For that reason, I think it's most unfortunate that, as a society, we've suddenly come upon science and have elected to treat it like a giant video game. We're bound to be disappointed, just as we were in the dot com bubble.
People who encountered the Internet for the first time thought that they were witnessing a sudden explosion of technology. They had no idea, and evidently no interest in acquiring the idea, that the Internet was the result of gradual development that had gone on for decades before that, right back to Von Neumann if you like. They didn't care to see that the rate of development over this period was about as rapid as human industry could make it.
Dot com investors, however, thought they were seeing a radically shorter timeline, thus a steeper growth rate, thus unrealistic expectations that such a rate would continue or even accelerate, thus all sorts of crazy excesses, thus harsh disappointment and a sudden retreat of capital. All of this proved catastrophic for a lot of us in what had, until that time, been a stable industry.
The actual rate of progress continues to be about as rapid as we can make it. We simply have to be satisfied with that. Science is not a consumer product, and wanting a thing very, very, very much does not magically make it possible. Science fiction is a valuable form of speculation, but the physical properties of the universe are not likely to change through greed or wishful thinking.
Let's take a lesson from Easter Island. It's now a barren outcropping of rock, treeless and desperately uninhabitable, though dotted with large stone statues that suggest it once supported a flourishing civilization. Unfortunately, it seems that civilization got a bit carried away with the technology of carving statues and transporting them using log rollers. There came a time when the last tree was cut down, the last animal hunted to exinction. The remaining inhabitants turned their fury on the statues, smashing and defacing them, but it was too late. Lacking materials from which to build boats, they had no means to escape the island.
I don't have any numbers to offer, but just consider the design constraints.
For example, car engines have to deliver rapid acceleration. They have to be lightweight. They have to be cheap. Power plants are stationary, so weight is not a concern. They don't need to accelerate under load, and since they have a very long planned lifetime, a very different tradeoff can be made between capital cost and operating efficiency.
Power plants can be tuned for maximum efficiency under specified conditions. Car engines have to deliver high performance under a much wider range of conditions, which makes many aspects of their design less efficient.
That said, power plants are not perfectly efficient. For example, as others have noted, losses will be incurred in electrical generation, transmission, and transformation. There will be further losses if storage is involved, and if not, there's always the challenge of handling peak loads on the power grid.
I once visited some friends in Scotland who have retired to an old farming estate. About a hundred years ago, the former owner had dammed one of the becks, built a power house, and installed a generator. With the massive stone building, cast iron turbine, porcelain insulators, giant knife switches, exposed wire, and water dripping everywhere, it was quite something to behold.
It must have been a significant investment, but must also have been considered worthwhile in its day. My point is that both technology and economics play into the equation. Local stationary power generation was once the best deal going, and probably still is under some conditions.
When I write applications for Unix, my primary concern is that they work correctly in both Linux and Solaris. That nicely exercises most of the portability issues, and as Unix APIs go, they're not very far from the ideal center of mass. I find that when I do this, I can adapt to other Unix variants quite easily, whereas I end up doing a lot of grumbling and fiddly refactoring of IFDEFs if I go the other way around.
In fact, there was nothing wrong with using Apache as an example. Clearly the world is with you on this one.
Now, if some third party such as Oracle wants to make a customized version of Apache, that can only mean one of two things:
-
It needs to add some specialized functionality. Fantastic! That's one of the great advantages of open source, that it empowers every organization and individual to do this. This would not be possible without open source.
-
It needs to fix some general problem, add some general functionality or security. In the spirit of open source, those sorts of changes should be given back to the community so that the entire codebase becomes more functional and more secure. It obviously benefits everyone, including Oracle, when this happens. This would not be possible without open source.
So it seems to me that, working with your example, your aunt has given you a logically compelling argument in favor of open source. Of course, she might not understand this, but then that's the usual problem, isn't it?Particularly when the platform has been deliberately designed to lock you in. That means you lose out not only on less expensive alternatives but also on more interoperable or more secure ones. In any industry, having a single supplier for any critical resource is bad news.
Moral: do everything possible to avoid this type of platform in the first place. It's a trap.
FWIW, we spend ~$45k per year, which works out to be ~2.5 - 3.5 % of revenue.
That's equivalently about $2K/person/year for the complete IT infrastructure, which is another way to derive a bottom line for purposes of cost management. Both ways are useful, but for different reasons.
If you doubled the number of employees, a rough prediction would be to double this cost as well. You'd get some economies of scale, but you might also max out some technologies (server or backup capacity, firewall or network bandwidth, performance of shared filesystems) and have to move to a more expensive tier. Anyway, the point is that even a rough idea of scale is very useful along this dimension, and it's very easy to present.
Budgetting according to revenue is more subtle, because bits are not consumables in the same way as auto parts are to the auto industry, for example. Revenue is not directly an input to infrastructure calculation. If the company generates more revenue, it could be an opportunity to improve the infrastructure, but that depends on the state of the infrastructure relative to the expected effect of improvements on productivity, both of which are hard to quantify numerically and hard to estimate even qualitatively.
Improving the infrastructure should have some effect on productivity, and it should help to attract and retain better employees, and it should make a better impression on clients in various ways. Those are issues which deserve debate, and of course buying new stuff is always fun. But there are no guarantees. The usual problem, in my experience, is not in getting management interested in this kind of discussion, but making sure that the bread and butter costs are not overlooked because of it.
The LED idea seems like it would be very effective, anyway, easy to build, and cheap too. Stars are effectively point sources, so you're right to choose small light elements. LEDs are available in some fairly small standard packages, and I've also seen them where the lens is an even smaller cylinder protruding from the main molding.
Sounds like fun. Now, if only you could get the ceiling to rotate through the seasons...
But you're right that light fibers aren't exactly big news for illumination. And they're not the only medium with low transmission losses, either. About 20 years ago, a friend of mine started up a company called TIR Systems to commercialize a light pipe technology that he developed in grad school. It works approximately like optical fiber but the prism light guide is much larger, and also requires less elaborate manufacture. The early materials that I saw were pressed out of large slabs of acrylic or something. At any rate, it seems much better suited to architectural application than bundles of optical fiber. And that's old news too.
You're correct. The Genera operating system, GUI, and applications were originally written in Zetalisp. As the Common Lisp standard emerged, the stack was ported to Common Lisp, which triggered the development of something called CLOS to replace the Flavors object system.
It's a very appealing concept to have a computing environment which unifies everything under one common notation, so that system calls are really no different whether invoked by an application, or on the command line, or bound to some key sequence in the editor or to some object displayed in the GUI. And the code quality in Genera is an absolutely outstanding example of what can happen when brilliant programmers go to work in an extremely expressive programming environment.
So why has Genera become a historical footnote rather than an enduring model for software development? Well, chiefly of course, its platform never achieved a competitive economy of scale. It proved to be too exotic, and far too expensive, for all but the most advanced research projects.
But market forces aside, I suspect that Genera would have been in for a very rough ride anyway. Yes, the concept was elegant, the design was inspired, and the code was beautiful. But system crashes in the early years of a new system are not uncommon, and what you saw in the debugger during a crash was not at all like what you were led to expect from the Genera documentation.
System calls in Genera typically turned out to be macros, which expanded as often as not into multiple methods invoked from multiply inherited superclasses embedded in wrappers and whoppers and ever more macro expansions, so that there might be a dozen mysterious frames on the stack, along with another dozen mysterious object classes, for any one documented system call. Yes, there is a certain natural complexity in the problem domain that has to be reflected in the code, but what you saw on the stack was heavily dominated by implementation artifact. Maybe for the implementors this situation would have been attractive, but in terms of site operations it really did not reward anything short of obsessive commitment to the platform. Sites found that they made more practical advances, far more cheaply, using Unix workstations which the regular programming crowd could straightforwardly use and understand.
So what's the moral here? I've been pondering this question for years, and I still don't know exactly what to conclude. In terms of experimental result, the story does seem to be telling us that pure creative excellence and a clean slate does not necessarily win out over the dull, prosaic, conservative grind by which systems slowly accumulate functionality over time. You accumulate nasty artifacts with both approaches. I wish it weren't so.
Sure, you can always add this stuff later to a given design, but at that point it's not just a massive rewriting effort. For one thing, you have to somehow find and fix all the design assumptions arising from lax security in the code. I'm not talking about implementation problems like buffer overflows, which are easy and transparent to fix, I'm talking about design tradeoffs which promote features such as executable content without regard for security.
Any system gives rise to dependencies among its various explicit and tacit behaviors. It pays to proceed carefully from the start, rather than being cavalier about security. It's hard to get the genie back into the bottle. And, as the LUA effect illustrates, after awhile those assumptions are no longer just in your code base, they're out in the marketplace as well. It's no longer merely a technical matter, or a feat of changing corporate culture, you have to convince an entire industry to back up and try again.
Sxip is not now in stealth mode, but the publications just started flowing a few months ago.
Sxip itself has been running for a couple of years. During that time, if you landed on the Sxip website, you'd see a notice saying "We are running in stealth mode right now. Check back later."
And when a problem is suited to scripting, it's also simple to implement over distributed systems. True scripting languages are inherently serialized, hence there is no issue with passing objects between systems.
You can't do everything this way, but there are many useful cases when you can, remote system management being one example. Then what you don't want is to find yourself stuck with yet another bloated vendor language that gets in the way of clean interoperability.
I'm not associated with Sxip in any way. I happen to be interested in identity management, that's all. Sxip is a player in that space.
Also, while we're at it:
A third followup suggests that Sxip is a horrible example because he hasn't seen it in production. As I say, I'm not associated with Sxip, and I'm not defending its business plan. However, identity management is inherently infrastructural, and you have to play by those rules to stay in the game. Success doesn't happen overnight, or even as a necessary result of massive corporate resources, as Microsoft Passport illustrated some years ago. Sxip is approaching the matter in a very different way, as a small startup operating initially in stealth mode. At this point, we don't know whether its specific strategy and choice of technology will lead to success or failure. For that specific reason, I suggest that it's a good startup to watch.
Sxip operated in stealth mode for about two years while it was ramping up. All discussion of merit aside, sometimes it takes that long to get the ideas and the team solid. Identity management is a good example of the old saying, "Things of quality have no fear of time."
It may be. I know a very bright Microsoft zealot who thinks it is, and couldn't be more delighted at the prospect.
I don't think it is, myself. For one thing, the internal cultures of these two organizations, and the personalities they attract to senior positions, could not be more different. You just have to look at their past conduct to see this. Microsoft does lay traps, systematically, all the time. Sun is a corporate player too, thus in the game for profit, but its strategies are much more symbiotic in their essential character.
When Sun puts someone on a standards committee, it's to make the standard more valuable for everyone, on the express theory that it's better to share a growing market than have all of a stagnant one. When Microsoft puts someone on the same committee, it's to "embrace and extend" the standard so as to exclude competition, and the expressed goal is to eliminate all competition.
Another thing worth remembering is that an organization as big as Sun has substantial internal struggles from time to time. Such was the case with Solaris on X86. The project took off energetically at first, but it was a risky venture which happened to fall out of political favor just at the point when driver support was becoming most critical. The result was not a strategic withdrawl, it was a conspicuous fumble which cost Sun a lot of internal morale, hurt its reputation, and lost it a golden opportunity whose extent has only become more apparent in recent years.
So yes, it could all happen again, but not because of some nefarious strategy on the part of Sun Microsystems. Sun does not have a history of executing that way.
According to the cdfreaks website, the PxLinux software simply uses a series of SCSI commands to retrieve statistical data from the drive. The same principle would also apply to ATAPI.
The SCSI command set is a set of published specifications specifically intended for such purposes. It cannot reasonably be the case that Plextor, the drive manufacturer, by following these specifications, expected to restrict the use of SCSI commands for drive control.
It's possible that there is some sort of exclusive software development agreement between Plextor and Shinano Kenshi, but that agreement is not binding on other parties.
It would also be possible, in principle, to sell these drives under condition not to use them except as strictly specified, but again such an agreement would not be binding on other parties.
In no case is it reasonable to seek damages against some third party who independently develops a means to use a manufactured device as intended. An impossible situation would clearly develop for both industry and the public at large if courts were to award such damages.
[I am not a lawyer, and the foregoing does not constitute legal advice.]
In the case of beverage containers, it makes sense to collect and refund a deposit from the consumer, because the choice point occurs at the moment the container becomes empty. The incentive works because it's possible for a consumer to get into a pattern of thinking that the cans have enough value to be worth collecting.
In the case of recyclable packaging, on the other hand, the consumer is not involved in the packaging decision, but is already effective in separating the package from the product. So passing costs to the consumer exerts no incentive. But the retailer is involved, because the system can only work if retailers accept packaging to be recycled.
The challenge for electronics disposal is different again, because it's intimately related to product design. There would be little point in collecting electronics only to produce landfill in a different place. Therefore the incentive has to be applied where it will influence design most directly, and it's a hard problem.
But similar programs have become very successful for building materials. Awards and rewards for "green" designs help architects and builders stand out from the competition, and they have helped to seed an entire secondary industry in recycled materials. It works because there are strong economic advantages to the reuse of certain materials such as clear timbers.
Whether we can achieve a similar effect with electronics components is hard to predict. As long as designs keep becoming obsolete, the value of a component is no more than the value of its raw materials less the cost of extracting them.