" No. MS is all about having a dominating market share."
Ah yes, but stock price is all about revenue growth. No matter how profitable MS might be, today's profit is for today's shareholders. The current share price reflects certain assumptions about the future growth of MS profit. The only way the stock goes higher is expectation of even higher profits in the future. Nobody bids up a company whose profitability is falling as they cut prices to try and retain market share. It will be very tough for MS to cut expenses faster than the decline in revenue. Even if they do, investors won't be happy about it.
In the short run, it's easier to identify (and screw) those customers least willing to switch. Otherwise, their growth rate is limited to the growth of the PC market (minus whatever price cuts they might make).
I am not a financial advisor. This is not investment advice.
When MS finally says 'Screw it, go Linux if you are not happy with our prices', the customers will shift from Linux talk to Linux action. Those who remain with MS are the ones who are locked-in and therefore insenstive to price. The prices will go higher and higher as the customer base slowly dwindles.
All software companies go this way. At some point, they have sold the product to everyone who needs it, and any growth in revenue HAS to come from price increases. They have already tried to accelerate the upgrade cycle, with little success. Many users never upgraded from Office 97 or Windows 98!
Because the latest Linux distros would be up and running in about 2 weeks, while MS would be working 24 x 7 for months to crank out a buggy Alpha version of XP. Intel rarely offends MS, despite the fact that MS needs Intel more than the other way around.
Just like teenage sex, everyone is sure that computers will be better (and probably safer) "next time".
The Chinese are not anywhere near as locked into MS as the western world. For them, this IS "next time". They can learn from our mistakes. If we had it to do all over again, there are many things we would build differently -- the streets of Boston, for example.
The whole concept of large-scale open source development is very much in line with Asian concept of group participation. Of course, there is also the tendency to emulate all things American, but the urge to do this will subside as the Chinese realize that Americans are not all that thrilled with Microsoft products -- we merely tolerate them as the cost of doing business. In China, MS has no such lock-in and they are unlikely to achieve it.
Besides, the Chinese are unlikely to continue as the low-cost producers of anything if they throw money away on poor software, especially when there are cheaper and better substitutes available. If nothing else does it first, spyware and viruses will kill MS in China.
So much for $2/gallon gas
on
Port-A-Nuke
·
· Score: 2, Interesting
I'll bet the 10 megawatt model could be hooked up to an electric motor and transmission. No more gas station. Probably fast as hell too!
Security was always a problem, such as password stealers left running on VT100 terminals, stupid Motif tricks, and my personal favorite: the "default DECnet" account. In the 80's, DEC's TCP/IP stack for VMS was in a layered product called Ultrix connection (UCX). Not only was it not included as part of VMS, it wasn't even all that good. We had a product called TGV Multinet, which was a somewhat more robust package. I say "somewhat" because it had trouble with multi-processor systems. Multinet and its spinlock problems crashed our Vax more than all other hardware and software problems combined. But then again, the whole story is memorable only because the crashes were few and far between.
The amazing part about 6-years of uptime is that back in the 1980's we took it for granted! Most mainframes can stay up as long as the power reamins on. Only Windows can make us appreciate the value of perpetual uptime.
One of the reasons we had such uptime was that the software update cycle was very slow by modern standards. Every few weeks, Digital would send us a 9-track tape to update one of our products. VMS was generally once a year between major releases. Anything except an OS update could be installed without rebooting.
Before we had all of this object-oriented programming, the concept of memory leakage was much easier to debug. Also, VMS would exercise tight control over system resources -- a runaway process might cause a slowdown, but processes were limited in their ability to consume memory and page file space.
When there was a crash (it happened), we would call Digital customer support. They would actually read the crash dump and determine hardware or software, and either dispatch field service or send out a patch to be installed. It cost a fortune, but it sure beat the modern concept of calling tech. support and dealing with a semi-literate script reader.
We had three Vaxes in a cluster, attached to a pair of redundant disk/tape controllers. To this day, I hear people talk about the wonderful world of Windows (or even Linux) clusters on Intel boxes. The problem is that without multiple independent paths to your disk drives and something like the distributed lock manager, there is really no protection against the loss of a CPU or a disk controller. Digital had all of this figured out. It must have been quite an accomplishment, because I have seen mostly poor imitations of VMS clusters since that time.
Ask the folks at Coors or Smith & Wesson. In those boycotts, people just bought other brands of beer and guns. In the case of DRM, an entire industry has to be targeted. While it is hard to boycott a necessity like gasoline or electricity, digital entertainment is a sitting duck for this type of strategy. It's time to speak to the MPAA & RIAA using a language they understand.
ARRL's is well-known for going to DEFCON 1 whenever amateur radio spectrum is threatened. That's a good thing, because there would be no such thing as amateur HF spectrum if not for their lobbying efforts. Like the open source people who had extensive involvement in creating the Internet as we know it today, amateurs were the pioneers of almost all modes of modern wireless communications.
I do not understand why BPL has to exist in conlict with HF. Broadband is essentially a big fat RF channel. It could be made to work at much higher frequencies that will not bounce off the ionosphere and turn the HF spectrum into a global RF septic tank. If it was done properly, they could probably get more bandwidth (and therefore higher speeds) by using higher frequencies.
One of the other posts commented on the viability of wrapping fiber optic cable around the power lines. I like that idea best of all. No RF problem, OC-3 speed, what's not to like?
Taxation on the program, per installation, and a tax on the ads devivered via spyware. While we're at it, maybe a tax on each byte of data sent outbound via spyware. Killing spyware is then a simple act of following the money and taxing the hell out of those who distribute or benefit from it.
Companies who invest heavily in planning and specifications can (in theory) reap the rewards of low-cost offshore labor. Those who don't will suffer, primarily due to the time zone and language barriers. Of course, all of this planning and specification building is easier said than done.
Some companies will "double-dip" -- save time by launching a project with a half-baked specification, then save money by using offshore IT development. Senior managers love to congratulate themselves for innovative cost-cutting ideas like this. Ironically, we NEED this to happen every once in a while, just to create a market for solving the problem. If there were no fires, who would hire a firefighter? Here we have senior management playing the role of a kid who has just discovered the thrill of playing with matches. Let 'em play.
Whenever there is a problem, there is also opportunity. The opportunity for local IT is to:
Concentrate on building the high-quality specifications and project plans that offshore IT needs to be productive.
Work directly on projects that MUST be developed "on-the-fly". There will always be projects that cannot tolerate 24-hour turnaround time on simple questions, misunderstood instructions, or the extra time it takes to develop a comprehensive project plan. Offshore labor is cheap, nobody ever said it was fast.
Salvage the "train wreck" projects resulting from the "double-dipping" strategy I previously described. Companies that survive these train wrecks will have a newfound appreciation for those who cleaned up the mess. Survivors of the disaster will have a different strategy next time.
Most of the rights to SYSV belong to Novell, not SCO. From a Linux point of view, nobody has shown any infringing code, but some variants of Unix really ARE based on SYSV and the ownership of code might matter. I doubt that even Novell can actually prove ownership of everything in SYSV or clearly define their rights in a way that would hold up in court. Therefore they collect revenue in some areas where their rights are not disputed, using SCO as a sort of collection agent.
There is a theory out there stating that Sun's attempt to open source Solaris is just a ruse, so as to pump up whatever is left of SCO's credibility.
Sun: "We are going to GPL Solaris". SCO: "No you can't, we own Unix and the license you bought from us does not allow you to GPL Solaris". Sun: "Oh, that's right. You own Unix, and that's why we paid for a license. Silly us."
If IBM somehow becomes the owner of SCO's IP (whatever that may prove to be), they could possibly remove the SCO "obstacle" to Solaris/GPL and therefore call Sun's bluff. In that case, Sun would just make some other excuse for declining to GPL Solaris (probably blaming Novell). It would be fun to watch, but not quite so much fun as seeing the "For Sale or Lease" sign at SCO headquarters or Darl's resume on monster.com.
Sulu: "Captain, there is a piece of paper floating in space, directly in front of our ship!"
Kirk: "What does it say? Put it on the screen."
Spock: "Use of insulating devices will interfere with your notebook's thermal design and will void your warranty."
Kirk: "Great, but what does it MEAN?"
Spock: "In Earth's 20th century, there was a software company that now makes software for the Klingons and Romulans. This ancient software consumed vast resources and even portable computers of the era generated a tremendous amount of heat. To this day, the Klingons and Romulans are trying to make their computers run cooler and stop them from being hacked by freshmen from the Federation Middle School. The existance of this paper would tend to indicate the presence of a hostile ship nearby."
"Trading one monopoly for another makes no sense."
Is there some part of IBM's involvment with Linux that requires IBM's participation after the sale? The only case where that might make sense is their proprietary hardware. If I run Linux on an IBM mainframe, I might have limited choices if I want to rely on IBM support. But then again, I can make the ultimate choice to migrate to some other hardware platform and keep my Linux applications pretty much intact. The mere existence of that option is going to make IBM more interested in meeting customer expectations.
With Linux, I can have whatever level of independence I choose. At the outer edge, I can in-source my software support and build a custom kernel if I want to. In reality, it makes sense to have some level of external support with the tradeoff being some limitation of what you do with the system.
For every strategic decision I make, I want an escape route in case it goes badly. I was asked, "How do you escape from your dependence on Linux if you face major problems?" My response: "It's a lot easier to get rid of Linux than to get rid of Microsoft, and if such a migration becomes necessary I will have saved enough money to pay for it."
Even if IBM somehow managed to create a Linux monopoly, the bottom line effect would be similar to replacing a one party dictatorship with two party democracy. Granted, the two party system often produces lousy candidates, but it still outperforms any dictatorship. Having more choices is seldom a bad thing.
The modeller's budget probably didn't include enough money to develop the DiLithium crystal engines that allegedly powered the "real" ship, so he faked it with a prop. That's fairly common in R/C modelling; there are quite a few models of "jets" that are prop-driven. With a huge increase in cost, I suppose he could have had some kind of turbojets or ducted fans. At that point, it would be a really big model.
Using the disc-shaped part of the ship as a wing is a cool idea. Of course, the "real" ship would not have had anything other than engine thrust to control roll, pitch, and yaw, so whatever control surfaces he had on that thing were totally bogus. For that matter, the ship was never supposed to enter the atmosphere of any planet, so its aerodynamic properties were meaningless anyway.
I lose my SBC DS1 line every time it rains. They fumble and bumble, I lose a day's work, and my CEO gets grumpy. Eventually, the water evaporates and all of a sudden, it's "No trouble found". I don't see how a strike would change anything.
The learning curve is pretty steep for newbies, but the features, scalability, and price are hard to beat. It's not the standard Apache/MySQL/PHP approach, but there is alot to like about it.
Warning: Zope has some religious followers that make RMS look tame by comparison. Fortunately, most of the enthusiasm is justified by what the product can actually do.
Slashdot Mirror
" No. MS is all about having a dominating market share."
Ah yes, but stock price is all about revenue growth. No matter how profitable MS might be, today's profit is for today's shareholders. The current share price reflects certain assumptions about the future growth of MS profit. The only way the stock goes higher is expectation of even higher profits in the future. Nobody bids up a company whose profitability is falling as they cut prices to try and retain market share. It will be very tough for MS to cut expenses faster than the decline in revenue. Even if they do, investors won't be happy about it.
In the short run, it's easier to identify (and screw) those customers least willing to switch. Otherwise, their growth rate is limited to the growth of the PC market (minus whatever price cuts they might make).
I am not a financial advisor. This is not investment advice.
When MS finally says 'Screw it, go Linux if you are not happy with our prices', the customers will shift from Linux talk to Linux action. Those who remain with MS are the ones who are locked-in and therefore insenstive to price. The prices will go higher and higher as the customer base slowly dwindles.
All software companies go this way. At some point, they have sold the product to everyone who needs it, and any growth in revenue HAS to come from price increases. They have already tried to accelerate the upgrade cycle, with little success. Many users never upgraded from Office 97 or Windows 98!
Because the latest Linux distros would be up and running in about 2 weeks, while MS would be working 24 x 7 for months to crank out a buggy Alpha version of XP. Intel rarely offends MS, despite the fact that MS needs Intel more than the other way around.
He should launch Operation Unsubscribe
Maybe the robot can be reconfigured to digest spammers?
Just like teenage sex, everyone is sure that computers will be better (and probably safer) "next time".
The Chinese are not anywhere near as locked into MS as the western world. For them, this IS "next time". They can learn from our mistakes. If we had it to do all over again, there are many things we would build differently -- the streets of Boston, for example.
The whole concept of large-scale open source development is very much in line with Asian concept of group participation. Of course, there is also the tendency to emulate all things American, but the urge to do this will subside as the Chinese realize that Americans are not all that thrilled with Microsoft products -- we merely tolerate them as the cost of doing business. In China, MS has no such lock-in and they are unlikely to achieve it.
Besides, the Chinese are unlikely to continue as the low-cost producers of anything if they throw money away on poor software, especially when there are cheaper and better substitutes available. If nothing else does it first, spyware and viruses will kill MS in China.
I'll bet the 10 megawatt model could be hooked up to an electric motor and transmission. No more gas station. Probably fast as hell too!
Henry Kissinger's comment on the Iran/Iraq war in the 80's: "Too bad they can't both lose."
Security was always a problem, such as password stealers left running on VT100 terminals, stupid Motif tricks, and my personal favorite: the "default DECnet" account. In the 80's, DEC's TCP/IP stack for VMS was in a layered product called Ultrix connection (UCX). Not only was it not included as part of VMS, it wasn't even all that good. We had a product called TGV Multinet, which was a somewhat more robust package. I say "somewhat" because it had trouble with multi-processor systems. Multinet and its spinlock problems crashed our Vax more than all other hardware and software problems combined. But then again, the whole story is memorable only because the crashes were few and far between.
The amazing part about 6-years of uptime is that back in the 1980's we took it for granted! Most mainframes can stay up as long as the power reamins on. Only Windows can make us appreciate the value of perpetual uptime.
One of the reasons we had such uptime was that the software update cycle was very slow by modern standards. Every few weeks, Digital would send us a 9-track tape to update one of our products. VMS was generally once a year between major releases. Anything except an OS update could be installed without rebooting.
Before we had all of this object-oriented programming, the concept of memory leakage was much easier to debug. Also, VMS would exercise tight control over system resources -- a runaway process might cause a slowdown, but processes were limited in their ability to consume memory and page file space.
When there was a crash (it happened), we would call Digital customer support. They would actually read the crash dump and determine hardware or software, and either dispatch field service or send out a patch to be installed. It cost a fortune, but it sure beat the modern concept of calling tech. support and dealing with a semi-literate script reader.
We had three Vaxes in a cluster, attached to a pair of redundant disk/tape controllers. To this day, I hear people talk about the wonderful world of Windows (or even Linux) clusters on Intel boxes. The problem is that without multiple independent paths to your disk drives and something like the distributed lock manager, there is really no protection against the loss of a CPU or a disk controller. Digital had all of this figured out. It must have been quite an accomplishment, because I have seen mostly poor imitations of VMS clusters since that time.
Ask the folks at Coors or Smith & Wesson. In those boycotts, people just bought other brands of beer and guns. In the case of DRM, an entire industry has to be targeted. While it is hard to boycott a necessity like gasoline or electricity, digital entertainment is a sitting duck for this type of strategy. It's time to speak to the MPAA & RIAA using a language they understand.
Isn't it just a matter of time before somebody builds a receiver that is essentially a BPL packet sniffer?
ARRL's is well-known for going to DEFCON 1 whenever amateur radio spectrum is threatened. That's a good thing, because there would be no such thing as amateur HF spectrum if not for their lobbying efforts. Like the open source people who had extensive involvement in creating the Internet as we know it today, amateurs were the pioneers of almost all modes of modern wireless communications.
I do not understand why BPL has to exist in conlict with HF. Broadband is essentially a big fat RF channel. It could be made to work at much higher frequencies that will not bounce off the ionosphere and turn the HF spectrum into a global RF septic tank. If it was done properly, they could probably get more bandwidth (and therefore higher speeds) by using higher frequencies.
One of the other posts commented on the viability of wrapping fiber optic cable around the power lines. I like that idea best of all. No RF problem, OC-3 speed, what's not to like?
The internal memo that describes the "technical problem" that prevents releasing the data.
Taxation on the program, per installation, and a tax on the ads devivered via spyware. While we're at it, maybe a tax on each byte of data sent outbound via spyware. Killing spyware is then a simple act of following the money and taxing the hell out of those who distribute or benefit from it.
Amadeu wasn't rignt about their business practices.
No, but perhaps they have obviously given some thought about what to say when it crashes or gets hijacked by 12-year-olds.
Some companies will "double-dip" -- save time by launching a project with a half-baked specification, then save money by using offshore IT development. Senior managers love to congratulate themselves for innovative cost-cutting ideas like this. Ironically, we NEED this to happen every once in a while, just to create a market for solving the problem. If there were no fires, who would hire a firefighter? Here we have senior management playing the role of a kid who has just discovered the thrill of playing with matches. Let 'em play.
Whenever there is a problem, there is also opportunity. The opportunity for local IT is to:
Most of the rights to SYSV belong to Novell, not SCO. From a Linux point of view, nobody has shown any infringing code, but some variants of Unix really ARE based on SYSV and the ownership of code might matter. I doubt that even Novell can actually prove ownership of everything in SYSV or clearly define their rights in a way that would hold up in court. Therefore they collect revenue in some areas where their rights are not disputed, using SCO as a sort of collection agent.
There is a theory out there stating that Sun's attempt to open source Solaris is just a ruse, so as to pump up whatever is left of SCO's credibility.
Sun: "We are going to GPL Solaris".
SCO: "No you can't, we own Unix and the license you bought from us does not allow you to GPL Solaris".
Sun: "Oh, that's right. You own Unix, and that's why we paid for a license. Silly us."
If IBM somehow becomes the owner of SCO's IP (whatever that may prove to be), they could possibly remove the SCO "obstacle" to Solaris/GPL and therefore call Sun's bluff. In that case, Sun would just make some other excuse for declining to GPL Solaris (probably blaming Novell). It would be fun to watch, but not quite so much fun as seeing the "For Sale or Lease" sign at SCO headquarters or Darl's resume on monster.com.
Sulu: "Captain, there is a piece of paper floating in space, directly in front of our ship!"
Kirk: "What does it say? Put it on the screen."
Spock: "Use of insulating devices will interfere with your notebook's thermal design and will void your warranty."
Kirk: "Great, but what does it MEAN?"
Spock: "In Earth's 20th century, there was a software company that now makes software for the Klingons and Romulans. This ancient software consumed vast resources and even portable computers of the era generated a tremendous amount of heat. To this day, the Klingons and Romulans are trying to make their computers run cooler and stop them from being hacked by freshmen from the Federation Middle School. The existance of this paper would tend to indicate the presence of a hostile ship nearby."
Kirk: "All hands, battle stations"
"Trading one monopoly for another makes no sense."
Is there some part of IBM's involvment with Linux that requires IBM's participation after the sale? The only case where that might make sense is their proprietary hardware. If I run Linux on an IBM mainframe, I might have limited choices if I want to rely on IBM support. But then again, I can make the ultimate choice to migrate to some other hardware platform and keep my Linux applications pretty much intact. The mere existence of that option is going to make IBM more interested in meeting customer expectations.
With Linux, I can have whatever level of independence I choose. At the outer edge, I can in-source my software support and build a custom kernel if I want to. In reality, it makes sense to have some level of external support with the tradeoff being some limitation of what you do with the system.
For every strategic decision I make, I want an escape route in case it goes badly. I was asked, "How do you escape from your dependence on Linux if you face major problems?" My response: "It's a lot easier to get rid of Linux than to get rid of Microsoft, and if such a migration becomes necessary I will have saved enough money to pay for it."
Even if IBM somehow managed to create a Linux monopoly, the bottom line effect would be similar to replacing a one party dictatorship with two party democracy. Granted, the two party system often produces lousy candidates, but it still outperforms any dictatorship. Having more choices is seldom a bad thing.
The modeller's budget probably didn't include enough money to develop the DiLithium crystal engines that allegedly powered the "real" ship, so he faked it with a prop. That's fairly common in R/C modelling; there are quite a few models of "jets" that are prop-driven. With a huge increase in cost, I suppose he could have had some kind of turbojets or ducted fans. At that point, it would be a really big model.
Using the disc-shaped part of the ship as a wing is a cool idea. Of course, the "real" ship would not have had anything other than engine thrust to control roll, pitch, and yaw, so whatever control surfaces he had on that thing were totally bogus. For that matter, the ship was never supposed to enter the atmosphere of any planet, so its aerodynamic properties were meaningless anyway.
I lose my SBC DS1 line every time it rains. They fumble and bumble, I lose a day's work, and my CEO gets grumpy. Eventually, the water evaporates and all of a sudden, it's "No trouble found". I don't see how a strike would change anything.
"outsourced to India!"
Maybe it was. Does anyone know for sure who wrote the code?
The learning curve is pretty steep for newbies, but the features, scalability, and price are hard to beat. It's not the standard Apache/MySQL/PHP approach, but there is alot to like about it.
Warning: Zope has some religious followers that make RMS look tame by comparison. Fortunately, most of the enthusiasm is justified by what the product can actually do.
http://www.zope.org
http://www.plone.org