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 !
Why is it that an editor of BusinessWeek has no clue about business? If Microsoft embraced Linux by selling a low cost version of Office for it, migrating to Linux would be even easier --> no money for Windows, less money for Office.
With no MS Office for Linux, migrating is a lot harder. OOo works fine for most people (better in my experience, but my experience probably differs), but in some cases you just simply need the original, which means you also need Windows (or Crossover Office).
It really is as simple as that. Office isn't just MS's biggest cash cow, it's also their most important selection of proprietary file formats.
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?
It would be nice but I think there is too much speaking against it.
First of all I don't think it would be an easy port to make considering how M$likes to intermingle it's OS with it's applications. Office is bound to be using alot of OS specific API's, com objects etc... If the main selling opportunity would be low priced copies to the third world, then maybe they don't think it is worth the cost.
Thirdly I think it would be to much an admittance of defeat for M$ to aknowledge Linux that way.
Congrats on the new section, but the color scheme is killing my eyes.
Color scheme looks okay to me, nowhere near as bad as the Games ones but I'm wondering whether they really have enough Italian readers to justify a special 'it' section.
The real Ralph Yarro posts as Anonymous Coward. Anyone else is an impostor.
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?
Thank you for displaying your profound lack of knowledge of MS operating systems.
The kernel behind Windows 2000/2003 is as solid as Linux. Crashes are almost without exception the result of third party device drivers. 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.
As a developer I get to see the side of Windows and Linux that many don't -- low level interfaces to system functionality. And many aspects of Windows, from a developer perspective, are ahread of *nix.
The Win32 threading and synchronisation models are ridiculously powerful compared to *nix, which is precisely what makes it so hard to port a lot of Win32-based software to other platforms. The fact that you can't do a simple operation like "wait for a mutex to be released or a socket to become readable" deserves to be a joke about legacy operating systems, not a persistent reality. At least BSD's kqueue comes close.
There are many other places in which the *nix kernels show their age compared to the design of Win32 (not to mention MS's ability to maintain a consistent API over 10 years of product developments). 30 year old technology may be "mature", but its not always The Right Thing To Do for the future.
So try to get the facts before you succumb to FUD about the state of computing -- from MS or FLOSS.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
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.
Win32 has blocking, non-blocking and asynchronous modes of IO. But where it really shines is the integration between IO and scheduling (from a developer perspective).
The call WaitForMultipleObjects allows you to wait on any number of objects, for any or all of them to be signalled. Each object can be a thread, an IO resource (file, socket, pipe), a synchronisation primitive (mutex, event, semaphore), etc.
The other point of integration is Completion Ports. You can provide worker threads and asynchronous callback functions (to be invoked in the worker threads) to any IO operation.
POSIX AIO provides most of the functionality (with regard to IO) that one can desire (Completion ports are cute and offer a lot of potential for performance, but you can do an equivalent job with kqueue/poll/devpoll and/or aio). But POSIX AIO doesn't offer developers control over the integration between the scheduler and IO.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
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.
What's interesting to note however...
The kernel that you talk about, was mostly stolen from DEC..
The UI and application layers were microsoft's own code bolted on top...
The original kernel was a microkernel architecture where device drivers shouldn't have been able to drop the whole system, microsoft screwed that up by allowing drivers to be loaded into kernel space.
The stable parts of windows were stolen, the unstable parts were their own code.. Tells you something about the quality of their development process. The same thing applies to a lot of their other products, the more stable ones were bought/stolen from elsewhere.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
wait for a mutex to be released or a socket to become readable
And there speaks a programmer who has been ill educated by the MSWindows environment. There are dozens of events that a program may need to wait on, everything from mutexes to sockets to GUI callbacks to USB events to power fails to signals to virtual memory events to whatever. To have a special call to wait on only two of them is stupid, precisely the sort of nonsense you expect to see in the MSWindows environment, rather than consistently solving the general problem with powerful, general purpose tools like threads and asynchronous IO. Related to the above, programmers who like the MSWindows kitchen sink API frequently have a poor idea of what a race condition is and how to avoid them, a large part of why MSWindows and MSWindows applications are so flaky. The Unix/Linux API isn't particularly clean either but it's a lot cleaner architecturally.
---
It's wrong that an intellectual property creator should not be rewarded for their work.
It's equally wrong that an IP creator should be rewarded too many times for the one piece of work, for exactly the same reasons.
Reform IP law and stop the M$/RIAA abuse.
The Win32 threading and synchronisation models are ridiculously powerful compared to *nix, which is precisely what makes it so hard to port a lot of Win32-based software to other platforms. The fact that you can't do a simple operation like "wait for a mutex to be released or a socket to become readable" deserves to be a joke about legacy operating systems, not a persistent reality. At least BSD's kqueue comes close.
If that is true, then it's a shame that the performance of the Win32 sockets are so meagre compared to the Linux implementation. Take a look at this article on Developerworks. Maybe you can spot the changes required to close the performance gap between Windows and Linux (Linux running about 2 and a half times faster on the same machine).
And I think I'll take you to task for your blind assertion that "you can't do a simple operation like "wait for a mutex to be released or a socket to become readable" on a Unix platform. If you call pthread_mutex_lock in 'fast' mode it simply waits for the mutex to be released and will pick up as soon as the mutex becomes available. And there are plenty of other options around. It's also totally trivial to write a spin-check to check the TCP status of a socket.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.