Microsoft Corp. also uses XML in its most recent Microsoft Office formats. While it has opened these formats to some extent, Microsoft's XML formats are still proprietary and it has tried to patent some of its XML format technology. Microsoft also charges royalties for accessing its formats.
Yeah, as in "My EULA", the one to which you were forced to agree even before you unwrapped the cellophane.
I've seen a couple of examples of this in other contexts. The choice of language is quite deliberate, albeit painfully convoluted at times. For example, bank machines refer to "my bank card" even though they may simultaneously prompt concerning "your account".
The reason, as I've heard the story told, is that the card actually belongs to the bank, not to you, and the bank wants to keep it that way. So it must be careful not to create any impression of having given the card to you by referring to it as "your" card.
Porting... enforces good software engineering practices.
Yes, or anyway it puts a fork in the road. One direction points toward modularity but has a generally positive effect on design as well. The other direction quickly leads to a tangle of #ifdefs and special cases, tends to keep implementation issues in the foreground, and likewise hides design issues.
In the long run, the software which survives the process of being designed, refactored, and tested for portability is more robust. Some of that effect is due to insights gained along the way, and frankly, a good proportion is due to attrition.
Speaking of reasoning, your subjective dislike of an analogy is not sufficient grounds for inferring that the writer is dishonest, stupid or insane.
For example, it could just be an imperfect analogy. Reasonable people make them occasionally. Or, it could in fact be a very good analogy, and your dislike of it is due to poor judgement on your part. Given your evident tendency to hyperbole, I favor the latter explanation.
He will find himself ahead if he can rent it rather than building it first.
As infrastructure, these things aren't used often enough at most sites to justify the cost of installation, equipment, network QOS, and support.
So if possible, go down the street and use a videoconference facility run by someone else. They're not cheap once the hours really start to add up, but for the cost of a few initial test rides, and zero effort except that of showing up, they are an excellent way to assess the technology firsthand, and not incidentally, to develop a meaningful set of requirements.
I've had the privilege, I guess you could call it, of exposure to a variety of videoconference systems over the past decade, including some very large and elaborate ones that take an entire multimedia crew to manage. In my frank opinion, it's a very elaborate way to watch someone pick their nose.
A quite acceptable alternative is an ordinary voice conference call with headsets and a shared screen. Though it could perhaps use some refinement, the infrastructure is already all there! Until we're using it to the maximum and still find it wanting, it seems hard to justify a more elaborate solution.
However judges should not have any opinion for themselves, but should read the law for what the law says.
If that was all that was required, a court clerk could do it, or it could be automated. The same evidence would always produce the same result. In an artifically simple world, such a purely algorithmic application of law might be possible.
In practice, something different is required. The specific function of a judge is to exercise judgement, that is, to clarify and weigh the evidence presented, and ultimately to render an opinion for the court. That's the legal term for it, an opinion.
When judges are empanelled, the judgement is rendered as a majority opinion. That is, the legal system takes into account the possibility of dissenting opinions. This possibility is a logical consequence of the nature of opinion.
Opinion, while necessarily subjective, thus has both a central and ultimate role in law. Lawyers can and do present legal opinions to their clients, but in so doing are acting on behalf of themselves. Judges must present legal opinions also. The difference is that they do so on behalf of the court.
You make a good point. The auto industry went through a phase of "disposibility" where new models were gratuitously introduced, and existing models made artificially obsolete.
There was nothing fundamentally wrong with the products of the time, and in retrospect we seem to have developed a fondness for them, at least for the better examples. But meanwhile consumers were induced to waste a lot of resources.
Now we're in a different phase where there is a different rationale for wasting resources. We're also running out of resources.
It doesn't pay to get it right the first time.
A manufacturer operating on a parasitic model might say that, might even claim that such a model is inevitable. An informed consumer would not agree. The issue for us as IT professionals is thus to decide whose side are we on?
Well said. Yep, these are the the same phenomena I've been seeing as well, though I have reason to believe that we are starting to return to our senses.
This industry has always been kind of weird, with its emphasis on novelty instead of durability. Think of the trade magazines of ten or twenty years ago in comparison with the technical publications of the time. There was an established cultural division between IT management and IT expertise even then, though it was a stable relationship, and to that degree made some accomodation for professional merit.
More recently we've been passing through an era where time is regarded as an unaffordable luxury. Some of that is the industry, and some can be attributed to broader economics. There is no time to bring competent generalists on board and get them up to speed on a particular techology, and seemingly no grasp of the idea that something important might be invariant beneath the given technological flavor of the week.
The industry as a whole is still fighting over scraps instead of planting for the coming season.
Its characteristic weirdness has been particularly acute in recent years. It's been eating its senior people and its young, but such a strategy is clearly not sustainable.
Most industries eventually settle into some kind of equilibrium based on the stability of supply, demand, and means of production. We've just passed through a phase of radical oversupply of our raw materials. These are the highly useful ideas around computing and networking that were suddenly "discovered" en masse a decade ago, though in fact they had been slowly accumulating over a much longer period. In any case, the effect was very destabilizing, but I want to suggest that it is not characteristic of the industry. Sure, the industry is a bit weird, but not usually as weird as it has been recently.
Where useful ideas are concerned, the normal rate of supply is quite steady. After all, this is what we do as a species, just as plants produce oxygen. Since ideas are our raw materials, we should likewise be able to maintain an IT industry which works well in the steady state, which attracts capital and stimulates markets and all of that good stuff. There is no longer a bubble, but that is not to imply that what remains is a vacuum. There is a natural baseline, and we are returning to it.
Take a look at the NASDAQ, not the quarterly view but the
20-year view. Neglecting the bubble, it's actually a pretty uniform curve. You could almost forecast an industry on it. Fancy that!
Of course, for such an industry to be sustainable rather than parasitic, it has to attend to planting as well as harvesting. In particular, it has to cultivate expertise, because expertise is needed for the supply of useful ideas. And that's where we come in.
It's all mostly a matter of experience. That's why IT budgets will remain flat for a while longer.
Indeed, but allow me to offer another perspective with a longer timeline.
Ten years ago, the Internet and most of its services had formally been in existence for ten years already, and the ARPAnet and related network research for about 20 years before that.
Ten years ago, the market "discovered" all of this work, in large degree because of a particular application which happened to make it more accessible to novices. Although this itself produced no rapid and dramatic advances in the technology, the user base did expand exponentially, while the overall level of expertise among users decayed at a corresponding rate.
From the perspective of someone actually developing the technology, however, the "grappling" is not something recent, but had been taking place already for several decades. Investors, when they arrived on the scene ten years ago, equated the rate of adoption that they could see with a rate of development which they could not see, only to discover their error a few years later.
True innovation in information technology, meanwhile, has probably continued at more or less the same rate as always. Innovation is clocked primarily by the number of people with motivation, expertise, and resources to do the work. These, being constraining factors, is why the rate tends to be linear.
So in investment terms, we can see both the bubble and the ensuing overcorrection as departures from the natural rate of return that can be expected from this industry. The innovation potential of information technology continues to be excellent. However, we should not expect to extract it all at once.
I appreciate that this isn't quite what you were getting at when discussing IT budgets. For that, we have to ask what is an IT budget for, exactly? If it's like most other resources, it will grow at the same rate as the organization. At times when IT innovation creates an opportunity for the organization, the budget tends to increase, but that increase will be temporary.
What the industry really wants, unless we're just in the game to make a quick buck, is to make sure that such opportunities are genuine and then to deliver them effectively. Even if we see a steady flow of innovation, that's the most we can expect.
Finally, the IT budget as a proportion of overall organizational spending is not growing but constant, just like other infrastructure items. Otherwise, it would eventually take over the entire budget. It follows that, in a flat economy, the IT budget will be flat also.
Actually, there is nothing to prevent strong anonymity from working within an authenticated identity framework.
All you need is to provide a service which allows a user to create an identity named "anonymous1234" for example. The user receives a private key and a certificate signed by your certificate authority, both of which are unique to that identity.
The user can now assert that unique but anonymous identity to other services by presenting the certificate. Those services will, of course, be selective about which certificate authorities they accept, so on that basis they can choose whether or not to grant access to the anonymous identities provisioned by your service. Even better, the X.509v3 certificate profile has a "policy" attribute which aids in making this distinction.
Nowhere does the grandparent say that he should personally exploit the stupid people of the world
No, of course not. Nobody has suggested anything as offensive as that. The original comment was merely letting off a bit of steam by suggesting that certain people might be "too stupid to live."
My response was that by the same logic, people who can't spell should be exploited, or if you prefer your terminology, "screwwed." But if you would rather that they be left to die, I think that would be logically acceptable as well.
In case it wasn't blindingly obvious, I'm using a facetious argument, as I did in the previous post, to make my point more playfully.
I am not really suggesting that anyone should be exploited or left to die. I am pointing out that as we are all imperfect, therefore we should not judge others too harshly, lest the same rules be applied to us. I believe there is even some sort of parable to this effect.
the customer was just too stupid to read their contract, if not too stupid to live
You remind me of a guy I knew long ago who ended up in marketing for awhile. He was explaining his ethics to me one evening at the bar, and they went something like, "Well, if the customer can't figure out that we're misleading them, they deserve to be taken. Anyway, if we don't do it, someone else will."
Yeah, dumb people sure are a pain. And I know for a fact that people who can't even spell "various" are mentally defective, plain and simple. Though I don't think they deserve to die. No sir, I think it would be better all around if we were to exploit them like my friend did. Let's start with you.
Main problem is no package manager that I know of is able to cope with such a concept:rolleyes:, so you have to get your hands dirty.
Actually, I've found over the years that the Solaris package manager is very good at relocatability. The same is equally true in theory of RPM, though in practice not as consistently.
When software distributed in one of these package formats doesn't relocate simply and correctly, it's not a failing of the package manager. It's because the developers have overlooked some detail required to make the software relocatable. Typically that's a simplistic installation/removal script embedded inside the package.
Developers, please don't forget that/usr/local is only the nominal installation directory. Many sites are obliged to use other conventions, in particular when filesystems are mounted remotely.
By the way, source distributions which use autoconf tend to be the best behaved of all, in the sense of correctly processing changes to prefix and exec_prefix. That's remarkable, given the size and variety of configuration spaces among source distributions.
Software deployment is part of a more general subject sometimes known as software configuration management.
Since it's impossible to reason about security except with respect to a given configuration, this is a subject which deserves close attention, especially at larger sites where economies of scale are most effective.
Mark Burgess at the University of Oslo developed a mechanism called cfengine as a solution to the configuration management problem. It's multiplatform, mature, stable, comprehensive, secure, and it scales very well. I recommend it.
This is a traditional approach which I've seen done successfully at a number of sites. Often, the remote filesystem contains the definitive software installation, while some alternate, possibly coarser, mechanism is used to maintain the installation locally.
It scales better if you (a) automount the remote filesystems, and (b) use in conjunction with cachefs.
If you notice performance problems, you may elect to deploy a set of workgroup servers, or you may find it worth the effort to switch to something like cfengine and install everything locally.
I expect that Microsoft's "integration" strategy for subverting interoperability will continue to induce pain points in fresh code just as it has done in legacy code.
In a complex design which combines a tolerance for brittleness and nonmodularity with a strong preference for products to fail open rather than closed, that has to be so. It becomes that much harder to meet functional tests, let alone the nonfunctional ones related to security.
But I fear 2 other things now. first, that he will find other people to fill the vacancies, and two, they will not be so dedicated to the truth.
Imagine a whole publication operating to the ethical standards of Maureen O'Hara.
Who would read it? I think it makes a great place to collect all the badness so that it can be more easily ignored.
I remember the words of Arlo Guthrie: "We thought that one big pile [of garbage] was better than two little piles, and rather than bring that one up, we decided to throw ours down."
Better to say that Firefox is designed for compatibility with web standards, which makes it a great investment. Moreover, it's an investment you're not stuck with, since you can substitute any browser that is similarly compatible.
Some browsers are deliberately designed to undermine web standards. If you like the idea of helping yourself and others become locked in to a single vendor, choose one of these.
Strictly speaking, there are some areas where you could deliberately make something work only in Firefox. A couple of posters have mentioned XUL, which meets that test. Using XUL deliberately, you might think that you could make something work only on Firefox. But that is not strictly correct either. Given that the XUL specifications are open, you would not be developing for Firefox, but in fact for any browser that supported XUL.
One area of much greater practical relevance to this discussion is CSS interoperability. Acknowledging that this is a work in progress, and that the CSS standards are subject to interpretation, I think we can look to Firefox as an excellent reference implementation, should disputes arise as to which working system is best suited to clarify the standard.
Many programmers have an arrogance about them that they think all security bugs are perfectly obvious and if only THEY looked at the code they could get rid of them.
Anyone with sufficient programming experience knows that typical implementations errors are perfectly obvious, once they are discovered.
Someone discovering bugs in your code therefore provides an exercise in humility, not arrogance.
It's the search which takes most of the work, and open source provides the means by which any interested party can participate. This, remember, is what got Richard Stallman interested in free software in the first place. His group had found a bug, but they weren't allowed to fix it.
You can't have your cake and eat it, too. First you complain that Microsoft has an unfair advantage with bundling their apps. You want them to be forced to unbundle their apps. Then after they unbundle their apps you complain that Windows doesn't come bundled with any apps.
Your comparison is flawed because you're treating characteristically different things as if they were equivalent:
When a supplier is willing to sell several items packaged together at a significant price but does not make them available individually at any price, that is called bundling. The consumer has no choice but to accept or reject the entire bundle.
When a supplier is willing to sell a package but also the individual items, that is called packaging. The consumer has the option to purchase some items or the entire package, likely at reduced cost.
When a supplier is willing to give away several items packaged together, that is called distribution, in this context at least. Since cost is not an issue, there is no tradeoff for the consumer to make.
People might therefore reasonably resent that Microsoft bundles software, while also noting that Windows is not distributed with much application software. The two positions are not at all contradictory.
I agree completely with your comments, based on about 50 years of travelling over much of the world.
I can't recall a single travel situation where I missed having a cell phone. Like you, I therefore fail to find merit in the argument that having a cell phone will make any difference.
Perhaps it might, but then perhaps just as likely I'll find myself like those poor guys a couple of years ago, up some logging road in Alaska, who had the cell all right, but had no idea where they were. And they died like that.
By the way, a recent consumer poll reported that cell phones had become both the most loved and the most hated artifacts in common use. It only makes sense, therefore, to exercise some discretion. Marketing people don't like that, of course, but this is about your choice, not theirs.
At least it makes sense not to immerse removable media. But what's wrong with immersing the disk drives? The drive enclosure is hermetically sealed, no?
Turns out that I still had an account on a system at Stanford where I was faculty and I transferred some files via scp to my machine at my current university.
...
Remember, if you log onto your machine from another, ask yourself "What do I know about the integrity of this machine?". I really assumed that my stanford account was pretty secure and so I didn't even think about logging from that machine to my current one.
The key principle is that security is not inherently symmetrical between any two systems. The communication itself between those systems may be secure, but that is independent of the security of each system.
Thus, a remote login from Uppsala to Stanford is not the same as a remote login from Stanford to Uppsala. It's not a deficiency of the remote protocol, but a consequence of different organizations being responsible for the two systems.
This same observation also explains how to manage digital certificates for best security. I've been involved with a number of institutions which generate X.509 certificates for use by their members. The typical implementation is for the institution to provide a web page where the user supplies identification values and a certificate passphrase, from which the system generates a signed certificate and mails it or otherwise presents it to the user.
Such an implementation, while convenient, throws away the two main factors which makes certificates more secure than bare passwords, namely the privacy of your private key and the privacy of its passphrase. The correct way to get a signed certificate is to (a) generate the certificate request in your own secure environment, (b) keep the resulting private key and its passphrase in that environment only, (c) send the public key off as the request to be signed.
Somehow I don't see that as source of embarassment. When was the last time Buddhist fundamentalists were in the news?
Compassion is a quality which Buddhists hold in high regard, and rightly so. It can be a powerful way to step out of reactive thinking and regain an appreciation for all creatures great and small.
Doctrinally, both Pamela Jones and Maureen O'Hara are equally Buddhas. PJ seems to be a conscientious, grateful, articulate Buddha. Maureen is a rather vicious Buddha. Both, I'm sure, have times of joy and times of suffering, and they act out of those feelings as best they know how.
I knew an elderly dog who was in chronic pain in his last years. One day a small girl got too near him, and he gave her a very nasty bite in the forearm. She carries the scars, and she is easily intimidated by dogs.
I think we can have compassion both for the girl and for the dog. But, in compassion for others, at a certain point we also have to do something about the dog.
Slashdot Mirror
As this article points out:
I've seen a couple of examples of this in other contexts. The choice of language is quite deliberate, albeit painfully convoluted at times. For example, bank machines refer to "my bank card" even though they may simultaneously prompt concerning "your account".
The reason, as I've heard the story told, is that the card actually belongs to the bank, not to you, and the bank wants to keep it that way. So it must be careful not to create any impression of having given the card to you by referring to it as "your" card.
Yes, or anyway it puts a fork in the road. One direction points toward modularity but has a generally positive effect on design as well. The other direction quickly leads to a tangle of #ifdef s and special cases, tends to keep implementation issues in the foreground, and likewise hides design issues.
In the long run, the software which survives the process of being designed, refactored, and tested for portability is more robust. Some of that effect is due to insights gained along the way, and frankly, a good proportion is due to attrition.
You might if 90% of the gas stations were designed not to work for your car, but only for these ugly ones.
For example, it could just be an imperfect analogy. Reasonable people make them occasionally. Or, it could in fact be a very good analogy, and your dislike of it is due to poor judgement on your part. Given your evident tendency to hyperbole, I favor the latter explanation.
As infrastructure, these things aren't used often enough at most sites to justify the cost of installation, equipment, network QOS, and support.
So if possible, go down the street and use a videoconference facility run by someone else. They're not cheap once the hours really start to add up, but for the cost of a few initial test rides, and zero effort except that of showing up, they are an excellent way to assess the technology firsthand, and not incidentally, to develop a meaningful set of requirements.
I've had the privilege, I guess you could call it, of exposure to a variety of videoconference systems over the past decade, including some very large and elaborate ones that take an entire multimedia crew to manage. In my frank opinion, it's a very elaborate way to watch someone pick their nose.
A quite acceptable alternative is an ordinary voice conference call with headsets and a shared screen. Though it could perhaps use some refinement, the infrastructure is already all there! Until we're using it to the maximum and still find it wanting, it seems hard to justify a more elaborate solution.
If that was all that was required, a court clerk could do it, or it could be automated. The same evidence would always produce the same result. In an artifically simple world, such a purely algorithmic application of law might be possible.
In practice, something different is required. The specific function of a judge is to exercise judgement, that is, to clarify and weigh the evidence presented, and ultimately to render an opinion for the court. That's the legal term for it, an opinion.
When judges are empanelled, the judgement is rendered as a majority opinion. That is, the legal system takes into account the possibility of dissenting opinions. This possibility is a logical consequence of the nature of opinion.
Opinion, while necessarily subjective, thus has both a central and ultimate role in law. Lawyers can and do present legal opinions to their clients, but in so doing are acting on behalf of themselves. Judges must present legal opinions also. The difference is that they do so on behalf of the court.
There was nothing fundamentally wrong with the products of the time, and in retrospect we seem to have developed a fondness for them, at least for the better examples. But meanwhile consumers were induced to waste a lot of resources.
Now we're in a different phase where there is a different rationale for wasting resources. We're also running out of resources.
It doesn't pay to get it right the first time.
A manufacturer operating on a parasitic model might say that, might even claim that such a model is inevitable. An informed consumer would not agree. The issue for us as IT professionals is thus to decide whose side are we on?
This industry has always been kind of weird, with its emphasis on novelty instead of durability. Think of the trade magazines of ten or twenty years ago in comparison with the technical publications of the time. There was an established cultural division between IT management and IT expertise even then, though it was a stable relationship, and to that degree made some accomodation for professional merit.
More recently we've been passing through an era where time is regarded as an unaffordable luxury. Some of that is the industry, and some can be attributed to broader economics. There is no time to bring competent generalists on board and get them up to speed on a particular techology, and seemingly no grasp of the idea that something important might be invariant beneath the given technological flavor of the week.
The industry as a whole is still fighting over scraps instead of planting for the coming season. Its characteristic weirdness has been particularly acute in recent years. It's been eating its senior people and its young, but such a strategy is clearly not sustainable.
Most industries eventually settle into some kind of equilibrium based on the stability of supply, demand, and means of production. We've just passed through a phase of radical oversupply of our raw materials. These are the highly useful ideas around computing and networking that were suddenly "discovered" en masse a decade ago, though in fact they had been slowly accumulating over a much longer period. In any case, the effect was very destabilizing, but I want to suggest that it is not characteristic of the industry. Sure, the industry is a bit weird, but not usually as weird as it has been recently.
Where useful ideas are concerned, the normal rate of supply is quite steady. After all, this is what we do as a species, just as plants produce oxygen. Since ideas are our raw materials, we should likewise be able to maintain an IT industry which works well in the steady state, which attracts capital and stimulates markets and all of that good stuff. There is no longer a bubble, but that is not to imply that what remains is a vacuum. There is a natural baseline, and we are returning to it.
Take a look at the NASDAQ, not the quarterly view but the 20-year view. Neglecting the bubble, it's actually a pretty uniform curve. You could almost forecast an industry on it. Fancy that!
Of course, for such an industry to be sustainable rather than parasitic, it has to attend to planting as well as harvesting. In particular, it has to cultivate expertise, because expertise is needed for the supply of useful ideas. And that's where we come in.
Indeed, but allow me to offer another perspective with a longer timeline.
Ten years ago, the Internet and most of its services had formally been in existence for ten years already, and the ARPAnet and related network research for about 20 years before that.
Ten years ago, the market "discovered" all of this work, in large degree because of a particular application which happened to make it more accessible to novices. Although this itself produced no rapid and dramatic advances in the technology, the user base did expand exponentially, while the overall level of expertise among users decayed at a corresponding rate.
From the perspective of someone actually developing the technology, however, the "grappling" is not something recent, but had been taking place already for several decades. Investors, when they arrived on the scene ten years ago, equated the rate of adoption that they could see with a rate of development which they could not see, only to discover their error a few years later.
True innovation in information technology, meanwhile, has probably continued at more or less the same rate as always. Innovation is clocked primarily by the number of people with motivation, expertise, and resources to do the work. These, being constraining factors, is why the rate tends to be linear.
So in investment terms, we can see both the bubble and the ensuing overcorrection as departures from the natural rate of return that can be expected from this industry. The innovation potential of information technology continues to be excellent. However, we should not expect to extract it all at once.
I appreciate that this isn't quite what you were getting at when discussing IT budgets. For that, we have to ask what is an IT budget for, exactly? If it's like most other resources, it will grow at the same rate as the organization. At times when IT innovation creates an opportunity for the organization, the budget tends to increase, but that increase will be temporary.
What the industry really wants, unless we're just in the game to make a quick buck, is to make sure that such opportunities are genuine and then to deliver them effectively. Even if we see a steady flow of innovation, that's the most we can expect.
Finally, the IT budget as a proportion of overall organizational spending is not growing but constant, just like other infrastructure items. Otherwise, it would eventually take over the entire budget. It follows that, in a flat economy, the IT budget will be flat also.
All you need is to provide a service which allows a user to create an identity named "anonymous1234" for example. The user receives a private key and a certificate signed by your certificate authority, both of which are unique to that identity.
The user can now assert that unique but anonymous identity to other services by presenting the certificate. Those services will, of course, be selective about which certificate authorities they accept, so on that basis they can choose whether or not to grant access to the anonymous identities provisioned by your service. Even better, the X.509v3 certificate profile has a "policy" attribute which aids in making this distinction.
No, of course not. Nobody has suggested anything as offensive as that. The original comment was merely letting off a bit of steam by suggesting that certain people might be "too stupid to live."
My response was that by the same logic, people who can't spell should be exploited, or if you prefer your terminology, "screwwed." But if you would rather that they be left to die, I think that would be logically acceptable as well.
In case it wasn't blindingly obvious, I'm using a facetious argument, as I did in the previous post, to make my point more playfully. I am not really suggesting that anyone should be exploited or left to die. I am pointing out that as we are all imperfect, therefore we should not judge others too harshly, lest the same rules be applied to us. I believe there is even some sort of parable to this effect.
You remind me of a guy I knew long ago who ended up in marketing for awhile. He was explaining his ethics to me one evening at the bar, and they went something like, "Well, if the customer can't figure out that we're misleading them, they deserve to be taken. Anyway, if we don't do it, someone else will."
Yeah, dumb people sure are a pain. And I know for a fact that people who can't even spell "various" are mentally defective, plain and simple. Though I don't think they deserve to die. No sir, I think it would be better all around if we were to exploit them like my friend did. Let's start with you.
Actually, I've found over the years that the Solaris package manager is very good at relocatability. The same is equally true in theory of RPM, though in practice not as consistently.
When software distributed in one of these package formats doesn't relocate simply and correctly, it's not a failing of the package manager. It's because the developers have overlooked some detail required to make the software relocatable. Typically that's a simplistic installation/removal script embedded inside the package.
Developers, please don't forget that /usr/local is only the nominal installation directory. Many sites are obliged to use other conventions, in particular when filesystems are mounted remotely.
By the way, source distributions which use autoconf tend to be the best behaved of all, in the sense of correctly processing changes to prefix and exec_prefix. That's remarkable, given the size and variety of configuration spaces among source distributions.
Since it's impossible to reason about security except with respect to a given configuration, this is a subject which deserves close attention, especially at larger sites where economies of scale are most effective.
Mark Burgess at the University of Oslo developed a mechanism called cfengine as a solution to the configuration management problem. It's multiplatform, mature, stable, comprehensive, secure, and it scales very well. I recommend it.
It scales better if you (a) automount the remote filesystems, and (b) use in conjunction with cachefs.
If you notice performance problems, you may elect to deploy a set of workgroup servers, or you may find it worth the effort to switch to something like cfengine and install everything locally.
I expect that Microsoft's "integration" strategy for subverting interoperability will continue to induce pain points in fresh code just as it has done in legacy code.
In a complex design which combines a tolerance for brittleness and nonmodularity with a strong preference for products to fail open rather than closed, that has to be so. It becomes that much harder to meet functional tests, let alone the nonfunctional ones related to security.
Imagine a whole publication operating to the ethical standards of Maureen O'Hara. Who would read it? I think it makes a great place to collect all the badness so that it can be more easily ignored.
I remember the words of Arlo Guthrie: "We thought that one big pile [of garbage] was better than two little piles, and rather than bring that one up, we decided to throw ours down."
Better to say that Firefox is designed for compatibility with web standards, which makes it a great investment. Moreover, it's an investment you're not stuck with, since you can substitute any browser that is similarly compatible.
Some browsers are deliberately designed to undermine web standards. If you like the idea of helping yourself and others become locked in to a single vendor, choose one of these.
Strictly speaking, there are some areas where you could deliberately make something work only in Firefox. A couple of posters have mentioned XUL, which meets that test. Using XUL deliberately, you might think that you could make something work only on Firefox. But that is not strictly correct either. Given that the XUL specifications are open, you would not be developing for Firefox, but in fact for any browser that supported XUL.
One area of much greater practical relevance to this discussion is CSS interoperability. Acknowledging that this is a work in progress, and that the CSS standards are subject to interpretation, I think we can look to Firefox as an excellent reference implementation, should disputes arise as to which working system is best suited to clarify the standard.
Anyone with sufficient programming experience knows that typical implementations errors are perfectly obvious, once they are discovered. Someone discovering bugs in your code therefore provides an exercise in humility, not arrogance.
It's the search which takes most of the work, and open source provides the means by which any interested party can participate. This, remember, is what got Richard Stallman interested in free software in the first place. His group had found a bug, but they weren't allowed to fix it.
Your comparison is flawed because you're treating characteristically different things as if they were equivalent:
-
When a supplier is willing to sell several items packaged together at a significant price but does not make them available individually at any price, that is called bundling. The consumer has no choice but to accept or reject the entire bundle.
-
When a supplier is willing to sell a package but also the individual items, that is called packaging. The consumer has the option to purchase some items or the entire package, likely at reduced cost.
-
When a supplier is willing to give away several items packaged together, that is called distribution, in this context at least. Since cost is not an issue, there is no tradeoff for the consumer to make.
People might therefore reasonably resent that Microsoft bundles software, while also noting that Windows is not distributed with much application software. The two positions are not at all contradictory.I can't recall a single travel situation where I missed having a cell phone. Like you, I therefore fail to find merit in the argument that having a cell phone will make any difference.
Perhaps it might, but then perhaps just as likely I'll find myself like those poor guys a couple of years ago, up some logging road in Alaska, who had the cell all right, but had no idea where they were. And they died like that.
By the way, a recent consumer poll reported that cell phones had become both the most loved and the most hated artifacts in common use. It only makes sense, therefore, to exercise some discretion. Marketing people don't like that, of course, but this is about your choice, not theirs.
At least it makes sense not to immerse removable media. But what's wrong with immersing the disk drives? The drive enclosure is hermetically sealed, no?
Remember, if you log onto your machine from another, ask yourself "What do I know about the integrity of this machine?". I really assumed that my stanford account was pretty secure and so I didn't even think about logging from that machine to my current one.
The key principle is that security is not inherently symmetrical between any two systems. The communication itself between those systems may be secure, but that is independent of the security of each system.
Thus, a remote login from Uppsala to Stanford is not the same as a remote login from Stanford to Uppsala. It's not a deficiency of the remote protocol, but a consequence of different organizations being responsible for the two systems.
This same observation also explains how to manage digital certificates for best security. I've been involved with a number of institutions which generate X.509 certificates for use by their members. The typical implementation is for the institution to provide a web page where the user supplies identification values and a certificate passphrase, from which the system generates a signed certificate and mails it or otherwise presents it to the user.
Such an implementation, while convenient, throws away the two main factors which makes certificates more secure than bare passwords, namely the privacy of your private key and the privacy of its passphrase. The correct way to get a signed certificate is to (a) generate the certificate request in your own secure environment, (b) keep the resulting private key and its passphrase in that environment only, (c) send the public key off as the request to be signed.
Somehow I don't see that as source of embarassment. When was the last time Buddhist fundamentalists were in the news?
Compassion is a quality which Buddhists hold in high regard, and rightly so. It can be a powerful way to step out of reactive thinking and regain an appreciation for all creatures great and small.
Doctrinally, both Pamela Jones and Maureen O'Hara are equally Buddhas. PJ seems to be a conscientious, grateful, articulate Buddha. Maureen is a rather vicious Buddha. Both, I'm sure, have times of joy and times of suffering, and they act out of those feelings as best they know how.
I knew an elderly dog who was in chronic pain in his last years. One day a small girl got too near him, and he gave her a very nasty bite in the forearm. She carries the scars, and she is easily intimidated by dogs.
I think we can have compassion both for the girl and for the dog. But, in compassion for others, at a certain point we also have to do something about the dog.