On Thu, Jan 13, 2011 at 3:16 PM, Phillip Moore <[email protected]> wrote: > > Well, if I was going to live within their walls, I wouldn't be trying to > build this inside of mine. > The whole point of EFS is creating a common, shared distribution > infrastructure, so you don't have to use specific mechanisms for each > product you work with. So far, it looks to me like ruby is way behind perl > with respect to this sort of scalability, but it's clearly evolving.
It might be interesting (and Ruby-like as well) to do a rubygems replacement that assumes the existence of an EFS infrastructure underneath. However, you can do much the same with Gemfiles: e.g., gem "package1", "alpha" gem "package2", "2.2.2" .... i.e, within the Gemfile specifications, the required packages and versions are already specified. The more interesting problem (i.e., multiple versions and implementations of Ruby co-existing, and sharing/not sharing gems) is where RVM is used, so I think there's space there for EFS. In other words, RVM is what the individual developer will use, but it's not-so-sharable across an enterprise where you will want to share gemsets, for example. Can you expand on what your thoughts are for a design for Ruby? > My goal is to get this all integrated so that I don't have to install puppet > locally anywhere, and can use it to manage system configuration, and a bare > minimum of software installation. Even puppet can reap huge benefits from > using EFS as a mean of deploying upgrades to the puppet infrastructure. > Also, another key point of centralized network-based software deployment is > to minimize the amount and complexity of the data you HAVE to manage local > to each node. Puppet appears to do that very well, but it can NOT solve the > myriad of problems that EFS solves by allowing independent versions to > co-exist. You are still constrained by rpm/apt-get/pkgadd and their > numerous limitations if you struggle to manage local installations of > software. One of the difficulties Puppet tackles (and problems with it, IMO) is that it does not assume a reliable network filesystem. If that assumption can change, much of the complexity can be removed. I think that would be very useful and interesting. Steven _______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
