Slashdot Mirror
How Microsoft Could Embrace Linux
"He goes on to cite the governments of Paris, Munich, Brazil, Peru, China, Korea, and Japan which are all embracing open source software to varying degrees. Meanwhile, when they choose Microsoft software, fast-growing emerging markets like China and India opt for pirated copies. Salkever explains that the concerns for customers like these are the 'relatively high price of Microsoft software' and the 'concerns about buying proprietary software to run critical government operations.' Finally he points to recent moves by Sun and IBM to leave the commoditized software and hardware business behind, writing 'When the world's largest and most respected IT consultancy draws a clear bead on your crown jewels, it's time to mount a bold counterattack.'"
why not offer them a low-cost Linux version of Office?
why would any linux user use MS Office, especially when they have to pay for it?
considering heaps of people use OpenOffice.org and the like on Windows, I really don't see many people using MS Office under linux.
If people have already decided to go for a linux OS then finding a good open source office suite to go with it is no problem at all. I think the time for MS to try to gain a foothold in the linux application market was about 2 years ago and they missed it.
Why would Micro$oft make the Linux platform more appealing by creating apps for it?
They won't embrace it, because they can't extend and extinguish it as they have done for other software.
Thanks for the most part to RMS and the GNU GPL.
Votez ecolo : Chiez dans l'urne !
It lists two reasons people are moving to Linux/OpenOffice, but doesn't address either of them.
Quote: In November, 2003, the government of Brazil ordered its agencies to use Linux and other open-source software as much as possible. A month later, Israel's Commerce Ministry announced a decision to migrate to OpenOffice, an open-source desktop suite that runs on Linux and Apple's (AAPL ) OS X system, as well as on Windows. The city governments of Paris and Munich both announced their intention to switch to Linux and open-source applications. In Peru, a state legislature nearly passed a law banning the use of proprietary software by government agencies. And the governments of China, Korea, and Japan have announced an alliance to promote open-source software.
All of these organisations are switching because they don't want to use proprietary software. Providing a Linux version of MS Office won't solve this, as there's no chance in hell MS will release it as OSS.
So that's one of the concerns the article mentions, but leaves unaddressed.
Second is the price. Why would MS offer Office for Linux for a low price, when it can just offer existing products (Windows XP plus Office) for a low price, ensuring a lock-in that wouldn't occur with Office/Linux?
They only make money off of their OS and office suite. If they offered a low-cost office suite, no one would need the expensive operating system or expensive office suite. Who really wants to pay $750 for Longhorn, and then pay another few hundred for an Office suite? Then, 5 years down the road, have to upgrade again because MS stops offering bug fixes. Multiply that by 500 workstations and you have a large budget that you're basically giving MS. That probably funds upgrades to calc.exe and clock.exe.
Why read the article when I can just make up a snap judgement?
Condition variables (available under any half decent implementation of Pthreads Posix standard) give you just that kind of ability.
Granted you don't have the ability to set up asynchronous callbacks to be called when something does happen to your mutex/socket.
Before someone points out that a call to select() will tell you when data becomes available for reading, the important distinction is that in the asynchronous callback model in Win32 you get told when and don't have to hang around waiting for it to happen. Obviously you could simulate something along the same lines by having a select() in a single thread notify you (or do a callback) when data is available but in Win32 this takes almost no effort on your part.
If doing communication based software that has to actually be cross platform (and your stuck with C++ for some reason) then ACE is your saviour.
It is a bit unfair criticising the features of the Pthreads model vs the Win32 model - as with everything Microsoft they only had to make it work on one platform theirs ! Portability and real cross platform applicability does come at a cost.
The perceived frailty of MS is (a) a hangover from the Win95/98/Me crap and (b) because of the UI and application communication layers, not the kernel.
.NET and Web Services is going "so well", as it's another step down the road to hell.
What about the current inability to cancel create requests in the kernel? That's responsible for a lot of application-level hangs, without involving 3rd-party drivers. You also end up with unkillable processes - not just Unix-like zombie processes, but multi-megabyte monsters that won't go away. In such situations Shutdown is merely a wishful request, and even W2K/XP will struggle to complete it with hung applications.
And many aspects of Windows, from a developer perspective, are ahread of *nix.
Such as? I've been coding for Windows for 10 years, and I still yearn for the simpler and more powerful approach of Unix coding (which is mainly in my spare time at present). From a coder's point of view, the only thing Windows has going for it is Visual Studio, which is still much nicer than KDevelop. The new Visual Studio 2005 Beta is very sluggish, so I hope they've not ruined it.
I had the misfortune to be working on a file-system driver under Windows last year, and it's beyond a joke. Writing even a simple new filesystem requires spending thousands of dollars on the MS IFS kit, and it's far from easy from there. It's a complete spaghetti of interactions between your driver and the cache manager + OS, with many subtle pitfalls. Why else could OSR charge $50K for a driver framework kit just to aid development?? Did I mention that a file-system driver for 9x/Me is completely different from NT/W2K/XP? Now compare this to the simplicity of the VFS layer Unix, and weep...
Windows seems to go out of its way to make everything complicated, just for the sake of it. I'm pleased to see the push for
30 year old technology may be "mature", but its not always The Right Thing To Do for the future.
If it works well, why change it? As a coder I'd rather work with a tried an tested system. With Windows I seem to too much time testing on and coding round the subtle differences between different versions of Windows than , and I'm sure Longhorn is going to be yet another version to include.