the Workplace Shell (desktop UI, arguably the best part of OS/2)
Agreed. It's one of the things that still has me using OS/2 as my primary computer at home, rather than switching entirely to Linux(OTOH, the 3 other computers all run Linux). I'd love to see IBM port the WPS to X for use on Linux. I'd gladly pay per-machine for it.
Funny, ISTR doing just that. "OS/2 for Windows", I believe it was called.
OS/2 for Windows was OS/2 2.1, not the 1.x versions he was talking about. Instead of including Win 3.1 code, it used a user's already-licensed and installed copy of Win 3.1 for Win3.1 compatibility. If could also be handy if you had no interest in running Win3.1 programs under OS/2.
Why do adherents to the "Church of RMS" dig for such snide remarks?
Probably it's simply because (seemingly) almost everyone does nowadays. The Bulveristic[1] credo "Try to find some taint in your opponent before (or instead of) examining the logic of his arguments" in all of its variant forms(e.g. "Follow the money") seems to be ubiquitouis. It is, after all, much easier to cast aspersions on someone than to try to refute their arguments. It is also, as C. S. Lewis noted when slapping a name on this form of argument, "a truly democratic game in the sense that all can play it all day long, and that it gives no unfair privilege to the small and offensive minority who reason".
[1] See the C. S. Lewis collection "God in the Dock", the chapter titled(surprise, surprise) "Bulverism"
Or rather this is a common misconception in practice open source is often better supported than proprietary software.
While I'll agree, I will point out that management tends to have a different definition of support than us techies. We tend to think in information-gathering terms. 'Support', to us, means that we can get hold of whatever information is needed to fix the problems we encounter. Management tends to think in business structure terms. They want some business structure in place that will take responsibility for fixing or helping to fix problems.
In practice, as you noted, open-source style support is often superior, from the techie viewpoint. Business-structure support often puts you in touch with entry-level people who are used to giving out 'Please read the manual for me' level tech support, who don't actually run the software 'in anger', and who may very well be giving support out of pre-printed responses, rather than from their own knowledge and troubleshooting ability. From the 'information-gathering' standpoint, open-source style support, where you're in contact with your peers who are generally actually making real use of the software and have to deal with the same problems you do, is superior.
Aside from the business-structure blinders, I can see a little of where managers might sometimes be dubious. Managers often want to employ the kind of people who call tech support for 'read the manual to me'-style support. They're often cheaper, and less threatening to managerial ego. Open-source style support isn't geared towards the kind of hand-holding these people expect. You're normally expected to have read the relevant docs and tried to gather clues on your own before turning to a mailing list, usenet group, or whatever. Failing to do this will at best earn you a pointer to the relevant docs, and at worst will earn you a thorough flaming.
Now I'm not disagreeing with this state of things - it's not too much to ask of someone asking for free help that they do what research they're able to do on their own before imposing on others - I'm just pointing out that Open-source style support fails to pander to Managerial fantasies of doing Enterprise Computing in a Clue-Free environment. To carry it out to an extreme, many managers would like to be able to pull some moron off of the street, send him to some classes(or, even better, find someone who has already been through the classes and has a shiny certificate to show for it), and be sure that by buying the appropriate software and contracting the appropriate 'support', they can be assured of a stably-running operation, despite the deficiencies of their own people.
This is, of course, impossible(I can hear the managers now: "Don't say that!"). I'm exaggerating here, of course, but a fantasy very much like the above drives the heart of many a manager. When presented with the real-world "Your people can, with some study and work, learn to use the flexibility of open source software to your advantage" vs corporate marketing's "If you manage to find the right magic bullet, sold by the right company, you can have a stable, enterprise-wide computer system/network without having to hire all of those expensive and annoying techies", they're going to have an almost irresistable pull towards the latter.
All commercial software is released under licenses that disclaim all responsibility of the manufacturer -- sometimes with the exception of defective media shipped
I call this the standard software guarantee. The vendor will guarantee that:
You'll be able to read off of the supplied media whatever it is that the vendor put on it. If you can't, the vendor will give you a replacement.
Yet, these same people will often make ill-informed decisions about what software to run within a company, even over the objections of the people who have to suffer it.
I think this is often because people perceive being in a place of authority as automatically proving their superiority over their subordinates. Management requires different skills, not superior skills, and I don't think a lot of managers acknowledge that. "If I'm a manager, I must be smarter than you - that's how I got to be a manager". In some places, that's practically dogma. Challenge it, and you'll feel the wrath of managerial ego come crashing down on you. In this kind of atmosphere, it's easy to ignore the input of technical experts when it conflicts with what they hear from their peers(who, being managers, must be smarter than those irritating technical peons, some of whom have the audacity to have salaries an alarmingly large percentage of what the managers get.)
When we discuss the Internet Worm, for example, the blame doesn't fall totally on RTM. A sizable segment of blame goes to the authors of the finger and sendmail daemons that the Worm used to thrive and propogate. Their careless programming caused the environment, and they should have been able to recognize the danger well before RTM started to code.
Arguably, the finger and sendmail problems were coding errors, not designed in per se. The problems with Outlook et al. are the result of poorly thought out and designed features. I think the latter deserves more culpability than the former.
Wasn't that touted as as "feature" at one time? At least I can remember the phrase "good enough software" being touted. Of course, in other fields of endeavor, we have a slightly different word for this. We call it mediocrity.
Phil wrote a better compression program that was compatible with System Enhancements Associates (SEA) program called ARC
IIRC, Phil essentially wrote an assembler workalike of ARC, called PKArc. Naturally, it was faster.
So they litigated.
And they settled. My memory of the settlement is that Phil agreed to immediately change the name of his product to PKPAK, and to within a few months create a different product(which ended up being PKZIP). The rest of the settlement was secret(speculation in the BBS community seemed to be that it was SEA that wanted the secrecy. I later found a transcript of a thread on this subject on Bix where Thom Henderson(one of the founders of SEA) indicated it was PKWare that asked for it).
Many people in the BBS community thought that SEA was a little heavyhanded (Perception, I don't know the reality) and moved to PKZIP.
The suit basically had 3 claims:
Copyright infringement. There may have been something to this, as there were indications that there were comment typos in the SEA source that also showed up in the PKware source.
Usage of SEA's proprietary ARC file format.
Usage of SEA's proprietary.ARC extension
The latter two claims stuck in the craw of many in the BBS community(particularly the last one), and added a lot to the perception of SEA as a legal bully. As a result, many in the BBS community were quite eager to switch over as soon as PKZip became stable, and plenty of BBSs converted en mass shortly thereafter.
I've since come to regard this situation as a good example of the danger of pursuing a lawsuit with "legal blinders'(seeing things only from the perspective of the law) on, particularly when your market has access to large-scale communications. Ignoring the likely perceptions of your market may very well result in you winning the lawsuit, but losing the market. ARC very quickly went from the defacto standard archiving utility for the BBS and online service community to an also ran, largely as a result of the BBS community's perceptions of the suit.
But since Microsoft makes COMMERCIAL software, you can run right down to the courthouse and SUE THEIR ASSES OFF!
I mean, that's what you pay for when you buy commercial software, right?
Uh, sure, Bubba. And the likelyhood of your actually being able to win the suit in a short enough time to keep your business out of bankruptcy(not to mention all the rights you have to give up in order to get licenses) has nothing to do with the soundness of this as a business strategy. Right.
Personally, I think that anyone who thinks that betting your business on the ability to win a lawsuit against Microsoft is a sound business strategy is a few fries short of the Happy Meal they'll shortly be selling.
Hitler was really interested in Odhinnism and Norse mythology in general, but only so far as it could be used as a tool to enslave people's minds.
That might explain why he so utterly failed to grok it. C.S. Lewis(who had a lifelong appreciation for Norse mythology and 'northernness') expounds on this(in part) in a little essay entitled "First and Second Things"(which can be found in the collection "God in the Dock", which I heartily recommend to any who appreciate Lewis):
It was, therefore, a bitter moment when the Nazis took over my treasure and made it part of their ideology. But now all is well. They have proved unable to digest it. They can retain it only by standing the story on its head and making one of the minor villians the hero.
In other words, our society is once again looking for the "quick fix" answer to a generation of kids improperly raised and educated, then expected to act as morally capaple adults in a world where lying, cheating, extortion, and getting the most toys before you die is the name of the game.
Seems we always look for the quick fix. I'm becoming more and more convinced that if the U.S. has a characteristic fault that extends all across the political spectrum, it's the tendency to demand short term solutions without really considering whether those 'solutions' help or hurt in the long run.
Essentially, the issue boils down to a difference of view on what constitutes 'support'.
Management tends to think in structural terms; of having business structures in place to provide support when needed. We technical people tend to think in information gathering terms - we want to make sure we can get hold of the information needed to solve the problems we run into.
Of course, while it might theoretically seem that the two views would end up dovetailing, the reality too often is that they're quite diverged. Those business structures often end up staffed by entry-level people who primarily deal with 'read the documentation for me'-level tech support, and who often don't actually run the software they're supporting. For information-gathering purposes, informal peer support(with people who are actually using the software) is often more effective(unless, of course, you're looking for 'read the documentation for me'-level tech support, in which case you're not really a technical type).
One thing I have to wonder, though: what kind of 'mission-critical' application is there that could actually get by on 'read-me-the-documention-for-me'-level support?
As they sure as h*ll will modify the data on the computer during both processes, there is no way the victim (er, the owner of the computer) can point to what would have been changed without his knowlegde or consent. In effect, he has no ability to prove that the evidence wasn't there in the first place.
Unless, of course, he keeps archived backups. Depending on the nature of the planted evidence, it may be helpful to be able to show when the 'evidence' was actually introduced to the computer. Proving that someone, say, has been spying for the Chinese for the past 5 years can be a bit difficult when it can be shown that all of the computer 'evidence' didn't exist until 2 months ago.
Backups....they're not just for data recovery anymore
Slashdot Mirror
I tend to use the term "capistocracy"(rule by businessmen). As in "We may be capitalist, but we're not a capistocracy(at least, not yet)".
Agreed. It's one of the things that still has me using OS/2 as my primary computer at home, rather than switching entirely to Linux(OTOH, the 3 other computers all run Linux). I'd love to see IBM port the WPS to X for use on Linux. I'd gladly pay per-machine for it.
To the point where, under OS/2 2.1, they marketed a version(dubbed "OS/2 for Windows") that would grab a user's existing Win 3.1 and use it directly.
One of the third-party OS/2 vendors(Stardock?) recently tried to push something like that. I don't think they got too far with IBM on it.
OS/2 for Windows was OS/2 2.1, not the 1.x versions he was talking about. Instead of including Win 3.1 code, it used a user's already-licensed and installed copy of Win 3.1 for Win3.1 compatibility. If could also be handy if you had no interest in running Win3.1 programs under OS/2.
Probably it's simply because (seemingly) almost everyone does nowadays. The Bulveristic[1] credo "Try to find some taint in your opponent before (or instead of) examining the logic of his arguments" in all of its variant forms(e.g. "Follow the money") seems to be ubiquitouis. It is, after all, much easier to cast aspersions on someone than to try to refute their arguments. It is also, as C. S. Lewis noted when slapping a name on this form of argument, "a truly democratic game in the sense that all can play it all day long, and that it gives no unfair privilege to the small and offensive minority who reason".
[1] See the C. S. Lewis collection "God in the Dock", the chapter titled(surprise, surprise) "Bulverism"
While I'll agree, I will point out that management tends to have a different definition of support than us techies. We tend to think in information-gathering terms. 'Support', to us, means that we can get hold of whatever information is needed to fix the problems we encounter. Management tends to think in business structure terms. They want some business structure in place that will take responsibility for fixing or helping to fix problems.
In practice, as you noted, open-source style support is often superior, from the techie viewpoint. Business-structure support often puts you in touch with entry-level people who are used to giving out 'Please read the manual for me' level tech support, who don't actually run the software 'in anger', and who may very well be giving support out of pre-printed responses, rather than from their own knowledge and troubleshooting ability. From the 'information-gathering' standpoint, open-source style support, where you're in contact with your peers who are generally actually making real use of the software and have to deal with the same problems you do, is superior.
Aside from the business-structure blinders, I can see a little of where managers might sometimes be dubious. Managers often want to employ the kind of people who call tech support for 'read the manual to me'-style support. They're often cheaper, and less threatening to managerial ego. Open-source style support isn't geared towards the kind of hand-holding these people expect. You're normally expected to have read the relevant docs and tried to gather clues on your own before turning to a mailing list, usenet group, or whatever. Failing to do this will at best earn you a pointer to the relevant docs, and at worst will earn you a thorough flaming.
Now I'm not disagreeing with this state of things - it's not too much to ask of someone asking for free help that they do what research they're able to do on their own before imposing on others - I'm just pointing out that Open-source style support fails to pander to Managerial fantasies of doing Enterprise Computing in a Clue-Free environment. To carry it out to an extreme, many managers would like to be able to pull some moron off of the street, send him to some classes(or, even better, find someone who has already been through the classes and has a shiny certificate to show for it), and be sure that by buying the appropriate software and contracting the appropriate 'support', they can be assured of a stably-running operation, despite the deficiencies of their own people.
This is, of course, impossible(I can hear the managers now: "Don't say that!"). I'm exaggerating here, of course, but a fantasy very much like the above drives the heart of many a manager. When presented with the real-world "Your people can, with some study and work, learn to use the flexibility of open source software to your advantage" vs corporate marketing's "If you manage to find the right magic bullet, sold by the right company, you can have a stable, enterprise-wide computer system/network without having to hire all of those expensive and annoying techies", they're going to have an almost irresistable pull towards the latter.
I call this the standard software guarantee. The vendor will guarantee that:
I think this is often because people perceive being in a place of authority as automatically proving their superiority over their subordinates. Management requires different skills, not superior skills, and I don't think a lot of managers acknowledge that. "If I'm a manager, I must be smarter than you - that's how I got to be a manager". In some places, that's practically dogma. Challenge it, and you'll feel the wrath of managerial ego come crashing down on you. In this kind of atmosphere, it's easy to ignore the input of technical experts when it conflicts with what they hear from their peers(who, being managers, must be smarter than those irritating technical peons, some of whom have the audacity to have salaries an alarmingly large percentage of what the managers get.)
If you're referring to C2 certification, last I knew all of the C2-level certifications for NT were for non-networked configurations.
Please go read the "Washington Supreme Court Upholds Shrinkwrap Licensing" article again, and explain the reasoning behind your statement.
Arguably, the finger and sendmail problems were coding errors, not designed in per se. The problems with Outlook et al. are the result of poorly thought out and designed features. I think the latter deserves more culpability than the former.
Wasn't that touted as as "feature" at one time? At least I can remember the phrase "good enough software" being touted. Of course, in other fields of endeavor, we have a slightly different word for this. We call it mediocrity.
IIRC, Phil essentially wrote an assembler workalike of ARC, called PKArc. Naturally, it was faster.
And they settled. My memory of the settlement is that Phil agreed to immediately change the name of his product to PKPAK, and to within a few months create a different product(which ended up being PKZIP). The rest of the settlement was secret(speculation in the BBS community seemed to be that it was SEA that wanted the secrecy. I later found a transcript of a thread on this subject on Bix where Thom Henderson(one of the founders of SEA) indicated it was PKWare that asked for it).
The suit basically had 3 claims:
The latter two claims stuck in the craw of many in the BBS community(particularly the last one), and added a lot to the perception of SEA as a legal bully. As a result, many in the BBS community were quite eager to switch over as soon as PKZip became stable, and plenty of BBSs converted en mass shortly thereafter.
I've since come to regard this situation as a good example of the danger of pursuing a lawsuit with "legal blinders'(seeing things only from the perspective of the law) on, particularly when your market has access to large-scale communications. Ignoring the likely perceptions of your market may very well result in you winning the lawsuit, but losing the market. ARC very quickly went from the defacto standard archiving utility for the BBS and online service community to an also ran, largely as a result of the BBS community's perceptions of the suit.
Uh, sure, Bubba. And the likelyhood of your actually being able to win the suit in a short enough time to keep your business out of bankruptcy(not to mention all the rights you have to give up in order to get licenses) has nothing to do with the soundness of this as a business strategy. Right.
Personally, I think that anyone who thinks that betting your business on the ability to win a lawsuit against Microsoft is a sound business strategy is a few fries short of the Happy Meal they'll shortly be selling.
Politics as usual in the U.S.?
That might explain why he so utterly failed to grok it. C.S. Lewis(who had a lifelong appreciation for Norse mythology and 'northernness') expounds on this(in part) in a little essay entitled "First and Second Things"(which can be found in the collection "God in the Dock", which I heartily recommend to any who appreciate Lewis):
Seems we always look for the quick fix. I'm becoming more and more convinced that if the U.S. has a characteristic fault that extends all across the political spectrum, it's the tendency to demand short term solutions without really considering whether those 'solutions' help or hurt in the long run.
McElwaine? Is that you?
Do you really want to force ISPs to become judge and jury when they get a complaint? I see nothing good coming out of such a situation.
Cricket has rules? Why spoil it with rules?
That's absolutely amazing, considering that Mindspring didn't open its doors until June 1994.
Essentially, the issue boils down to a difference of view on what constitutes 'support'.
Management tends to think in structural terms; of having business structures in place to provide support when needed. We technical people tend to think in information gathering terms - we want to make sure we can get hold of the information needed to solve the problems we run into.
Of course, while it might theoretically seem that the two views would end up dovetailing, the reality too often is that they're quite diverged. Those business structures often end up staffed by entry-level people who primarily deal with 'read the documentation for me'-level tech support, and who often don't actually run the software they're supporting. For information-gathering purposes, informal peer support(with people who are actually using the software) is often more effective(unless, of course, you're looking for 'read the documentation for me'-level tech support, in which case you're not really a technical type).
One thing I have to wonder, though: what kind of 'mission-critical' application is there that could actually get by on 'read-me-the-documention-for-me'-level support?
Ben
Unless, of course, he keeps archived backups. Depending on the nature of the planted evidence, it may be helpful to be able to show when the 'evidence' was actually introduced to the computer. Proving that someone, say, has been spying for the Chinese for the past 5 years can be a bit difficult when it can be shown that all of the computer 'evidence' didn't exist until 2 months ago.
Backups....they're not just for data recovery anymore
If you're responsible for the network at a college, do you:
If you do either of these, what justifications will you give when the student body eventually calls for your head? Discuss.