I miss him very much ..... he seems disappeared from here for quite a long time.
I am wondering too...
I don't know for sure but sometimes people just need a break, like holidays ;).
I miss him very much too
I don't want to believe it, but someone told me dstogov was bought out by Zend and he is now working on their accelerator :-(
If someone knows otherwise, I would love to be wrong/misinformed on this.
This would be exactly what I am suspicious of. Before switching to MMCache I have used phpAccelerator on my box which was quite a fine work of Software for accelerating PHP. But then Nick Lindridge suddenly and aparently with no reason abandoned the maintenance of the project and is since then gone...
Now dstogov seems to be gone too and what is coming into my mind is Matts quotation at the phpAcccelerator-Forum: DAMN YOU Zend for ripping people off with your Accelerator (< $100/system would be reasonable) and not including accelerator functionality in PHP itself! Don't they want PHP to be faster by *default*? Compiling scripts each time takes waaay too long. :-(
Has anyone asked the php creators why they can't include some kind caching system directly to php? Or is it explained on the php site somewhere??
MMCache is a GPL'd project .... is there nobody else out there that can fill the gap left by dstogov?
Yes, thankfully this is GPL, but without a capable maintainer, this project will wither and die.
I switched to mmcache from phpa when it looked like phpa was dying. I'd hate to see the same thing happen here.
This is what the GPL is supposed to prevent, and the GPL is doing it's part, now we just need someone else to step up!
i'm thinking this would make a great slashdot story! Anybody want to try and get it written up posted?
I did find some more supporting evidence that dstogov is working for zend now (he has cvs accounts and zend email address!)
So here is a copy of my slashdot story I just submitted. Hope it gets picked up:
From the "if you can't beat your competition, buy them" dept:<br><br>
The developer/maintainer (dstogov) of the GPL'd <a href="http://turck-mmcache.sourceforge.net/">turck mmcache php accelerator</a>, that claims to be the <a href="http://turck-mmcache.sourceforge.net/#bench">fastest php accelerator</a> available, has apparently been <a href="http://www.derickrethans.nl/index.php">bought out by Zend</a> (see the right-side news column 'Godfather?'). Turck mmcache has become quite useable on production servers and is also useable on php5 beta releases. Also, the well regarded <a href="http://www.php-accelerator.co.uk/">PHP Accelerator</a> appears to have fallen into disrepair without a release in almost a year. For the non-paying crowd, the only other viable alternative is <a href="http://pecl.php.net/package/APC">APC</a>. So here is the call for a new maintainer for turck mmcache!
First Nick and now dstogov. Shame on you, Zend, THE php company! This is very much Microsoft like. How much do you share with dstogov from your whooping "starting at $1875. For pricing based on platform and CPUs contact us"? Wouldn't it be better to sell your Zend Performance Suite at a more reasonable price which the majority CAN affort if you are unwilling to include some kind of caching system directly into the php code?
I would definitely support the idea of making a great slashdot story out of it.
Well, I think the first step to "protect things" is to get at least someone willing to act as a second admin for the project, no? Right now, dstogov is the only admin, which means that unless he's willing to commit any code changes that others come up with, it will die ...
Anyone ever talk *personally* with dstogov that can get themselves added as a co-admin?
Zend's behavior is somewhat irritating, but I can't begrudge dstogov for taking the job/money from zend. Who knows how badly he needed the job?
Anyway, this is totally a guess, but I'd think that his terms of employment w/zend prohibit him from further development of mmcache. So, whoever picks up mmcache, would need to fork and start a new project.
I don't think anything needs to be 'protected'. The GPL does that for you. The only we don't have with a fork is CVS history. Everything else is right there in the source.
Last thought, I've heard APC is ok, but that it still has a few problems. If all else fails with mmcache, APC is my next choice.
Turck Software was closed two months ago, and now I realy work for Zend. I can't work without money and Zend is a good place for me, where (I belive) I can make some other good things.
In this time I have not ability to continue MMCache development.
If anyone like to do it - welcome. I can give admin or developer access to the project.
Dmitri, I totally understand your inability to continue MMCache development while you are busy with a full time job at Zend.
In this circumstance I would like to suggest that you re-license it as LGPL, BSD, PHP or whatever license is acceptable and submit it to PECL, so others can continue its development, eventually continuing you as lead if you prefer, even if you probably will not commit any work.
So, what do you think of submitting it to PECL?
It is already GPL. Is it bad? Does it conflict with PHP license?
Submitting it to PECL seems to be good idea, except that sourceforge is more friendly sandbox for side developers.
Yes, GPL is bad as it is not acceptable for projects distributed by the PHP group. The reason is that GPL software can only be linked with also GPL. LGPL is acceptable though.
as evil as I personally think that GPL is, I don't believe that whether its GPL or anything else really matters in this case ... mmcache is a standalone extension, and not something that is compiled into PHP ...
Keeping it GPL prevents it from being submitted to PECL ( http://pecl.php.net/ ) where the project could get much more visibility and interest from users and developers that can help continuing its development.
The problem with GPL is the same reason why MySQL 4+ client libraries will not be shipped with PHP distributions as it compromises the license of PHP itself.
MMCache is an extension but it does not work by itself without being linked static or dinamically to PHP itself. GPL does not permit linking with non-GPL code.
This issue has been extensively discussed and it applies to all code it PECL and PEAR too.
Congrats on the new job Dmitry.
I hope you'll enjoy working at Zend and continue contributing to the development of PHP.
I think that Dmitry Stogov no support mmcache, because he now works in Zend :-(
I download and look the source code of mmcache, but is hard task to maintain it!
Its a pity that Dmitry is quitting his work on MMCache, but I can understand that it must be hard making a living while working for free on opensource projects such as this one.
However, it would be an even greater pity if the project is now abandoned and becomes an orphan project.
I think all we can do now is hope that someone will stand up with the skills required to continue guiding and working on this project. To be honest, I have no idea how many people contributed to his project and have the knowledge required...
I understand Dmitry too.
I dont know how many people contributed to this project, I know the skill required:
1) good C programming.
2) gnu/microsoft/other C compiler.
3) OSSP mm shared memory allocation.
4) OS API expecially M$/linux.
5) Zend engine 1-2 (OP code) and source code.
6) PHP extentions and source code.
7) encrypt and fundament of chaching/optmizing.
My C\C++ expirience is available for continuing this project.
Certainly no help will be available from Dmitry!
This is a project that have annoied Zend that it has bought out him! (like M$ do)
Quote: "I have used phpAccelerator on my box which was quite a fine work of Software for accelerating PHP. But then Nick Lindridge suddenly and aparently with no reason abandoned the maintenance of the project and is since then gone"
It's certainly sad that not only has Dmitry left the project, but even worse that he moved to Zend.
Please note though that PHPA is not abandoned, although has not been updated for a while. This is in part because it works well as it is, and we've been very busy on the Encoder and other developments.
We plan to ourselves publish a bug fix / feature update to mmcache 2.4.6 and this will be available from our site. We have always considered mmcache to be an excellent piece of software, and we'd be happy to see the project continue. If we can help with this ourselves then we will.
And glad to hear you all.
Nick, I think it'll be good to see your fixes as a part of this project, not as an independent branch.
I switched from PHPA to MMcache because I don't like the way PHPA handles crashes (really, as my server load raised to 100000-300000 requests per day, PHPA becomes most of the time auto-turned off).
Currently I use mmcache-2.4.1 on production server (only for opcode cache), which works quite stable except when shm cache overfilled (see bug http://sourceforge.net/tracker/index.php?func=detail&aid=814947&group_id=69426&atid=524487\).
I tried 2.4.6, but get another problem (http://sourceforge.net/tracker/index.php?func=detail&aid=844975&group_id=69426&atid=524487) under high load, while it works good on my workstation.
Log in to post a comment.