Slashdot Mirror
openMosix Is Shutting Down
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."
someone else will pick it up.
Isn't that kind of the point of open source?
There's a similar project named 'Open Single System Image'
http://sourceforge.net/projects/ssic-linux
FTA: "Moshe Bar, openMosix founder and project leader, has announced plans to end the openMosix Project effective March 1, 2008."
Wikipedia: Moshe is founder of the company behind the Xen software, XenSource, Inc. Moshe is also founder of the company Qumranet which is behind the development of the KVM virtualization technology in the Linux kernel.
Looks like Moshe is to busy for that old fashioned mosix stuff...
Apparently the code doesn't count, only spurious logic about changing hardware factors. Oh, and apparently the sun does, in fact, set.
But how cool a name is Moshe Bar?
The secret to creativity is knowing how to hide your sources. -- Albert Einstein
From the summary it seems that the people who've contributed most to the openMosix code have moved on to other things.
Well, that happens. People's lives don't stand still, they change: they take on other commitments at work, have relationships, travel the world, etc.
But that doesn't mean that openMosix is dead.
On the contrary. This is open source software.
The code isn't lost. Others can pick up the slack and join the effort as they see fit. openMosix can still move forward, perhaps not at the same pace as before, but forward nevertheless.
It seems to me that the summary misses the point of OSS. If this was a closed source project and the lead developers had walked away then, yes, openMosix would almost certainly be dead and buried.
But, unless I'm missing something huge this isn't the end of the line for openMosix, precisely because it is open source.
It hardly seems appropriate to look at this as a failing of OSS development. On the contrary, it's arguably an example of one of its strengths.
This a baton change not a retirement. At best, the new holder(s) of the baton will soon hit the same stride as the previous holder(s). At worst, the baton has fallen to the ground and it simply needs to be picked up.
"Accept that some days you are the pigeon, and some days you are the statue." - David Brent, Wernham Hogg
Yeah, but how likely or realistic is it that the few people in the world who understand, in this case, clustering, to such an extent, will choose to work on this project? The vast majority of software developers want to get paid for their work.
In theory, you're right. It'll continue. But will reality live up to theory? Only time will tell.
I don't respond to AC's.
What a ghastly overreaction, but hey, this is slashdot.
Best of the best? I may get flamed for this, but I'd barely heard of OpenMosix.
When Apache, the Linux kernel, Eclipse and (name a popular GNU project) look like "shutting down", then maybe we can bleat about the failure of open source.
And as some have said, there's not real reason the baton can't be passed on to interested new parties.
I agree, there's a degree of optimism in my argument but the summary is plain flawed.
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?
"Accept that some days you are the pigeon, and some days you are the statue." - David Brent, Wernham Hogg
The pendulum has swung back now. In the days when 10Mbps ethernet came onto the scene and our processors could barely keep up with their floopy drives (which is why a floppy used DMA), we collectively came up with the idea of using several computers to solve a problem by splitting the problem up among them. Since then thanks to Moore's law our processors now spend a lot of time waiting to fetch the next instruction from their on-chip L1 cache - as in when there's a miscalculation in the branch prediction step.
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
Wrong.
.NET and get experience with that environment, as now that MS has declared foxpro dead, they aren't ever expecting to get another foxpro job. The only alternative left to companies with "legacy" foxpro code is to completely re-write any application in that language in a different one (not a small task).
MS regularly end of lifes things. Just recently the EOL'd foxpro. Sure its a crap language and a crap environment, but I know 5 people personally who are frantically trying to teach themselves
You can still get the openMosix code, if you had openMosix experts you could still fix things and move forward. If you have an existing system on openMosix you can look for a different solution and move to it or keep your system on the existing code. I really don't see how this is any different than MS calling for an EOL of Windows NT. When they do that you are forced to invest tons of hours and money buying new systems, developing a migration plan, deploying the new system, training users on it... It is no different in Open source or closed source, when vendors decide they aren't supporting you anymore, it costs you money.
Vendors regularly leave users out in the cold, both closed source and open. Only difference is, if a company wanted to pick up openMosix they certainly could. They could provide support, ongoing development, whatever. When MS EOLs something, your only choice is to take whatever MS gives you.
I have been following openMosix for many years and, to be honest, the development team was never much good. OpenMosix worked best shortly after it was forked from Mosix, and it was down-hill ever since - about 10 years now! The latest stuff for the 2.6 kernel never worked at all. That said, this cluster-level kernel-hacking is probably just too hard to do right, unless you were to start from the ground-up. Plan9 anyone?
The article summary was certainly an eye grabber... but, the truth is, I've deployed quite a few linux HA and load balancing clusters. I have also installed a couple openMosix clusters. While it may be sad that openMosix is closing, the vast majority of clustering cannot be handled by openMosix. It is designed as a parallel processing cluster. I would say 99% of clusters are of the HA/load balancing variety. IE, I've got 3 web servers and I want to distribute the load between them. openMosix cannot do this, it isn't designed for it. Or I have 5 DB servers and I want to distribute load/perform replication. again openMosix does not do this. It is a "processing" cluster. IE I have this huge data set, and an application which will split up that data set and do some processing on it. Think SETI@home except, you don't want to send it to people's homes, you just want to run a single process which will send jobs off to other nodes for computing. The only thing I ever successfully used openMosix for was a compile cluster, and for that it was nice, but even for regularly compiling KDE, it wasn't much worth the effort to get the cluster running for the time it saved in compiling.
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.
As usual, people are posting replies without any clue about the actual situation (or at least the claims of important people involved)
See http://mulix.livejournal.com/199931.html
"Now the real project can get the credit it deserves. I hate it when people steal credit. It was so annoying to read interviews where it was claimed that behind openMosix are years of research, when all this research was actually behind MOSIX."
They'd look down on it like a typical C++ developer looks down on HTML or Visual Basic development.
Yes, I'm sure they'd look down on a very well paying job that was far far less stressful.
Everything I need to know I learned by killing smart people and eating their brains.
and they lack the means or motivation to continue
See what happens when you *stop* imagining a Beowulf Cluster?
Table-ized A.I.
Some utility bits of open source of course do not need a lot of maintaining and reach full maturity pretty early and only require the odd tweak for hardware compatibility, for those projects maintaining a team is difficult, logically speaking those projects get pick up and carried by another open source project that can run them as a side line.
Chaos - everything, everywhere, everywhen
Since when was writing C++ code stressful? Surely if anything, writing VB code is stressful?!?!
Basically what we (the community) has figured out is that SSI featuresets should not be implemeneted in the OS layer, but below it. Look at the SGI Altix technology. Or large Unisys machines. Or that hyper-transport happy monstrosity that Cray is building. They have special low-level firmwares running on the I/O processors that are doing in low latency, tuned hardware what *Mosix was trying to do from Ring 0 on the nodes.
Using various ISA interfaces (MPI in the low end, or Hypervisor abstractions like Xen, etc. etc.) you can run many guest OSs in the space as needs require, and localize the shared-memory-ness as required to get maximum threading benefit with the lowest total latency you can tolerate. All this with minimally modified guest OSs in which to run the code. This is a much better situation then heavily modified kernels pretending to be a single system image (and then having to worry about forking/threading/VFS issues and propogation of that stuff).
On the flip side, grid technology and speciality message-passing libraries fill out the feature set for more embarassingly parallel problems that need lots of CPU and RAM... you have the luxury of spending time and money coding your applications for that environment if you are CPU limited.
Mosix doesn't have much use anymore as a general purpose product. Either it's too heavy-weight (and drowning in syncro overhead) and we should be relying on firmware/hypervisors that are customized for the hardware, or it's not necessary because we can handle the load balancing at a higher level.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Depends on the VB project. A lot of places that actually want it done in VB just don't have someone around who codes and want something worked on. Unless it's a rat's nest, it's usually not so bad, and at $130/hour, I'm sure you could cope.
Besides, the person I initially replied to was of the opinion that nobody who could do the sort of work that openMosix requires would deign to "dumb himself down" (figuratively speaking) to writing c#/.net code even if it was netting the guy $130/hr. Personally, I call BS. After a while, you learn that you work to live instead of living to work.
Everything I need to know I learned by killing smart people and eating their brains.
The really good hackers:
a. don't want their minds and skills to rot
b. get bored by the easy stuff
c. are not stressed by difficult hacking (stress comes from office politics)
d. like to be admired for their ability to do the difficult stuff
e. like to be in the company of peers who can do the difficult stuff
You might get a great hacker doing lame stuff, but you'd have to pay him much MORE than you'd have to pay him to do the difficult stuff. The extra pay would compensate for the extra boredom. Since you can get a warm body for much less money, you're unlikly to hire the great hacker.
Since C#/.net is very lame compared to the challenges of something like OpenMosix, we can pretty reliably conclude that the supposed hacker is not really qualified to hack on OpenMosix. (alternate theory: his dad is the CEO and so the pay is quite absurd for the job being done)
Let me explain the reason for their decision in a sane way as I see it.
*MOSIX was supposed to provide an EASY way of doing clustered worth. Low over head in terms of coding and administration. It was aimed at MODERATE clusters not massive beasts as it lacked performance/efficiency. While two extra machines may be worth the lower overhead two hundred probably are not so the immense clusters used other methods.
Advanced in computing, multiple cores and so on, have killed this low-to-medium cluster market NOT clustering as a whole.
Yes there are tons of things that still need clustering, think web data for example for a new one, but they are large and even larger. They need performance and so *MOSIX is not what they are looking for.
In other words the market for *MOSIX is effectively dead thus the project is joining it.
Let me let you in on a little secret. Even the best people eventually realize that there's more to life than working no matter how "cool" you think what they're working on is. They look at their lives and realize that living to work is a bad idea because life is for actually living.
For a lot of people, that happens about the time they have their first kid. For others, it happens sooner. Yet others experience it later, to the detriment of their families if they have them.
I also have to tell you that it's not uncommon for a good independant contractor to be paid more than $130/hour because most consulting companies bill out their contractors at that much or more. Honestly speaking, my top hourly rate thus far has been more than $130/hr.
You may learn that your ideal of the "great hacker" is rather off the mark some day. The truth is that the really good people often don't care about how great others think they are. They get things done, and move on with what they have to do.
Everything I need to know I learned by killing smart people and eating their brains.
You start the project in the first place because you have a unique solution to a given real-world problem.
... but that would never have been apparent if it wasnt tried.
.. but at da club, its not working out that way. Thankfully, we can toss the lime green shirt and try something different, because we are non-commercial.
.. are looking at the story with their commerically-oriented-hat on. If that is you, then you shouldnt be working in science or computers - you should be out selling mobile phone ringtones, Celine Dion records, yo-yo's, insurance, timeshare condo plans, roller skates, lottery tickets, etc, etc, etc. If that is you, then you deserve to end up with the fat'n'ugly chick in the lime green shirt, simply because the advertising banners plastered all over the wall TOLD you she was the best choice.
Others may have different solutions to the same problem, and you are all free to attack it in your own way. In a totally free environment, you can determine the best solution to the problem using proof-by-mindshare.
As time moves on, the landscape changes, and some/none/all of your assumptions about the problem domain that drive your solution get challenged.
If it appears that your solution is no longer relevant, and that other methods work better in the real world, then your project can successfully conclude, and you can move on to the next big thing. In this case, OpenMosix can see that it's solution to the problem is not the ideal way to go, as evidenced by the fact that MPI, load balancers, (insert other solutions), tend to be more applicable to most real world problems
In a way, an open source software development is a test of a hypothesis. You dont measure success just by proving the hypothesis - you can also disprove it (or spawn a new one), and still claim success.
If this had been a commercial / proprietry project, then everything would be different - there would be egos and money on the line, so the motivations for doing the project in the first place are very very different. If OpenMosix was commercial, higher ups in the company would be moving the goalposts to suit themselves, spending money on advertising and kickbacks, and putting effort into forcing it into sitations where it wasnt the ideal answer. The resultant mindshare and marketshare in a commercially driven enviroment yields sub-optimal solutions - its based on which solution has the best political backing and advertising budget, not the one that best fits the problem.
See, its like this - to an opensource mindset, the hottest person in da club is the one that gets _given_ the most phone numbers. To a non-opensource mindset, the hottest person in da club is the one who can _buy_ the most phone numbers. Someone thought that the flouro lime green shirt might be a good idea
The sort of people who read the headline of the story and see it as a bad thing, a negative thing, an anti-FLOSS thing
Thank goodness open source allows a project to go from conception to conclusion for all the right reasons.
So here's a personal anecdote: Microsoft, Inc. held a free training session/love-in for devs and wannabee devs at a vacated movie theater in Bellevue, WA. It was ~2003 and I was one of the wannbee-devs-in training in the audience. Bellevue is maybe five miles from the "promised land" of Microsoft's RedWest campus and One Microsoft Way and MSFT managers were supervising the proceedings. I recall some discussion of extending Office 2003, some interesting demos of Visual Studio, and a lovely parting gift of an Intel webcam, which I still have. (thanks, guys!)
An older grizzled bearded guy stands up during one of the Q&A's, his voice tinged with injury: "...but what plans do you have for FoxPro?! Some of us spent a lot of time building these skills." Answer from a Microsoft PM presenting in front of his colleagues and managers: ~"I don't think there are specific plans, and it's very unclear whether that product will be developed further." Followup: "[insert whining here]". Answer to the followup: ~"I've tried to give you a pretty honest answer about where VFP is going, and my suggestion would be to look at growing your skills with .NET if you're interested in developing for MSFT platforms."
I'm not sure how much clearer it gets than that. The writing has been on the wall for VFP for years and years now, and you would have to be borderline negligent as a dev not to realize that. A benefit of playing with proprietary frameworks is that the corporations that own them tend to be pretty up-front about their future. Around 2002 I was learning faux-OO VBScript/ASP (lol), but I quickly recognized that path was a dead end. Developers cannot afford to fall asleep at the switch. Anyone who was surprised by the death of ASP or FoxPro wasn't at all serious to begin with.
Since C#/.net is very lame compared to the challenges of something like OpenMosix
Excuse me? So you're saying that the language dictates how "complex" the language is dictates how fun a project in the given language can be?
I certainly think it is likely that OpenMosix presents a lot of interesting technical challenges that any good developer would love to get his hands on, but a complex business system in c#(or java for that matter) present a DIFFERENT kind of interesting technical challenges!
any enterprises relying on openMosix to run their operations are in a pretty bad spot right now, i agree. their enterprise quality support has evaporated.
of course, this would be a completely different story if it were a close-source program they were relying on... because... ?
companies go out of business, too. and when their close-source programs are no longer supported, *no one* has the ability to pick up where they left off.
openMosix was doomed to fail like this at some point. Countless academic projects attempt to improve Linux for their specific needs in the wrong way. They release their work as patches never intended to merge with the kernel, or fork the kernel and never merge again. Over time you can guess what happens -- it becomes impossible to cope with the rate of change that others force on you, and the grant budget never considered ongoing maintenance costs, so the the patches become worthless, or the kernel fork unmaintained. So now Moshe is in deep, and nobody else wants to touch it.
I Browse at +4 Flamebait
Open Source Sysadmin