[opensolaris-summit] Brandorr's comments on proposed Summit topics

Philip Brown phil at bolthole.com
Thu Sep 20 15:13:19 PDT 2007


On Wed, Sep 19, 2007 at 10:25:13PM -0700, Alan DuBoff wrote:
> ...
> For a long time I've hoped that we would see open source software install 
> in /usr/bin:/usr/sbin as it should, but it's not clear if Indiana will 
> take things to that extent yet. But I did sit in the session that was 
> given at IDF today in San Francisco, and I got the impression that Ian 
> could be thinking that way (and if so, I would support that thought;-).

My opinion on that, is that it should depend on "who do you call, for an
 'indiana' system, if something in /usr/bin breaks?"


There is still some fuziness in my mind, as to what indiana is.
Even if indiana is supposed to be a more "do it yourself" option, I could
still envision some situationally dependant reasons where "everything goes
in /usr/bin" may not be the best choice.

That is to say, even if Sun is not the force behind "supporting" an indiana
based install.. SOMEONE/some group/forum will be. 
For that entity, there will still be value for knowing something about what
to expect from stuff in /usr/bin.

Envision this:

Someone posts on a debian user mailing list,
"Help! my [foo] isnt working right!"

people try to help, and after much oddity and headscratching and time
spent, someone says, 
[hypothetical: this doesnt work too well if there are 2,000 files there!]

"well show us what ls -l /usr/bin looks like", 

and it is then determined that;

1. this user just "happened" to have installed some experimental version of
 grep in /usr/bin, instead of the usual debian package

2. this version of grep has some bugs or altered functionality in edge
  cases

3. This other version was what caused [foo] to not work right.

   Tens of hours have been wasted trying to track down a problem "with
   debian", when it was actually a problem with an experimental user
   dumping some alternative binary in /bin, because after all, 'everything
   goes in bin'.

If you dont set up some kind of expectation of, "dont muck with bin like
that", then messes like that will be bound to happen. 

In the case of Debian, even though I'm not aware of any explicit rule
against that sort of thing... I think the person would be lambasted for
wasting peoples time. There is some amount of expectation that
"a debian system", would have the debian version of grep installed.

In the case of Indiana... I think it would be beneficial to have some
kind of explicit statement of what to expect from /usr/bin, and what
kinds of things should be installed "elsewhere".
(and where "elsewhere" should be!)
In addition to avoiding timewasters like the above, i think it would help
to build confidence in what to expect from  "Indiana".

But, all this again depends on what exactly Indiana is supposed to be.
If it is just supposed to be "a more fluidly updated version of Solaris",
(with a nod to also making additional freeware more easily installable)
then I think the rules on what goes in /usr/bin, should be quite strict,
similar to regular Solaris. In my opinion, "non-sun-tracked" software
should still go somewhere else. 

If, on the other hand, Indiana is targetted as a more "anything goes"
environment, then perhaps not. But if it's an "anything goes" environment,
then I almost dont see the point of it.



More information about the opensolaris-summit mailing list