I would also note that Islamic Fundamentalism stoked by our dependence on oil has already killed more US citizens than the nuclear power industry.
Also keep in mind that Islamic Fundamentalists see a war of culture. Western culture is pervasive. It slowly enters existing cultures and begins to supplant it. This is a definate threat to Fundamentalists who's very existance and meaning is defined by traditional culture. Fundamentalists would still find reasons to attack Western targets without the geopolitics involved in oil. The only difference is that they may find it harder to fund their campaign.
It's a shame the US didn't just hold on to Kuwait. All that mobilization and expense. All those rich oil fields. And now the Kuwaitis are running their own country again. What a shame. You'd think a country that's just out to steal oil would do a better job at it when the situation presented itself.
Even assuming that they became unhinged from playing too much CS, doesn't mean that we should ban it. People did go crazy and kill people before computer games existed...
Yes. But we can't go around baning God, can we?
Especially when God has personally told us about evils like Counter Strike and Dungeons and Dragons. Fantasy is all evil, you know. I've got some quotes taken out of context from some scripture based on ancient Middle Eastern mythology to prove it.
You'd have to be picky about your choice in military organization. Many of the world's military forces spend quite a bit of time not killing people. It makes for a fairly poor outlet if your "talent" is lacking a mental block to killing. And, in fact, if this particular talent stems from poor impulse control, you'll likely find it very difficult to function in a military organization.
Granted - there are exceptions. But those exceptions tend to involve military forces that do a lot of dying if they bump up against anybody other than another incompetent force or civilians. But then, the same flippant response that calls out "the military" might also comment that getting these people killed is the whole point.
Afterall, in most cases the user has "agreed" to allow these programs to run by installing something without fully reading the terms of service.
With this assumption in place, fine... and now the user has decided to identify all software of that class that they "agreed" to install and decided to uninstall it (of course, you and I know there is plenty of spyware that assumes permission if you use the right kind of web browser).
But you do bring up an interesting issue about classification. Why does common antivirus software have definitions for ElfBowling (a game) and BO2K (remote administration)? And why don't they have definitions for spyware? And while I can understand how usefull it is to have all these definitions... exactly what does any of this have to do with a virus?
That may be the reason why this group caved... not that money changed hands, but the threat of a lawsuit was waived around.
Of course, the real issue is companies who wish to avoid the "spyware" moniker... even if we know better.
The main problem is that NASA has all their eggs in one basket. Where is the funding for development of the next generation shuttle?
I'm sure NASA is asking the exact same question. Where exactly IS their funding to develop next generation craft? Note the cancelation of even the X-38 project just two years before it completed flight testing.
Also, keep in mind NASA doesn't get a pile of money to spend on anything it wants. It does get a sizeable budget (a fraction of the value of its budget during Apollo era). But a large chunk of that budget is tied directly to specific programs - abandon the program and lose the ear-marked funds.
What complete rubbish: the reverse is actually the case. Which is more secure *and* easier to use: one that allows you to directly access and manipulate the fields in a database or one that is task driven and guides you in performing that task by prompting you to enter the information required?
Which is easier to use? The database interface that you just sit down and begin entering the information required? Or the database that first requires you to authenticate before you can begin entering data (and then what happens if you forget your password or lose your smartcard / keyfob)?
What you described is simply a better interface. It does nothing to protect the data involved. Without basic authentication, authorization, and access controls you do nothing to protect the integrity or availability of the data. At best, it might assist in data accuracy.
The holy grail in Infosec involves minimizing the impact of the inverse relationship. This is certainly possible (enter 2-factor authentication mechanisms such as tokens and smart cards). And there are certainly scenarios where one can move to a more secure interface AND improve ease-of-use over a legacy insecure and hard-to-use interface. But that relationship tends to remain intact, if minimal.
The adversarial relationship is natural. IT tends to involve an inverse relationship between functionality and security. The easier something is to use, the less secure it is likely to be. And likewise, attempting to put in security restraints will tend to impact ease of use. This applies to people too.
Users' primary interest is having widgets to do their work. Infosec's interest is about protecting existing widgets. The adversarial relationship tends to come in place when deploying new widgets, or making widgets easier to use and access, impacts the security of all widgets (and information in general) already deployed.
It might be interesting to note that this exists within IT too. IT departments tend to be held responsible for deploying widgets. And since widgets are easier to deploy in less-secure configurations, the natural temptation is to cut corners on security for the sake of easing deployment. This conflicts with Infosec who's goal is to keep widgets secure, not necessarily to ensure more widgets are deployed.
The challenge is to recognize this inverse relationship and take advantage of it. Use the natural inverse and work it in to your organization as a check-and-balance.
First and foremost, an organization should have their security policies well documented and those policies should be applicable to most common access requirements without interpretation. When Infosec notes something is dangerous, it shouldn't be a judgment call - it should be based on documented policy.
Secondly, Infosec's role is not to be a road block. It's there to help conform (and modify) existing policy. If a policy is unworkable, fix it. But more likely the policy is functional and it will simply take some working with the end user / developer to modify the system design to properly conform with that policy.
Finally, there will be times when the policy is valid and the project simply can't be modified. This is where Infosec helps define to level of risk. Meanwhile, project developers define a business case for their architecture. Both cases are presented to higher management who ultimately weight risk against business case. And if the business case outweighs the risk, that risk is well documented.
This is an excellent document. It should go a long way towards easing concerns of IT managers considering FOSS architecture. The summery:
The use of FOSS by financial institutions does not pose risks that are fundamentally different from those presented by the use of proprietary or self-developed software.However, FOSS adoption and usage necessitates some distinctive risk management practices with which institutions must be familiar.
The interesting thing is that the risks outlined are essentially existing risks handled with a slightly different understanding for FOSS. For example, they outline forking as a risk:
Forking is of particular concern in the FOSS development process.A fork occurs when the development community splits over the path of development of a given application.In the worst-case scenario, development of forked FOSS may be halted, or the technical direction may become so altered that it no longer meets the institution's needs.
Institutions should mitigate this risk by ensuring that adequate support is available for the current FOSS software either in-house, through vendors, or other outside sources.
This should be familiar territory for anybody who's had their vendor End Of Life a product. The same general strategy applies to both proprietary software as FOSS. The only difference is that FOSS may offer more choices (there may be enough interest in the original fork to continue or if it is that important, you can fund continuation of the project yourself).
It might also be worth noting that some of these "unique" practices have to do with the ability to modify source code. That is certainly unique to most organizations used to working with proprietary software. However, organizations that do their own in-house development will have to face the same issues of copyright, patent infringement, etc. Of course, the issue of copyright and patent infringement has also come to light numerous times in the proprietary software world too. Perhapse nobody is imune to this after all.
Back on topic... TCO. From the document:
Institutions evaluating the total cost of FOSS ownership should include both direct and indirect costs.Direct costs generally include hardware, software licensing, and annual maintenance.One of the features attracting institutions to FOSS is its complimentary or low cost for licensing and maintenance.However, the indirect costs of FOSS may be higher than those associated with proprietary software if existing staff requires more training than would otherwise be necessary with a proprietary product.In addition, change management costs may be higher in a FOSS environment if the institution implements products lacking third-party vendor support.The institution generally will bear more responsibility and spend more resources identifying, selecting, analyzing, and installing upgrades and patches.Depending on the FOSS selected, other indirect costs may appear, such as code reviews, documentation, and contingency planning.
And again, there's nothing really surprising here. The key is that FOSS is not a magic bullet - you still have to work to deploy it. But anybody dealing with IT will find that much the same work will be done no matter where the code comes from.
It is interesting to note that nowhere does the FDIC say that FOSS will have a higher TCO. They outline a series of concerns that MAY drive TCO higher than the licensing might imply. But if an organization is carefully with their deployment strategy, they may find themselves able to deploy FOSS without driving up TCO and maintain that initial savings. Heck, they may even find that the available tools and strategies to handle some of these issues (change management, patch analysis / management, etc.) will help them manage TCO very well.
What a facinating idea. There could be a rather nasty suprise waiting for the camp that wishes to legally define "intellectual property". Once ideas become legally coded as a form of property, maybe even to the strongest sense of the law - real estate, then there's a whole slew of additional laws that govern the ownership of that property. It would represent quite a boon for government on available tax base alone.
And this stuff about legacy? It brings to mind ancestral estates. How many old bloodline families have had to turn over castles, manors, ranches, and other large estate items as that family finds itself no longer with the means to maintain the tax base the property represents? Legacy, indeed.
I imagine at least one of the things that would worry them is a balkanization of sender id. Where, over a long period of time, say a decade, they find themselves spending more resources trying to hit a moving target of an evolving sender id than they would have on a brute force method of dumping spam.
If the protocol is open and widely adopted, it will be hard for it to move around too quickly. Oddly enough, changing standards is a well-known and documented Microsoft business practice. Strange that you would imply Open Source involvement would bring this about. If anything, Open Source projects tend to favor open protocols which tend to be easy to implement if not fairly slow-moving and stable.
Or that if someone does come up with a novel idea that should be widely adopted, they can insure that they'll be able to participate on a level playing field with everyone else, safe from extortion by lawsuit and without having to share more of their toys than they might otherwise want to.
A "level playing field" is where nobody has the advantage. Everyone plays by the same rules (whether some are more successful than others is an entirely different issue). What you've described is a playing field where someone gets to alter the rules to their advantage.
If he licenses it under the GPL they'll at least have to write it as a module separate from the rest of their toys, and, at least by my understanding, they'd still have to give that improvement away. An improvement a competitor might use against them.
Who said anything about the GPL? And who even mentioned code? This isn't about licensing software. This an issue with the fundamental protocol involved. The common protocols today are truly open where anybody can adopt them. A none-too-subtle reason for their success and widespread adoption. If Microsoft wants their ideas to be as successful, their proposed protocol must also be just as open and available. Even if that means a competitor implements said protocol in a better product than theirs.
Whatever one's ideology might be, certainly it's something for them to look out for. I think it's pretty hard to blame them for preaching at least a little segregation. Ultimately, this is a business decision which could have a world wide impact for decades. Can you really fault their caution?
The scope of this issue is bigger than Microsoft. Sure, there are good business cases for trying to keep a handle on a piece of technology. But there are times that this can't happen. This is one such time.
SMTP is an open protocol, available to anyone who wishes to implement it - no cost, no restrictions. If Microsoft wishes to introduce a technology that will work in that environment and enjoy the same level of success, it will have to have the same level of openness and availability. Otherwise, their attempts will most likely fail.
The question is exactly what Microsoft's business case is. Are they trying to own a protocol or cut the costs of one of the most fundamental protocols used in IT today - by themselves as well as the rest of the world? If it is the former, then sure... there's no fault in what they're trying to do. But at the same time, I wouldn't be willing to listen to them. But if the case is the later, then there is certainly fault in their methodology.
Of course, Microsoft doesn't have a history of hiring assassins and experts in mass murder. They just now have awoken to the possibilities of participating in politics - though have no history of interest in actually running for office.
They do, however, have a history of "embrace and extend", FUD, user lock-in, and other such business tactics. Heck - there are even publicly-available memos on some of these subjects.
It would seem that there IS more support for the parent than your comment. Unless, of course, you're getting ready to break the most stunning "Halloween Memo" to date?
And so Microsoft has a golden oportunity. They can help reduce costly spam incoming to their networks (corporate, hotmail, msn, etc.). They can help reduce one of the most popular vectors for malware that has a negative effect on adoption of their software. AND they can pull off a major warm-and-fuzzy PR move to counter the expanding cadre of IT types who have come to distrust, if not lothe them.
In that respect, MacOS, Windows, and Linux (with the appropriate window manager) are all the same.
Sometimes subtle things make a big difference. On my WinXP box at work, I've had to install various 3rd party apps to try and duplicate common Linux desktop behaviors (virtual desktops, rolling windows, sloppy focus, etc.). I was kind of suprised at how annoyed I was when I didn't have those features.
I don't hold out much hope for the next generation of geeks, I must say.
That's not the next generation of geeks. That's the usual consumer who's finally adopting technology that had been the cutting edge realm of geeks past.
I mean, will we see a similar case like "The marketing department never understands what we IT is really doing!"?
It doesn't matter. If the OSDDP projects don't produce usefully material, it'll sit unused. If it does prove to be usefully, it'll become widely adopted. Just like OSS, OSDDP material will live or die on merit - not corporate politics.
From what I know of the open source world, documentation is one area that people make money on the free product.
A couple points.
First, I some of O'Reilly's tactics quite intersting. For example, they sell a book on Subversion called Version Control with Subversion. The very same work is available online. The book is licensed under Creative Commons. This hasn't been the first work done in this manner by O'Reilly. And that would imply that there is something else to this business than hording documentation.
Secondly, even proprietary software produces a considerable market for technical books. Even for software that comes with complete, professionally writen manuals, etc. (sometimes even some degree of support).
Finally, documentation isn't new to Open Source. There are actually projects with some very good documentation (as rare as that may be). Yet publishing houses have began publishing an increasing number of technical books covering these as well as other Open Source projects.
I doubt better documentation is going to destroy the technical book business model for Open Source software.
For all forms of knowledge there are gatekeepers. Even your beloved Internet has a gatekeeper know as an ISP.
My ISP is being a poor gatekeeper then. I can change service to another ISP. I can go to my local internet cafe. I can go the the library. I can wait until I go to work. In all cases, I can access the same information without my ISP either being aware of or having any say in that access.
Yes, lets hold up as a good example of what we'll get, The Internet. OK so you've just read something on the web. So how do you know it is correct?
Something gets printed in a Journal. How do you know it is correct? The same process of peer review and established trust can be done with the web. And, in fact, has been done for quite some time.
At the same time, I'm also well aware that it's another example of "the best justice money can buy", and in that sense I'm appalled.
I also find myself at odds. On one hand, due to the nature of law, I would wish that all things were equal and the merits of the case were the sole consideration. But at the same time I am compelled to feel some admiration for one who excels at one's profession. Especially when that profession's mix of knowledge, presentation, and application of legal code present distinct similarities to hackers everywhere. I suppose the problem is when skill obscures merit.
Having said all that... don't cry for SCO. They're not the underfunded little guy. They have actually put considerable funds towards their legal team. And while IBM's legal team is held in high esteem, SCO has supposedly secured some considerable legal talent themselves.
Now if all that talent could produce an inkling of merit.
There are two design flaws right there. First, you shouldn't have to X-ray it to determine orientation, second that the drawings are incorrect.
I agree on that point. And I pointed it out myself. Such components should be keyed so they can only be installed one way.
So everything was assembled according to the techinical drawings.
Absolutely not. If the system was assembled according to the technical drawings, they would not have been installed in reverse. The mistake wasn't a design that failed to work as expected. The mistake was an implementation that didn't follow the system design.
From the article:
Similar hardware has also been installed on NASA's Stardust probe, which has already collected fragments of a comet and is headed back to Earth with them. Engineers have studied design drawings of Stardust, which has a parachute re-entry system using the same switches as Genesis.
Investigators into the Genesis crash believe that Stardust is assembled correctly -- if the documentation is accurate. "While the switches are the same, the installation... is quite different," a NASA manager told journalists.
Slashdot Mirror
Also keep in mind that Islamic Fundamentalists see a war of culture. Western culture is pervasive. It slowly enters existing cultures and begins to supplant it. This is a definate threat to Fundamentalists who's very existance and meaning is defined by traditional culture. Fundamentalists would still find reasons to attack Western targets without the geopolitics involved in oil. The only difference is that they may find it harder to fund their campaign.
It's a shame the US didn't just hold on to Kuwait. All that mobilization and expense. All those rich oil fields. And now the Kuwaitis are running their own country again. What a shame. You'd think a country that's just out to steal oil would do a better job at it when the situation presented itself.
Yes. But we can't go around baning God, can we?
Especially when God has personally told us about evils like Counter Strike and Dungeons and Dragons. Fantasy is all evil, you know. I've got some quotes taken out of context from some scripture based on ancient Middle Eastern mythology to prove it.
Wait. Did I just fork to a tangent?
You'd have to be picky about your choice in military organization. Many of the world's military forces spend quite a bit of time not killing people. It makes for a fairly poor outlet if your "talent" is lacking a mental block to killing. And, in fact, if this particular talent stems from poor impulse control, you'll likely find it very difficult to function in a military organization.
Granted - there are exceptions. But those exceptions tend to involve military forces that do a lot of dying if they bump up against anybody other than another incompetent force or civilians. But then, the same flippant response that calls out "the military" might also comment that getting these people killed is the whole point.
With this assumption in place, fine... and now the user has decided to identify all software of that class that they "agreed" to install and decided to uninstall it (of course, you and I know there is plenty of spyware that assumes permission if you use the right kind of web browser).
But you do bring up an interesting issue about classification. Why does common antivirus software have definitions for ElfBowling (a game) and BO2K (remote administration)? And why don't they have definitions for spyware? And while I can understand how usefull it is to have all these definitions... exactly what does any of this have to do with a virus?
Of course, the real issue is companies who wish to avoid the "spyware" moniker... even if we know better.
With the exception that the X-15 was able to do more and broke far more new ground.
I'm sure NASA is asking the exact same question. Where exactly IS their funding to develop next generation craft? Note the cancelation of even the X-38 project just two years before it completed flight testing.
Also, keep in mind NASA doesn't get a pile of money to spend on anything it wants. It does get a sizeable budget (a fraction of the value of its budget during Apollo era). But a large chunk of that budget is tied directly to specific programs - abandon the program and lose the ear-marked funds.
... And whats rusting cars got to do with a pack of new kids, anyway?
Which is easier to use? The database interface that you just sit down and begin entering the information required? Or the database that first requires you to authenticate before you can begin entering data (and then what happens if you forget your password or lose your smartcard / keyfob)?
What you described is simply a better interface. It does nothing to protect the data involved. Without basic authentication, authorization, and access controls you do nothing to protect the integrity or availability of the data. At best, it might assist in data accuracy.
The holy grail in Infosec involves minimizing the impact of the inverse relationship. This is certainly possible (enter 2-factor authentication mechanisms such as tokens and smart cards). And there are certainly scenarios where one can move to a more secure interface AND improve ease-of-use over a legacy insecure and hard-to-use interface. But that relationship tends to remain intact, if minimal.
The adversarial relationship is natural. IT tends to involve an inverse relationship between functionality and security. The easier something is to use, the less secure it is likely to be. And likewise, attempting to put in security restraints will tend to impact ease of use. This applies to people too.
Users' primary interest is having widgets to do their work. Infosec's interest is about protecting existing widgets. The adversarial relationship tends to come in place when deploying new widgets, or making widgets easier to use and access, impacts the security of all widgets (and information in general) already deployed.
It might be interesting to note that this exists within IT too. IT departments tend to be held responsible for deploying widgets. And since widgets are easier to deploy in less-secure configurations, the natural temptation is to cut corners on security for the sake of easing deployment. This conflicts with Infosec who's goal is to keep widgets secure, not necessarily to ensure more widgets are deployed.
The challenge is to recognize this inverse relationship and take advantage of it. Use the natural inverse and work it in to your organization as a check-and-balance.
First and foremost, an organization should have their security policies well documented and those policies should be applicable to most common access requirements without interpretation. When Infosec notes something is dangerous, it shouldn't be a judgment call - it should be based on documented policy.
Secondly, Infosec's role is not to be a road block. It's there to help conform (and modify) existing policy. If a policy is unworkable, fix it. But more likely the policy is functional and it will simply take some working with the end user / developer to modify the system design to properly conform with that policy.
Finally, there will be times when the policy is valid and the project simply can't be modified. This is where Infosec helps define to level of risk. Meanwhile, project developers define a business case for their architecture. Both cases are presented to higher management who ultimately weight risk against business case. And if the business case outweighs the risk, that risk is well documented.
The interesting thing is that the risks outlined are essentially existing risks handled with a slightly different understanding for FOSS. For example, they outline forking as a risk:
This should be familiar territory for anybody who's had their vendor End Of Life a product. The same general strategy applies to both proprietary software as FOSS. The only difference is that FOSS may offer more choices (there may be enough interest in the original fork to continue or if it is that important, you can fund continuation of the project yourself).
It might also be worth noting that some of these "unique" practices have to do with the ability to modify source code. That is certainly unique to most organizations used to working with proprietary software. However, organizations that do their own in-house development will have to face the same issues of copyright, patent infringement, etc. Of course, the issue of copyright and patent infringement has also come to light numerous times in the proprietary software world too. Perhapse nobody is imune to this after all.
Back on topic... TCO. From the document:
And again, there's nothing really surprising here. The key is that FOSS is not a magic bullet - you still have to work to deploy it. But anybody dealing with IT will find that much the same work will be done no matter where the code comes from.
It is interesting to note that nowhere does the FDIC say that FOSS will have a higher TCO. They outline a series of concerns that MAY drive TCO higher than the licensing might imply. But if an organization is carefully with their deployment strategy, they may find themselves able to deploy FOSS without driving up TCO and maintain that initial savings. Heck, they may even find that the available tools and strategies to handle some of these issues (change management, patch analysis / management, etc.) will help them manage TCO very well.
You think you're upset about Slashot. Just wait 'till you see what they're doing with Dremel stencils on Suicide Girls.
What a facinating idea. There could be a rather nasty suprise waiting for the camp that wishes to legally define "intellectual property". Once ideas become legally coded as a form of property, maybe even to the strongest sense of the law - real estate, then there's a whole slew of additional laws that govern the ownership of that property. It would represent quite a boon for government on available tax base alone.
And this stuff about legacy? It brings to mind ancestral estates. How many old bloodline families have had to turn over castles, manors, ranches, and other large estate items as that family finds itself no longer with the means to maintain the tax base the property represents? Legacy, indeed.
If the protocol is open and widely adopted, it will be hard for it to move around too quickly. Oddly enough, changing standards is a well-known and documented Microsoft business practice. Strange that you would imply Open Source involvement would bring this about. If anything, Open Source projects tend to favor open protocols which tend to be easy to implement if not fairly slow-moving and stable.
A "level playing field" is where nobody has the advantage. Everyone plays by the same rules (whether some are more successful than others is an entirely different issue). What you've described is a playing field where someone gets to alter the rules to their advantage.
Who said anything about the GPL? And who even mentioned code? This isn't about licensing software. This an issue with the fundamental protocol involved. The common protocols today are truly open where anybody can adopt them. A none-too-subtle reason for their success and widespread adoption. If Microsoft wants their ideas to be as successful, their proposed protocol must also be just as open and available. Even if that means a competitor implements said protocol in a better product than theirs.
The scope of this issue is bigger than Microsoft. Sure, there are good business cases for trying to keep a handle on a piece of technology. But there are times that this can't happen. This is one such time.
SMTP is an open protocol, available to anyone who wishes to implement it - no cost, no restrictions. If Microsoft wishes to introduce a technology that will work in that environment and enjoy the same level of success, it will have to have the same level of openness and availability. Otherwise, their attempts will most likely fail.
The question is exactly what Microsoft's business case is. Are they trying to own a protocol or cut the costs of one of the most fundamental protocols used in IT today - by themselves as well as the rest of the world? If it is the former, then sure... there's no fault in what they're trying to do. But at the same time, I wouldn't be willing to listen to them. But if the case is the later, then there is certainly fault in their methodology.
AT: This is not the business practice history you are looking for.
AT: Microsoft is misunderstood.
Of course, Microsoft doesn't have a history of hiring assassins and experts in mass murder. They just now have awoken to the possibilities of participating in politics - though have no history of interest in actually running for office.
They do, however, have a history of "embrace and extend", FUD, user lock-in, and other such business tactics. Heck - there are even publicly-available memos on some of these subjects.
It would seem that there IS more support for the parent than your comment. Unless, of course, you're getting ready to break the most stunning "Halloween Memo" to date?
And so Microsoft has a golden oportunity. They can help reduce costly spam incoming to their networks (corporate, hotmail, msn, etc.). They can help reduce one of the most popular vectors for malware that has a negative effect on adoption of their software. AND they can pull off a major warm-and-fuzzy PR move to counter the expanding cadre of IT types who have come to distrust, if not lothe them.
What do they do? Play licensing shennanigans.
Sketpicism is very much justified.
Sometimes subtle things make a big difference. On my WinXP box at work, I've had to install various 3rd party apps to try and duplicate common Linux desktop behaviors (virtual desktops, rolling windows, sloppy focus, etc.). I was kind of suprised at how annoyed I was when I didn't have those features.
That's not the next generation of geeks. That's the usual consumer who's finally adopting technology that had been the cutting edge realm of geeks past.
That just means they'll join #linux on their favorite IRC net and DEMAND someone tell them how to install this security patch.
Annoyed by the sense of entitlement, someone will tell them.
It doesn't matter. If the OSDDP projects don't produce usefully material, it'll sit unused. If it does prove to be usefully, it'll become widely adopted. Just like OSS, OSDDP material will live or die on merit - not corporate politics.
A couple points.
First, I some of O'Reilly's tactics quite intersting. For example, they sell a book on Subversion called Version Control with Subversion. The very same work is available online. The book is licensed under Creative Commons. This hasn't been the first work done in this manner by O'Reilly. And that would imply that there is something else to this business than hording documentation.
Secondly, even proprietary software produces a considerable market for technical books. Even for software that comes with complete, professionally writen manuals, etc. (sometimes even some degree of support).
Finally, documentation isn't new to Open Source. There are actually projects with some very good documentation (as rare as that may be). Yet publishing houses have began publishing an increasing number of technical books covering these as well as other Open Source projects.
I doubt better documentation is going to destroy the technical book business model for Open Source software.
My ISP is being a poor gatekeeper then. I can change service to another ISP. I can go to my local internet cafe. I can go the the library. I can wait until I go to work. In all cases, I can access the same information without my ISP either being aware of or having any say in that access.
Something gets printed in a Journal. How do you know it is correct? The same process of peer review and established trust can be done with the web. And, in fact, has been done for quite some time.
I also find myself at odds. On one hand, due to the nature of law, I would wish that all things were equal and the merits of the case were the sole consideration. But at the same time I am compelled to feel some admiration for one who excels at one's profession. Especially when that profession's mix of knowledge, presentation, and application of legal code present distinct similarities to hackers everywhere. I suppose the problem is when skill obscures merit.
Having said all that... don't cry for SCO. They're not the underfunded little guy. They have actually put considerable funds towards their legal team. And while IBM's legal team is held in high esteem, SCO has supposedly secured some considerable legal talent themselves.
Now if all that talent could produce an inkling of merit.
I agree on that point. And I pointed it out myself. Such components should be keyed so they can only be installed one way.
Absolutely not. If the system was assembled according to the technical drawings, they would not have been installed in reverse. The mistake wasn't a design that failed to work as expected. The mistake was an implementation that didn't follow the system design.
From the article: