openMosix Is Shutting Down 252
jd writes "Despite having one of the largest user-bases of any clustering system for Linux, openMosix is to be shut down. Top developers have left and they lack the means or motivation to continue. Their official claim of multicore CPUs making clustering redundant is somewhere between highly improbable and totally absurd, as has been pointed out elsewhere. Why is this shutdown so important? Well, from a technical standpoint, the open-source bproc (the Beowulf process migration module) is ancient, MOSIX is very hard to obtain unless you're a student, and kerrighd is (as yet) immature. From a user standpoint, openMosix is the mainstay of the Open Source clustering world and has by far the best management tools of any. The ability of this project to continue will likely have a major impact on the future of Open Source in the high-end markets — if the best of the best couldn't survive, people will be more careful about anything less."
OpenSSI (Score:5, Informative)
http://sourceforge.net/projects/ssic-linux [sourceforge.net]
Re:Uh, I think the summary misses the point of OSS (Score:5, Informative)
Its message and tone is that openMosix = dead, openMosix = OSS, therefore openMosix dying = OSS solutions are bad.
What it completely fails to address is that the situation would be no better, and in fact would be a lot worse, if this was a CSS tool. Indeed, the ray of light for openMosix users comes from the fact that it is OSS.
Bashing OSS solutions because one is dead/dying/in limbo/whichever way you want to look at it is patently ridiculous because it's not the openness of the code that's at fault here, or even the open source development model.
To put it bluntly, CSS projects that lose their core development teams don't exactly fair any better do they?
Why this IS important (Score:3, Informative)
Our networks however have not kept up to this pace. Right now our very best effort for network speed is infiniband which tops out at 96Gbps theoretical limit. The AMD Opteron page lists a limit of 24GBps, that's 192Gbps, bandwidth using three coherent hypertranport processors. See the problem?
I see one of two things happening, either we'll find a magic bullet technology to significantly increase our network speeds; or some limit will finally end Moore's law. Otherwise there's simply no reason to tie together multiple processors. Despite Windows best efforts, our CPU's still spend most of their time waiting for something to do.
Dennis Dumont
Re:OpenSSI (Score:3, Informative)
OpenSSI, however, works transparently to the userland, at least. Got a program that spawns bunches of processes? OpenSSI.
But don't get too excited. This is NOT exactly like SMP. Unlike multiple physical processors that can actually have threads of x application running on different procs, OpenSSI only migrates processes. So your super multithreaded game wont magically work better.
Well, Richard had to hawk his turtles too (Score:2, Informative)
The premise for shutting down the project is correct. Multiple cores all but eliminate the need for the most extreme clusters. Throw PCI-X graphics cards into the mix, and you have even that much more computing power. That's not to say that there aren't applications that require clustering, but, those who make those applications probably are going to wind up writing their own distributed processing framework anyway that is tailored to their needs.
Sometimes the turtles are just destined to be soup.
Probably the biggest thing that it needed (Score:3, Informative)
I see now that they have an alpha version out for 2.6.
Note that 2.6.0 was released in 2003.
a little inflammatory (Score:5, Informative)
At the time I used it it couldn't migrate web server processes or db server processes, so it was useless for what I do most of the time.
Re:orly? (Score:2, Informative)
I'm saddened by this development too. I've got a small network I've built over years of tinkering with Linux and I would have liked to explore what MOSIX and OpenMOSIX promised. I was hopeful that OpenMOSIX would release a stable branch for Linux 2.6, as that's what I prefer running on my machines. I may have even been able to contribute some after a while, but I'm no kernel hacker (Which is what's required for a project like this), so I can't even bootstrap in now.
Re:Why this IS important (Score:2, Informative)
use xcpu (Score:2, Informative)
Use, Buy, D.I.Y, or Get Over It (Score:3, Informative)
OpenMOSIX is neat, but it ain't the end all be all, and it's been my experience that any shop that's serious about running a cluster manages to find/attract someone with the chops to get it up and running. Can just any elementary school pull one together for "free"? Maybe not. For them, there's Pooch [daugerresearch.com] or AppleSeed [ucla.edu].
Re:orly? (Score:1, Informative)
http://linux.softpedia.com/get/System/Operating-S
http://linux.softpedia.com/get/System/Operating-S
http://www.mosix.org/txt_cluster.html [mosix.org]
http://www.tucows.com/software_detail.html?id=847
http://www.icewalkers.com/Linux/Software/530140/M
BTW, that's just a few. I hope they helped out. BTW, my search term in Google were "MOSIX download" without the quotation marks.
openMosix != Beowulf (Score:2, Informative)
Most Beowulf clusters run parallel codes written to use the Message_Passing_Interface (MPI) [wikipedia.org]. MPI programs really don't want to be migrated to different nodes while they're running, so load management is achived through schedulers such as Grid Engine [sunsource.net], TORQUE [clusterresources.com], and others. These schedulers avoid the need for process migration by preallocating the resources (compute nodes) in advance, and prevent the load imbalance from happening in the first place. openMosix waits for the imbalance to slow down the computation before it migrates a process to relieve the problem.
If you check the archives of the Beowulf mailing list [marc.info], you'll see that while the Beowulf community knows about openMosix, very few Beowulfers use it [marc.info].
Re:If it's really necessary... (Score:4, Informative)
The project will be shut down in March 2008, not before.
actually, it's Moshe only who will stop "leading" the project (as a reminder, he didn't really 'lead' many thing in the 2.6 version)
After march, we will see who will get the 'leader' position, but I don't think that is really an important change (call that politics if you want). The fact is for now, oM 2.6 has 3 core devs (me, risc, and g4saa) and we are quite all busy elsewhere. Anyway, if I can make interesting progress this year on the oM2.6 code, I'll take over the project.
Don't fear, oM project is not yet buried
Anyhow, if any of you guys feel like kernel/user cluster dev, please feel free to contact me (or the list directly, I'll answer it)
WE NEED MORE DEVS !! (as always anyway).
Re:Ups Grammar mistake (Score:2, Informative)
"has had clustering for ~15 years"
Re:VMS ... (Score:2, Informative)
Installing software on one system meant it was installed everywhere because all of the machines booted from the same system disk. The remote help desk consisted of a person who would occasionally deal with telecomm issues and the very rare swapout of nearly-indestructible VT-100 terminals.
In today's world, I see too many "imitation" clusters in which a single failure takes down the whole thing. It's hard to believe that Digital lost the war to Intel and Microsoft.
IT was a fabulous career choice back in the 1980's. The high cost of everything forced people to make serious commitments to vendors and [gasp!] employees who ran the data center. Today's world of disposable commodity hardware/software/people may be faster and cheaper, but the bugs and downtime would be unacceptable by 1985 standards. Here in modern times, we expect much more than 1980's IT could deliver. But we certainly don't expect with the same consistency.
Ever heard of ROCKS? (Score:3, Informative)
Also, companies like IBM and HP love to push their own proprietary setups.
As well, there are some good commercial products that add lots of well supported tools.
For example MOAB