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