Hi Jyri. Thanks for the cookbook suggestion. I'll probably be writing something up on this too and putting it on my blog or somewhere else, with a focus on NetBeans.
I understand that Solaris goes to not just developer laptops. But a focus right now is to attract developers. So we should find a way where that use case is not damaged due to the other use cases. One thought I've had is we should have an RBAC profile called "Developer" or "Web Developer" which has all the rights needed to get their job done. I also like what OSX does, where if you do try to do something privileged, instead of saying "no", it just asks you for the password. gksu seems to fit the bill here, and maybe we can make use that. Thanks, David Jyri Virkki wrote: > David Van Couvering wrote: >> http://wiki.rubyonrails.org/rails/pages/HowToUseMultipleGemRepositories >> >> This page says that to set this up you need to do the following: > [...] >> If this really is the way we want to go, then we need to find a way to >> automate this. Having to follow this kind of cookbook just to get >> started seems like a definite way to prevent people from getting going >> with Ruby in Solaris. > > A cookbook tailored specifically to OpenSolaris would be a nice first step. > > Prashant, can your team come up with a short writeup on getting it working > as easily as possible using current snv_b79 as the base? > > Next step would be to provide some automation. Perhaps the ruby > package should include a script/tool that sets everything up > automatically the user who runs it. > > >> Note that all of these situations deal with machines where there are >> multiple users and you either want to control access to the system >> repository or manage potential collisions. >> >> But in the standard developer's laptop, there is only *one* person. > > But Solaris doesn't only install on personal laptops. It also installs > on E25K's and everything else in between, in most of which cases there > are many users and meaningful security requirements. There's only one > SUNWruby package and it's the same one that gets installed on a > personal laptop and on the big iron production server and on the > shared ISP server hosting hundreds of untrusted users and .. so forth. > > That's what makes it challenging. We need to find ways to make the > initial developer experience as convenient as possible without making > the system unsuitable for other uses. Some web stack components (like > apache) deliver RBAC rights profiles which can be assigned to the > desired users. Ruby doesn't today do anything special along these > lines, though suggestions (or diffs ;-) are always welcome. > > > With IPS and distro constructor coming up, there are some new ways to > have more targeted setups for specific audiences, which will be good > to explore next year! Even then, it'll be unlikely to have packages > that deliver insecure content (such as world writable systems dirs). > >
