Here's my thoughts/comments on the changes I made, and future directions I'll be working on....
The changes we made to efs-core are not all that radical, mostly simplifications, some of which I may have to add back to the code gong forward. For example, we change /efs/dev to /efs/stage, due to the never ending confusion about what "dev" means. We also change the "dev" stage to "test" as well, for similar reasons. The code also support krb5 ONLY, and we dropped all support for PAM-based username/password authentication. That also allowed us to rip out the SSL code, since that existed for one reason: to secure the clear test password when using PAM. We also ripped out support for /efs/home as well, and planned to deliver support for only /efs/stage and /efs/dist, and nothing more. All of that was done to optimize the use of EFS at my current consulting gig, but it was in the end a waste of time. This is yet another place where politics tumps technology, and the weight of the legacy environment bears down so heavily on the organization that virtually nothing truly strategic is being done. The place is buried alive in tactical hacks. For my next gig, there's a "global namespace" project for which EFS is a perfect fit, and the various decision makers around that project have a lot of collective experience with both VMS at Morgan Stanley and EFS at BAC (if I dropped the names, you'd recognize most of them). I expect to be adding the PAM support and /efs/home support back into the code base again, and have a long list of interesting things I intend to do to the code, if I can get the development resources I need. For example, the entire client/server architecture needs to be rethought. I want to move to a REST-based API to replace the simple TCP architecture. I am also looking to create /efs/data as a generic RW namespace, based on the very last thing I did (write the design doc) before quitting Morgan Stanley in 2005. Storage engineering at MS validated that design by implementing it, and it has been a huge success. I think it fits into /efs quite nicely. The main thing I intend to change is to tackle the local installation problem once and for all, because anyone who thinks that running apps off of NAS devices is strategic is stuck in the 20th century (and some would argue, the 1980s). I have done some simple prototype work on mechanism to install /efs/dist locally, but there's a lot more work to do there. On Windows, this is the ONLY way that EFS will ever really be useful, since Microsoft made a strategic decision, over a decade ago, to NOT support that paradigm. Running things directly out of NFS will still be supported, but the key is to figure out how to make the local installation solution scale. This is the direction that the entire industry went 10-15 years ago, and if we want EFS to be relevant in the future, it needs to go that way, too. The main value EFS offers is the versionized /efs/dist namespace, and the lifecycle management paradigm (test -> qa -> prod). If we implement a scalable, manageable mechanism for subscribing to content in that namespace and keeping it updated, then it has a future. Otherwise, it will die, because NAS is simply not exciting to anyone anymore. On Mon, Oct 20, 2014 at 9:43 AM, Steven Jenkins <[email protected]> wrote: > It's great that you've published your updates to github and made your > recent work available. I'm very interested in seeing what you've been > up to with the code. > > This is not an official response, just my perspective: I'm happy to > work with you on openefs.org, explain the fork/situation on the site, > and make both your current work, as well as the legacy work (and the > work of any others, should they make commits available publicly), > available there. As you may recall, I had suggested leveraging github > a while ago, and I still think that's a good, strategic move. On the > other hand, I don't know the complexities of unwinding from the > current hosting situation, but I can check on that. > > Feel free to reach out to me directly, and we can see what can be done > and works best for all involved. > > Thanks, > Steven > > > On Sun, Oct 19, 2014 at 11:45 AM, Phillip Moore > <[email protected]> wrote: > > This is the first email to the efs-dev mailing list in almost two years, > and > > in that time, there have been very few commits to the public git > > repositories as well. > > > > After spending the last 2 years working on major improvements to EFS for > my > > current consulting gig, I have once again re-released all of that work to > > the OSS world. However, given the complete mess that is openefs.org, > and > > the lack of a real community, I am no longer going to use that site, and > > will in fact encourage anyone interested in my code to ignore it. > > > > I've published all of my latest work on github.com, and I'm in the > process > > of moving all of the trac tickets to issues on github's system. I am > doing > > these because I am almost certainly about to start a new gig where we > will > > be using EFS as the foundation for a new global filesystem > infrastructure, > > and I'm not interested in maintaining compatibility with the "official" > (if > > that even makes any sense) openefs.org code base. > > > > I'm pretty sure BAC is still paying for openefs.org support via > OSU-OSL, and > > as far as I am concerned, that's a waste of money at this point. It is > > clear by now that BAC has no interest in the code I've written, and I > long > > ago ripped out all the EFS 2 compatibility code anyway. I am about to > make > > major changes to efsdeploy and the EFS::Perl infrastructure as well, and > > these changes will be made with no commitment to backwards compatibility, > > either. In fact, the efs-core code base already has major namespace > > changes that aren't compatible with the old environment as well. > > > > I would like to formally suggest that we decommission that site, and > > preferably free up the domainname. If I can't get openefs.org back, > I'll > > just use something else, but right now, there's really no need for a > > dedicated website for the product, since it has so few users, and no > active > > community. > > > > If there is interest in keeping openefs.org up and running, then > consider > > this an announcement that I am forking the code and going my own way. > > > > > > _______________________________________________ > > EFS-dev mailing list > > [email protected] > > http://mailman.openefs.org/mailman/listinfo/efs-dev > > > _______________________________________________ > EFS-dev mailing list > [email protected] > http://mailman.openefs.org/mailman/listinfo/efs-dev >
_______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
