Slashdot Mirror
Open Source Code Finds Way into Microsoft Release
linumax tells us eWeek is reporting that Microsoft, for the first time, has included open source code in the release of one of their products. The Complete Cluster Edition of Windows Server 2003 will be including the Message Passing Interface (MPI) library. From the article: "MPI is key middleware that was designed by a consortia of all the supercomputing vendors in the 1990s to allow the easy portability of code. It abstracts away things like low-latency interconnect, and our focus is making it super easy for ISVs to move their code."
What about doing a: $ strings ftp.exe BSD Licensed software it's open source.
>Linux is not user-friendly.
It _is_ user-friendly. It is not ignorant-friendly and idiot-friendly.
Windows has included open source code for a long time. And not just C:\windows\system32\ftp.exe (run strings to that file), why is then that several microsoft products haven been affected by zlib vulnerabilities, uh? Just read the fu***** license, it's all there.
Ralph Giles of Xiph.org did an interview, where if I remember correctly he said that Microsoft, or rather Bungie, which Microsoft owns, used Ogg in Halo 2 and Speex in Xbox Live.
I've done only initial programming in MPI for a distributed systems course I took, so keep that in mind. What I think MPI is big for is how popular it is. MPI is a very open standard, has been adopted for a long time, and is used in quite a few research projects because some implementations are heavily optimized. Some of the bonuses of MPI include the ability to make groupings and do group-messages (with all sorts of abilities to combine/redirect group messages), blocking/nonblocking sending receiving (standard really), and its pretty easy to program in. It took me about two days to get a good feel for it and start designing some built-in features the hard way for the assignment, and it worked very well.
You should also note that Wikipedia calls it the "de facto standard", which I agree with (at least from a research pov).
Yep. GPL. A cancer. A looming danger to any commercial enterprise who even uses it. Anything the GPL touches get's absorbed. Yet Microsoft's own Services for Unix has used GPLed software for years. And they've maintained their proprietary licensing and intellectual property. Huh. Odd, that.
Posting as AC to protect the guilty.
Several times I have found GPL licensed code in the proprietary system I am paid to work on. I pointed it out to management (who did understand the issue) and suggested BSD licensed alternatives.
So I am sure it happens all over the place, but more often because the person who puts the code there doesn't understand the GPL.
One junior programmer told me that this part of the GPL...
...means that you can use GPL code for anything at all as long as you don't change it. Don't ask me why. That's just what he thinks.
> I believe they obtained a special license to use
> it how they wish. So it's not an example of
> stealing code under the BSD license.
The special license *is* the BSD license. It pretty much says you're allowed to do what you want with the code, including putting it in your evil and bloated OS.
http://savingiceland.org
OK, I read TFA and they are using an open source implementation of MPI2 (MPICH2). Maybe the summary should have mentioned that... but I guess unless you're a cluster guy like me it doesn't really matter which MPI they used.
Huh? The BSD license makes no demands other than posting a copyright notice. Thats why we have BSD vs GPL license flamewars all the time.
TIBCO, according to my readings of "Enterprise Integration Patterns" (Hohpe-Woolf) is more akin to BizTalk and at a much higher level.
No, if you look closely, most of Microsoft's comments were directed at the GPL in particular (esp. the more colourful comments about it being a cancer, and communist - actually, I think that last one was courtesy of our friend Darl).
The problem with the GPL is that if you use even a few lines of GPL code, you have to release the whole thing under the GPL.. which pretty much kills any commercial work (ie. for profit) on these projects (which some will argue is a good thing).
MPI is licensed BSD, so anyone can use it for anything pretty much.. including inside a closed source program. IMHO, it's much more free (as in freedom) as you don't have the obligation, as you do with the GPL, to release your source code modifications.
I am the maverick of Slashdot
I've done quite a bit of MPI programming using the MPICH and MPICH2 implementations. MPI itself is nothing more than a specification that addresses issues with sharing memory between processors, whether they are in the same 'box' or connected through some fabric like Ethernet or some of the high-speed interconnects.
;-) ).
/.er's experience with such things.
The specification is focused mainly on the syntax of the API to make Fortran, C, C++, and Java (?Not sure if Java is actually part of the spec yet) codes compile and operate smoothly across different MPI implementations like MPICH or LAM, to name a couple (I've never run into an MPI implementation, personally, that has screwed with the standard. All my codes have always compiled and functioned cleanly across multiple implementations (after extensive debugging, of course
MPICH and MPICH2 provide many different "drivers" to allow its use over 100Mb/GigE ethernet (ch_p4), Myrinet (provided by Myricom, ch_gm), Infiniband, ccNUMA or NUMA-like systems (ch_shmem, or lock-free ch_shmemlf), and drivers for globus systems.
With interconnect fabrics like ethernet and low-latency Myrinet and IB, Message passing typically involves passing actual data between hosts across this fabric and the ch_p4, ch_gm drivers handle this transparently (this part of the setup, selecting the driver, is a function of your Administrator and not the developer). On large memory SMPs, MPI may pass addresses or references rather than the actual data, taking advantage of the fact that the hardware is designed to allow any single CPU to address any region of memory rather than flooding the memory bus with unnecessary transactions.
Take parallel video rendering for example, where we might be simply gzipping each frame... on a cluster-style interconnect, each host must have a copy of the frame it is operating on so it must be passed along the interconnect to the host before work is done (or it can be read by each host from the original file, if that file is shared across the cluster or copied to each node. This becomes very I/O bound and suffers from the slowness of hard disks). On an SMP, a pointer to the beginning of that array may be passed to the thread or process trying to do the work, while the segment of that video is stored in RAM.
Being able to share memory in such a way allows fine-grained calculations like very-large-matrix operations over slower interconnects AND SMPs (though your performance on the slower interconnects will suffer because of the bandwidth or latencies induced by the interconnect).
As well, MPICH at least, provides excellent support for debugging parallel applications through the mpirun_dbg.* commands. It uses your favorite debuggers whether they be gdb, ddd, dbx, or totalview.
MPI in a nut shell, provides for the easy creation of multiple process threads and facilitates the sharing of data between each thread to enable parallel processing regardless of how your CPUs and memory are connected. Don't know anything about TIBCO though, nor have I ever heard of it... Sorry if this was too much or too little info. I'm not really aware of the average
Some students get access to a _small_ part of the Windows OS source code at some schools. The amount of code they get to see under the "shared" source stuff is very small. Governments (even the US govt.) don't even get access to 100% of the MS OS source code through the "shared" source initiative. MS is proprietary and they don't give up their code not matter what the MS-Marketing-Machine tries to say. End of story.
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
(Also, MPICH sucks when used with multiple devices - you have to compile it with the device(s) you're using, and can only configure it for one device type at a time. So if you're planning on using a mix of Infiniband, Globus and Ethernet, forget it. It won't work.)
Probably the best MPI library out there is Open MPI, which supports the MPI2 standard, supports MPI threads and progress threads, is much more optimizable for different platforms and was developed by groups ranging from Los Alamos Laboratories (yes, the nuke place) and the LAM/MPI development team.
Ok, you have a choice between two implementations. One is slow, has a poor release cycle and has been forked numerous times (MPICH, MPICH2, MP-MPICH, Globus MPICH, GAMMA MPICH and MVICH are all forks off the same code-base). The other is partially written in assembler, is developed by a broad consortium of MPI experts and is unlikely to fork as the maintainers are really good about integrating new code. Which would you pick?
I am also concerned about Microsoft's history of "Embrace and Extend' - are they planning on breaking the MPI-2 specifications for their own purposes? I can't see any value in them doing so, but I don't see any value in 'Embrace and Extend' anyway.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
No, they can't use it legally without giving proper credit and claim it's their code.