How Microsoft Could Embrace Linux

securitas writes "In a commentary and analysis piece, BusinessWeek technology editor Alex Salkever discusses how Microsoft can embrace Linux, and asks the question, 'Considering Redmond's slim odds of conquering developing nations, why not offer them a low-cost Linux version of Office?' Salkever explains that 'Microsoft faces increasing competition in both PC operating systems and in desktop applications' which are its core businesses, while corporate customers would likely adopt Microsoft Linux products." (Read more below.)

"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.'"

Comments

Re:Office for Linux? who'd use it?

[julesh]

It _would_ help persuade management to switch. "Can we still use Word?" "Yes."

Of course, this ignores (a) the existence of Crossover Office, which I understand is capable of running Word virtually flawlessly, and (b) the fact that MS wouldn't do it because they know that they'd lose -- the number of people switching to Linux because of the availability of office would cut directly into their Windows revenues, and probably into some of their other application-based revenues also.

Re:Office for Linux? who'd use it?

[meringuoid]

I have a whole lot of VBA written in Office. I could redo it all in OOo, but it's probably not worth my time if Microsoft's price for Linux Office is reasonable.

From what I heard, it's Office that's the real cash cow anyway, not Windows. Why shouldn't they?

M$ on linux

[Sarastrobert]

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.

Re:Office for Linux? who'd use it?

[hendridm]

Their whole system is built around integration - the more Microsoft you use, the more "pleasant" it's supposed to be. Exchange with Active Directory and SQL Back End, IIS for the web server, etc. If they make their products interoperate with competitor's technologies, they lose this sales tool.

We ran into this problem when we were looking to buy a new web server. The director actualyl gave me a choice on what was loaded on it. Although my last employer was a Linux shop, this place is Microsoft/Novell. As much as I love all things Linux on the server, we eventually decided to put Windows on it because a) we didn't want a third environment (Windows, Novell, Linux), b) most of our department expertise is Windows/Novell, c) Many of our apps are written in ASP, and although it wouldn't have been out of the question to rewrite them or use an emulator in the short term, it was a drawback.

I wouldn't doubt, however, that the major reason our director (is generally against free software) was okay with Linux is because Novell is backing it now, which is a good thing.

Re:If MS were not so proud...

[Twylite]

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.

Re:If MS were not so proud...

[bit01]

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.

Of sockets, mutex and performance

[tjwhaynes]

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