... the real story is that
Gore told an absolutely truthful statement.... You'll find that all of
those attacks on Gore are nothing but GOP propaganda.
I dare say that the reality is that Gore's statements ring true from one point of view and are hogwash from another. The Democratic party promotes the former; the GOP, the later.
Your assertion that "the real story is that Gore told an absolutely trutheful statement" seems just as one sided as what you accuse the GOP of having done. If you have facts, post them. Otherwise, your assertion is just more one-sided political rhetoric.
Wrong. MacOS HFS and HFS+ maintain per-volume "desktop databases" that contain (among other things) a mapping of creators to their respective applications. Hold down Command and Option keys as a volume is mounted, and the Finder will give you a chance to rebuild the its desktop database.
I may have miscommunicated. I don't explicitly deny the existence of anything I don't have evidence for. I simply fail to accept its existence. It's the difference between saying, "There is no book in that room," and saying, "I have no information about whether there is a book in that room, and, lacking said information, have no rational choice but to continue on as if there is no book."
You have then chosen to assume -- or believe, perhaps -- that in lack of evidence to the contrary, the book does not exist. (Re-read what you wrote.) The reality, however, is that the book may or may not exist; not having entered the room, you don't know which. Therefore, if you were truly a facts-only person, you would have said, "... lacking said information, I have no rational choice but to accept the possibility of the book's existence (or nonexistence)."
Your choosing to continue on as if there were no book is a leap of faith, just as another person's choosing to believe that the book does exist is also a leap of faith.
Quantitatively speaking, if the probability of the book's existence could be determined to be p and hence its nonexistence q=1-p, your leap could be considered of magnitude 1/q and the other person's 1/p. (Note that if the book were known to exist, i.e., p=1, your leap would have to be infinite, which agrees with intuition.) As long as neither p nor q can be proven to be zero, there is a possibility that they are nonzero, and choosing to believe in either of possibilities they represent to the exclusion of the other is to some magnitude a leap of faith.
Even when people don't die as a direct consequence of hardware and software failures, they do die indirectly. Businesses spend a heap of money on these kinds of failures. They also lose untold fortunes in opportunity costs, the money they would have earned had they not been spending their time and money on computing failures.
Had these failures not occurred, the economy would have been significantly stronger, and a portion of this economic benefit would have gone to health care, medical research, and other life-saving investments. Because, however, the failures *did* occure, these investments were lost, and people died.
For example, it was reported that Lloyd's of London estimated the worldwide cost of the ILOVEYOU virus at 15 billion USD. Even if only 5% of this money had instead gone to life-saving investments (and this is a reasonable assumption; the average business spends over 5% of its money on health-care costs), there would have been 750 million more health-care dollars available to save lives. And with that kind of money, many lives could have been saved.
So the next time you justify shipping a buggy app because it's "not life-or-death critical" or "a few bugs won't hurt anybody", remember that there will be a cost associated with your program's failures, and somebody somewhere will be sicker or nearer to death because of it.
Sendmail would crumble under that kind of load. Hotmail, rather sanely, uses qmail for outgoing deliveries. Here's the Message-ID from a mail I received from a friend who uses Hotmail:
Given that most of the certified "professional" programmers that I have bumped into during my last few years of consulting weren't quite up to the, er, daunting task of writing sensible code in VB -- or code that just plain worked, for that matter -- I doubt that they would understand, let alone appreciate, wonders like Scheme's call-with-current-continuation.
The legions of programmers who have entered the market recently only because they see it as a quick and easy way to make money aren't interested in taking on the more-disciplined, almost mathematical mindset that seems to allow for maximum immersion into functional languages. Rather, they'll do whatever M$ says is the best way to earn the big, easy bux.
And that's why FP languages aren't more mainstream. (Thank goodness that Perl has map! At least I can sneak FP into one corporate semi-approved language.)
I'm not exactly sobbing into my beer because these bozos signed a contract containing provisions that they now have a problem with. Reading the contract (and I mean going through every bloody line) is essential in a business deal.
Normally, I would agree with you, but the reality these days is that web firms go after work from big businesses that don't have a clue about the web. The client in this case probably read the "five days" part of the contract and figured it was enough. Why? Because the web firm guys may have told them that it was plenty of time.
The bottom line is that if Razorfish negotiated a contract that virtually guaranteed that their client got hosed down, a lot fewer CIO's are going to trust Razorfish with their business.
You know how Windows Update claims that it works without sending any information to Microsoft? Well, the patent's abstract says that, "at the database server, a determination is made whether an upgrade package for the software program module component is available...." In other words, your computer sends a list of software and versions to M$, and M$ tells you what must be upgraded.
That doesn't seem consistent with Windows Update's "no information" claim. Perhaps, if M$ uses this patent in some future product, the company will disavow their "no information" promises. Or perhaps, with UCITA in place, they will consider it their right to audit your computer every time you use Windows Update, which might run every time you boot up.
Scary.
Able, experienced software pros are hard to get
on
The IT Labor Shortage
·
· Score: 1
It seems that it's easy to hire people with flavor-of-the-day skills and certifications -- and there are more than enough recruiters acting as certification factories these days -- but it seems almost impossible to find talented, experienced software professionals.
Most of the guys who are interviewed for jobs at the companies where I work (I'm a self-employeed consultant) fall into the "I just got my X certification," where X is some M$ cert. Their recruiters sell them as able, experienced pros: "This guy is sharp; he's even certified."
The sad thing is that most people hiring in the I/T sector don't know how to tell the wheat from the chaff. I'd say that about one-forth to one-third of the "able, experienced" pros that get hired are let go within two weeks because they can't cut it. A good portion of the remainder limps along, little better than deadwood. Sad, indeed.
What you don't hear is how innovative [open source] interfaces are. Why? Because they're not.
As if that's somehow bad.
One of the most widespread fallacies of user interface design is that innovation is good. It ain't. Innovation in a user interface is bad, unless the benefits of the new interface justify the cost of learning yet another interface.
Consider the car's user interface: steering wheel, pedals, shifter. Hasn't changed in half a century. Now, what happens if some whiz-kid designer comes up with a new innovative user interface for your Ford Escort? Maybe he replaces the boring and not-very-user-centric steering wheel and pedals with a simple, intuitive "omnidirectional pointing device" (joystick). Let's further stipulate that this new UI is actually easier to use than the current version, once you learn it.
Now, believe it or not, you've been driving cars for so long that you have become one with the old user interface. Despite its gross imperfections, your years of experience with its ways and nuances make it a more effective interface for you than the new one. Guess what happens the first time you use the new, "user-centric" UI. You drive like half-blind, drunken idiot, simply because you're unfamiliar with the new interface.
Has the new, user-centric interface helped you? Nope. The reason why is because it's not the interface that counts, it's how well you and the interface work together that is the true test of an interface. In other words, for most "innovative" user interfaces:
You + old interface>You + new, innovative interface
For any new interface where the above inequality holds, the innovation it contains is unjustified, and the interface ought not to be foisted on the world.
Yet, we are greeted with multitudes of crappy, but oh-my-yes innovative new user interfaces daily. Why, why, oh please tell me, why is this so? Why can't designers stop innovating for long enough to realize that most of their innovations are crap, or at very best not justifiably better than the present interfaces? Why must everything be innovative?
I think that I know the answer. It lies in the very culture that surrounds design firms, cutting-edge web shops, and "new media" consultancies. The answer is this:
The design culture treasures innovation more than goodness.
The design community treasures innovation to the point where, if an interface isn't innovative, it's considered bad. This is immensely dumb. Nevertheless, that's the way the design community thinks. (I've seen it in action, folks, and it ain't pretty.) At design contests, for example, "innovation" ranks at the top of the judging criteria. Your esteem in the eyes of your peers is determined by how innovative you are. Innovation pervades the designer's every waking thought.
It's madness, folks, and it must be stopped.
Attention user-interface designers of all walks:
If you design user interfaces, you owe it to your users not to innovate unless you can prove that your innovations not only make the user experience better (for the users, not your ego) but also that the experience is sufficiently better to justify foisting yet another friggin' user interface on the world.
You have been warned.
When the new revolution comes, and the dogs are loosed upon the criminals of the old world order, among the hunted groups will not only be lawyers and politicians but also the designers who innovated gratuitously.
Does MacOS let you use those screens as one logical screen?
Yes. Since the "Color Quickdraw" days ('86 or '87), the QuickDraw imaging system has supported an arbitrary number of graphics devices, which are united in the form of a single desktop. Note that this region need not be rectangular. (Application developers who need to know the geometry of the desktop region can use the GetGrayRgn toolbox call, but this need is infrequent in practice.)
Apple has encouraged developers to write their applications with the expectation that there may be any number of graphics devices, each of which may have different size, color, and depth characteristics. (See DeviceLoop for the recommended way to provide multi-device support in your MacOS applications.) Because MacOS applications have been "multi-device savvy" since day one, the multi-monitor support in MacOS is particuarly useful and impressive.
In this respect, MacOS makes a good model for emulation.
The original question was based on the faulty presupposition that a programming paradigm can, in fact, be a panacea. Sorry, ain't gonna happen.
Who besides obvious hypemongers ever said that OOP, OOA/D, and their ilk were the magic programming elixirs for all software ailments? Certainly not Stroustrup.
Most folks who have been writing software for more than a few years realize that there are no easy answers, no quick all-serving fixes, no silver bullets. Every paradigm is a tool in the programmer's kit. Each is effective at solving a certain class of problems. Pick the right tool for the job, and you're on easy street. Make the mistake of attacking every problem with a hammer, and you apt to do a lot of cursing.
Regarding what paradigms are "challenging" OO, I don't think that there are any challengers, not because OO is the king of the hill, but because the whole concept of one paradigm being the "best" doesn't make much sense. For some problems, OO is the best tool in the kit; for others, it isn't. Most non-trivial problems are best solved by using a number of paradigms, anyway. I sure wouldn't settle for just one.
Look, folks, there isn't ever going to be a one-tool kit that solves all problems. Quit knocking C++ because it isn't this mythical beast.
In other words, the reason why some companies could claim success with their deployment of NT was good old elbow-grease/sweat equity.
Sounds to me as if people were saying, "We bought this big, fancy luxury car -- NT. We've spent so much money on it at the local garage, just getting it to the point where we can actually drive the thing, that now that we can drive it, we going to drive it until the end of time!
In more corporate terms: "We in the I/T department have invested so much time and money in NT that if we just dumped it for Linux, we would look like idiots. After all, who would pour so much money into a product when a better (and free!) alternative exists? So, we're going to drive NT until the end of time!"
I'd say you're right about the GoF pattern book not being much incentive for folks who would be the best contributors to their documentation project. I was hoping that if you found an interesting new pattern, the Mozilla folks would let you name it (at least as far as their documentation went). But the rules state that only patterns from the book are acceptable.
That's too bad. I'd bet some heavy coin that the exceptional kind of pattern hunters who won't be tempted by Design Patterns would be exceptionally tempted by the possibility of finding a new pattern and then naming it something like Fist of the Firemonkey.
Now, what you seem to be missing is the investor connection. The investors determine the stock price. This price is based on perception -- what the investors think. If they think that RHAT is worth a bundle, they'll be willing to pay more, and the stock will go up, even if Red Hat's profits are nil and even if the stock price no longer has any relationship to reality. It's what the investors think, and nothing else, that counts.
Now, RHAT's financial filings are unimpressive, and yet they're stock is high. Why is that? Again, it's what the investors *think* that counts. Investors *think* that Red Hat is a part of this new Open Source Movement that they *think* promises to usher in an entirely new way of looking at, buying, maintaining, and using software, and they *think* that this promise will be very valuable someday. If that promise is false, however, they have no reason to invest in RHAT.
Consequently, if investors get wind that Red Hat is not playing nice with the Linux, Open Source, and free-software communities, they'll be forced to conclude that Red Hat, itself, doesn't buy into the promise of the Open Source Movement. The investors will *think* that the Open Source promise is broken, and they'll sell RHAT like crazy, and the stock price will drop. Which, as many people have pointed out, Red Hat's leaders are obligated to avoid.
And that's why Red Hat has an obligation to do right by the aforementioned communities.
Investors see that stock value as inseparably tied to Red Hat's relationship with the Linux and free-software communities. (After all, that's why investors bought RHAT stock even though the company's earnings were nil; they believed in the business model, which is based on Red Hat being a good, respected member of the aforementioned communities.)
Therefore, if Red Hat damages the relationships, its stock value drops.
Consequently, Red Hat must preserve its good standing in the aforementioned communities.
Get it? If investors wanted to buy into a company whose business model was based on bullying and weaselry, they would have bought MSFT. RHAT investors, on the other hand, expect Red Hat to be a good member of the communities because without those communities (and their respect), RHAT's business model won't fly. (Read Red Hat's pre-IPO SEC filing to see how dependent they are on the free-software commnunities.)
I must say that this post is self-contradictory. It basically says, since Red Hat is now a publicly traded company, that it has necessarily become weasely and will milk the Linux community for everything it's worth. The post then suggests that RHAT's only concern -- no, it's obligation -- is maximizing stock value, and so if you trust RH to do good deeds, you're simply a sucker.
I would say that quite the opposite is true. Because Red Hat has an obligation to its shareholders, it has an obligation to preserve and continually improve its relationship with the Linux and free-software communities. Red Hat has an obligation to genuinely contribute and genuinely do good works. Don't forget that most of RHAT's stock value derives from what the investment community considers a unique business model, one founded on free software and on a genuine partnership with the free software community.
If Red Hat were to start hosing down the free software community with a stream of weasily tactics, it would poison the genuine partnership and in doing so irreparably damage one of the foundations of its business model. It wouldn't take too long for the investment community to figure out that Red Hat considered its own business model to be a lie, and investors would drop the stock like a white-hot anvil.
Hence, Red Hat is obligated to do right by the Linux and free software communities.
Some of Red Hat's new hires, being brought in from the outside world, might overlook this important fact. And so, some Dumb Things will happen. This RMS distro might be one of them, but I don't think so. I think that the RMS distro was intended to be a good thing, and that some members of the Linux community have been overly harsh in their criticism of Red Hat.
In summary,
Red Hat is obligated to do right by the Linux and free software communities
The RMS distro isn't a bad thing, it's a good thing.
On the whole "Its" thing, it's not going to work because the meanings for its letter triple, i-t-s, are way too confusing already. (Take the previous sentence, for example.) If choosing between its and it's is a brain-numbing challenge for most of us today, why make the problem worse by throwing another meaning into the mix?
May I suggest an another option:
DAWDress-Aware Workers. Our bosses.
DOWDress-Oblivious Workers. Us.
Some notes:
That DAW, when pronounced, sounds much like an enthusiastic "Duh!" with a Texas drawl is not a coincidence and is highly suggestive of the deep truth hidden within.
That DOW is sometimes used to refer to the Dow-Jones Industrial Average is also not a coincidence. When the DOW climbs, we know whose work made it possible!
Slashdot Mirror
I dare say that the reality is that Gore's statements ring true from one point of view and are hogwash from another. The Democratic party promotes the former; the GOP, the later.
Your assertion that "the real story is that Gore told an absolutely trutheful statement" seems just as one sided as what you accuse the GOP of having done. If you have facts, post them. Otherwise, your assertion is just more one-sided political rhetoric.
Wrong. MacOS HFS and HFS+ maintain per-volume "desktop databases" that contain (among other things) a mapping of creators to their respective applications. Hold down Command and Option keys as a volume is mounted, and the Finder will give you a chance to rebuild the its desktop database.
l box/MoreToolbox-483.html
See:
http://developer.apple.com/techpubs/mac/MoreToo
You have then chosen to assume -- or believe, perhaps -- that in lack of evidence to the contrary, the book does not exist. (Re-read what you wrote.) The reality, however, is that the book may or may not exist; not having entered the room, you don't know which. Therefore, if you were truly a facts-only person, you would have said, "... lacking said information, I have no rational choice but to accept the possibility of the book's existence (or nonexistence)."
Your choosing to continue on as if there were no book is a leap of faith, just as another person's choosing to believe that the book does exist is also a leap of faith.
Quantitatively speaking, if the probability of the book's existence could be determined to be p and hence its nonexistence q=1-p, your leap could be considered of magnitude 1/q and the other person's 1/p. (Note that if the book were known to exist, i.e., p=1, your leap would have to be infinite, which agrees with intuition.) As long as neither p nor q can be proven to be zero, there is a possibility that they are nonzero, and choosing to believe in either of possibilities they represent to the exclusion of the other is to some magnitude a leap of faith.
In Italy, that's the way it is. Restaurants often list a nominal "service fee" on the menu, and that fee goes to your waiter(s); no tip is expected.
Even when people don't die as a direct consequence of hardware and software failures, they do die indirectly. Businesses spend a heap of money on these kinds of failures. They also lose untold fortunes in opportunity costs, the money they would have earned had they not been spending their time and money on computing failures.
Had these failures not occurred, the economy would have been significantly stronger, and a portion of this economic benefit would have gone to health care, medical research, and other life-saving investments. Because, however, the failures *did* occure, these investments were lost, and people died.
For example, it was reported that Lloyd's of London estimated the worldwide cost of the ILOVEYOU virus at 15 billion USD. Even if only 5% of this money had instead gone to life-saving investments (and this is a reasonable assumption; the average business spends over 5% of its money on health-care costs), there would have been 750 million more health-care dollars available to save lives. And with that kind of money, many lives could have been saved.
So the next time you justify shipping a buggy app because it's "not life-or-death critical" or "a few bugs won't hurt anybody", remember that there will be a cost associated with your program's failures, and somebody somewhere will be sicker or nearer to death because of it.
Maybe we could make fools out of the folks at CNET by posting an article on Slashdot that describes their foolishness. That would learn 'em!
Sendmail would crumble under that kind of load. Hotmail, rather sanely, uses qmail for outgoing deliveries. Here's the Message-ID from a mail I received from a friend who uses Hotmail:
<20000428205548.12433.qmail@hotmail.com>
Note the qmail part.
Given that most of the certified "professional" programmers that I have bumped into during my last few years of consulting weren't quite up to the, er, daunting task of writing sensible code in VB -- or code that just plain worked, for that matter -- I doubt that they would understand, let alone appreciate, wonders like Scheme's call-with-current-continuation.
The legions of programmers who have entered the market recently only because they see it as a quick and easy way to make money aren't interested in taking on the more-disciplined, almost mathematical mindset that seems to allow for maximum immersion into functional languages. Rather, they'll do whatever M$ says is the best way to earn the big, easy bux.
And that's why FP languages aren't more mainstream. (Thank goodness that Perl has map! At least I can sneak FP into one corporate semi-approved language.)
I'm not exactly sobbing into my beer because these bozos signed a contract containing provisions that they now have a problem with. Reading the contract (and I mean going through every bloody line) is essential in a business deal.
Normally, I would agree with you, but the reality these days is that web firms go after work from big businesses that don't have a clue about the web. The client in this case probably read the "five days" part of the contract and figured it was enough. Why? Because the web firm guys may have told them that it was plenty of time.
The bottom line is that if Razorfish negotiated a contract that virtually guaranteed that their client got hosed down, a lot fewer CIO's are going to trust Razorfish with their business.
This is even more picky, but the two versions aren't the same. The first version doesn't copy the trailing zero byte while yours does:
while (*s) *d++ = *s++;
vs.
while (*d++ = *s++) ;
You know how Windows Update claims that it works without sending any information to Microsoft? Well, the patent's abstract says that, "at the database server, a determination is made whether an upgrade package for the software program module component is available...." In other words, your computer sends a list of software and versions to M$, and M$ tells you what must be upgraded.
That doesn't seem consistent with Windows Update's "no information" claim. Perhaps, if M$ uses this patent in some future product, the company will disavow their "no information" promises. Or perhaps, with UCITA in place, they will consider it their right to audit your computer every time you use Windows Update, which might run every time you boot up.
Scary.
It seems that it's easy to hire people with flavor-of-the-day skills and certifications -- and there are more than enough recruiters acting as certification factories these days -- but it seems almost impossible to find talented, experienced software professionals.
Most of the guys who are interviewed for jobs at the companies where I work (I'm a self-employeed consultant) fall into the "I just got my X certification," where X is some M$ cert. Their recruiters sell them as able, experienced pros: "This guy is sharp; he's even certified."
The sad thing is that most people hiring in the I/T sector don't know how to tell the wheat from the chaff. I'd say that about one-forth to one-third of the "able, experienced" pros that get hired are let go within two weeks because they can't cut it. A good portion of the remainder limps along, little better than deadwood. Sad, indeed.
The author writes in the opening paragraph:
What you don't hear is how innovative [open source] interfaces are. Why? Because they're not.
As if that's somehow bad.
One of the most widespread fallacies of user interface design is that innovation is good. It ain't. Innovation in a user interface is bad, unless the benefits of the new interface justify the cost of learning yet another interface.
Consider the car's user interface: steering wheel, pedals, shifter. Hasn't changed in half a century. Now, what happens if some whiz-kid designer comes up with a new innovative user interface for your Ford Escort? Maybe he replaces the boring and not-very-user-centric steering wheel and pedals with a simple, intuitive "omnidirectional pointing device" (joystick). Let's further stipulate that this new UI is actually easier to use than the current version, once you learn it.
Now, believe it or not, you've been driving cars for so long that you have become one with the old user interface. Despite its gross imperfections, your years of experience with its ways and nuances make it a more effective interface for you than the new one. Guess what happens the first time you use the new, "user-centric" UI. You drive like half-blind, drunken idiot, simply because you're unfamiliar with the new interface.
Has the new, user-centric interface helped you? Nope. The reason why is because it's not the interface that counts, it's how well you and the interface work together that is the true test of an interface. In other words, for most "innovative" user interfaces:
You + old interface > You + new, innovative interfaceFor any new interface where the above inequality holds, the innovation it contains is unjustified, and the interface ought not to be foisted on the world.
Yet, we are greeted with multitudes of crappy, but oh-my-yes innovative new user interfaces daily. Why, why, oh please tell me, why is this so? Why can't designers stop innovating for long enough to realize that most of their innovations are crap, or at very best not justifiably better than the present interfaces? Why must everything be innovative?
I think that I know the answer. It lies in the very culture that surrounds design firms, cutting-edge web shops, and "new media" consultancies. The answer is this:
The design culture treasures innovation more than goodness.
The design community treasures innovation to the point where, if an interface isn't innovative, it's considered bad. This is immensely dumb. Nevertheless, that's the way the design community thinks. (I've seen it in action, folks, and it ain't pretty.) At design contests, for example, "innovation" ranks at the top of the judging criteria. Your esteem in the eyes of your peers is determined by how innovative you are. Innovation pervades the designer's every waking thought.
It's madness, folks, and it must be stopped.
Attention user-interface designers of all walks:
If you design user interfaces, you owe it to your users not to innovate unless you can prove that your innovations not only make the user experience better (for the users, not your ego) but also that the experience is sufficiently better to justify foisting yet another friggin' user interface on the world.
You have been warned.
When the new revolution comes, and the dogs are loosed upon the criminals of the old world order, among the hunted groups will not only be lawyers and politicians but also the designers who innovated gratuitously.
Think about it.
Does MacOS let you use those screens as one logical screen?
Yes. Since the "Color Quickdraw" days ('86 or '87), the QuickDraw imaging system has supported an arbitrary number of graphics devices, which are united in the form of a single desktop. Note that this region need not be rectangular. (Application developers who need to know the geometry of the desktop region can use the GetGrayRgn toolbox call, but this need is infrequent in practice.)
Apple has encouraged developers to write their applications with the expectation that there may be any number of graphics devices, each of which may have different size, color, and depth characteristics. (See DeviceLoop for the recommended way to provide multi-device support in your MacOS applications.) Because MacOS applications have been "multi-device savvy" since day one, the multi-monitor support in MacOS is particuarly useful and impressive.
In this respect, MacOS makes a good model for emulation.
The original question was based on the faulty presupposition that a programming paradigm can, in fact, be a panacea. Sorry, ain't gonna happen.
Who besides obvious hypemongers ever said that OOP, OOA/D, and their ilk were the magic programming elixirs for all software ailments? Certainly not Stroustrup.
Most folks who have been writing software for more than a few years realize that there are no easy answers, no quick all-serving fixes, no silver bullets. Every paradigm is a tool in the programmer's kit. Each is effective at solving a certain class of problems. Pick the right tool for the job, and you're on easy street. Make the mistake of attacking every problem with a hammer, and you apt to do a lot of cursing.
Regarding what paradigms are "challenging" OO, I don't think that there are any challengers, not because OO is the king of the hill, but because the whole concept of one paradigm being the "best" doesn't make much sense. For some problems, OO is the best tool in the kit; for others, it isn't. Most non-trivial problems are best solved by using a number of paradigms, anyway. I sure wouldn't settle for just one.
Look, folks, there isn't ever going to be a one-tool kit that solves all problems. Quit knocking C++ because it isn't this mythical beast.
Sounds to me as if people were saying, "We bought this big, fancy luxury car -- NT. We've spent so much money on it at the local garage, just getting it to the point where we can actually drive the thing, that now that we can drive it, we going to drive it until the end of time!
In more corporate terms: "We in the I/T department have invested so much time and money in NT that if we just dumped it for Linux, we would look like idiots. After all, who would pour so much money into a product when a better (and free!) alternative exists? So, we're going to drive NT until the end of time!"
Cheers,
Tom
I'd say you're right about the GoF pattern book not being much incentive for folks who would be the best contributors to their documentation project. I was hoping that if you found an interesting new pattern, the Mozilla folks would let you name it (at least as far as their documentation went). But the rules state that only patterns from the book are acceptable.
That's too bad. I'd bet some heavy coin that the exceptional kind of pattern hunters who won't be tempted by Design Patterns would be exceptionally tempted by the possibility of finding a new pattern and then naming it something like Fist of the Firemonkey.
Yes, too bad.
Cheers,
Tom
Now, what you seem to be missing is the investor connection. The investors determine the stock price. This price is based on perception -- what the investors think. If they think that RHAT is worth a bundle, they'll be willing to pay more, and the stock will go up, even if Red Hat's profits are nil and even if the stock price no longer has any relationship to reality. It's what the investors think, and nothing else, that counts.
Now, RHAT's financial filings are unimpressive, and yet they're stock is high. Why is that? Again, it's what the investors *think* that counts. Investors *think* that Red Hat is a part of this new Open Source Movement that they *think* promises to usher in an entirely new way of looking at, buying, maintaining, and using software, and they *think* that this promise will be very valuable someday. If that promise is false, however, they have no reason to invest in RHAT.
Consequently, if investors get wind that Red Hat is not playing nice with the Linux, Open Source, and free-software communities, they'll be forced to conclude that Red Hat, itself, doesn't buy into the promise of the Open Source Movement. The investors will *think* that the Open Source promise is broken, and they'll sell RHAT like crazy, and the stock price will drop. Which, as many people have pointed out, Red Hat's leaders are obligated to avoid.
And that's why Red Hat has an obligation to do right by the aforementioned communities.
Cheers,
Tom
More bluntly:
Get it? If investors wanted to buy into a company whose business model was based on bullying and weaselry, they would have bought MSFT. RHAT investors, on the other hand, expect Red Hat to be a good member of the communities because without those communities (and their respect), RHAT's business model won't fly. (Read Red Hat's pre-IPO SEC filing to see how dependent they are on the free-software commnunities.)
Cheers,
Tom
I must say that this post is self-contradictory. It basically says, since Red Hat is now a publicly traded company, that it has necessarily become weasely and will milk the Linux community for everything it's worth. The post then suggests that RHAT's only concern -- no, it's obligation -- is maximizing stock value, and so if you trust RH to do good deeds, you're simply a sucker.
I would say that quite the opposite is true. Because Red Hat has an obligation to its shareholders, it has an obligation to preserve and continually improve its relationship with the Linux and free-software communities. Red Hat has an obligation to genuinely contribute and genuinely do good works. Don't forget that most of RHAT's stock value derives from what the investment community considers a unique business model, one founded on free software and on a genuine partnership with the free software community.
If Red Hat were to start hosing down the free software community with a stream of weasily tactics, it would poison the genuine partnership and in doing so irreparably damage one of the foundations of its business model. It wouldn't take too long for the investment community to figure out that Red Hat considered its own business model to be a lie, and investors would drop the stock like a white-hot anvil.
Hence, Red Hat is obligated to do right by the Linux and free software communities.
Some of Red Hat's new hires, being brought in from the outside world, might overlook this important fact. And so, some Dumb Things will happen. This RMS distro might be one of them, but I don't think so. I think that the RMS distro was intended to be a good thing, and that some members of the Linux community have been overly harsh in their criticism of Red Hat.
In summary,
Cheers,
Tom
On the whole "Its" thing, it's not going to work because the meanings for its letter triple, i-t-s, are way too confusing already. (Take the previous sentence, for example.) If choosing between its and it's is a brain-numbing challenge for most of us today, why make the problem worse by throwing another meaning into the mix?
May I suggest an another option:
Some notes:
So please consider DAW and DOW.
Cheers,
Tom