[ruby-talk:03747] Re: Why it's quiet -- standard distribution issues

Hi,

"Dave Thomas" wrote:
> Conrad Schneiker <[e-mail]> writes:
>
> > For those of us wanting to try out new or non-standard stuff, this would
be
> > great. However for reasons involving system administration (site
> > configuration standardization, troubleshooting, keeping everyone at the
same
> > level) in the most widespread and most run-of-the-mill environments,
this
> > would also have disadvantages. Most users don't have always-on Internet
> > connections.
>
> Today maybe. Next year, I suspect the opposite will be true.

Very wishful thinking I think. Even if so, a large fraction of users would
still be up the creek. Also there are many machines in many environments
that are deliberately kept off the net.

> > Many people don't want stuff changing behind their back on one
> > hand,
>
> I'd see a URL containing a encoded version number. And ig you think
> about it, accessing library components by some global identifier is
> really the basis of COM, and that seems to be accepted (OK, so maybe
> that's not something to aspire to, but at least it is a precedent).

Statistically I think that is a special case, not a general case.

> > and on the other hand, many of the same people don't want to be
> > dealing with pop-up dialogs asking if it's OK to fetch some random
module
> > that they are clueless about.
>
> And this would be different from Quickbooks and Microsoft Office in
> what way... ;-)

Which are the way they are because they don't want to provide a
straightforward alternative, allegedly for anti-piracy reasons. I'm not sure
following MS practices is the way to Ruby popularity. :-) Also, places that
I have previously worked at don't want people going out to the net to do
upgrades.

> > So while I think dynamic updating will certainly be a nice
> > capability to have (especially for products where Ruby is hidden
> > away internally), I don't think it will ever mitigate the many
> > practical advantages of stuff that is universally available
> > out-of-the-box for most people, under most conditions, for a long
> > time to come.
>
> Except the static approach has its own set of disadvantages.

Except that there are corresponding cases under the dynamic approach as
well, so it's not like there are more disadvantages overall. In the context
of which this thread started, I think the static approach (that includes
what 95% of average users are likely to want to use) is still the best
overall for facilitating the rapid growth and widespread use of Ruby. And
this doesn't in any way preclude a _supplemtary_ dynamic option.

> If
> there's a bug, should the naive user have to run a Makefile to install
> a newer version?

That all depends on the naive user's working environment and how serious the
bug is--there is a wide variation in these things. Most shops only update
their Perl installation every few years, since they would rather live with
bugs they know about rather than take chances with new bugs affecting
heavily used programs. Many such servers are not on the Internet. If you
don't have to mess with configure, running a make is pretty simple.

> And why should the average user download a heap of
> packages that they don't use?

Convenience. Simplicity. Pragmatism. So that many general purpose RAA
programs can depend on a fairly substantial common set of capabilities. From
their perspective they are downloading _one_ file, not a heap of packages.
There is nothing that precludes offering two static tar files, a fairly
minimalist one for fanatics and the recommended general purpose one. I doubt
the general purpose one would be more than 1 Mbyte larger, if that much.

> > Such dynamic updating developments are off in the future; and when
> > it does come, it may take several versions before it really becomes
> > suitable for general use.
>
> Exactly! And for that to happen, we need to be thinking about it now,
> talking about it next week, and hacking up some prototype
> implementations over the coming months.

But that doesn't preclude making the Ruby distribution maximally useful for
both new users and the overall Ruby community now. It's not an either-or
sort of thing.

> This is the kind of novel and useful functionality that, if
> implemented intelligently and flexibly, could make Ruby's name.

What will help most to make Ruby's name is to make it easy to use it out of
the box _now_, and without _imposing_ new constraints about continual
Internet connectivity and such. In other words, include what the
overwhelming majority of potential Ruby users are likely to want/need for
the most common platforms out of the box, and which makes sharing of common
programs maximally easy. Under such conditions (when combined with English
Ruby books), Ruby will exceptionally capable of making a name for itself.

Conrad