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

I think it's the feature of the mailing list archive to create a threads of
discussion based on the subject line. So I won't change it now, even while
we're away from 'Why it's quiet' discussion.

Conrad & Dave:
> > Most users don't have always-on Internet connections.
> Today maybe. Next year, I suspect the opposite will be true.

I had. Now I don't have, and it took some to adjust (and that's the reason
I'm visiting my work place even at weekend :). What it comes to next year, I
believe I'm without net at home. Even if I'll have it, I'm very sure my
parents wont' and my guess is they won't have it for next ten years. My
point is that while the average person will get to the net more and more
it'll take quite a while before we're entering to new era where majority of
homes have 24h net. Until it, any software built requiring random access to
the net is going to be doomed (except for dedicated and enthusiastic group).

> > 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. 

Provided there's a net to use it's way easier to say

  require EnterpriseLib Version.new(2.2).or_newer

and let Ruby fetch the appropriate version and cache it to the local machine
than do it by hand. The system administration will be lessen to 

  ./configure --RPAN_autofetch='soap://intranet.enterprise.com/rpan'

so admin tasks are minimized too. He has to set up proper local rpan-site
and mirror needed parts from the world wide rpan, additionally keep up with
the proper versions of the company wide libraries.

I might envision way too far away when I set the protocol to be soap in my
example. It could, however, be even more advanced. Imagine the config param
to be 'cvs://' or 'webdav://'.

> > Many people don't want stuff changing behind their back on one
> > hand,
> 
> I'd see a URL containing a encoded version number. 

I can't see the difference of huge standard distribution and fetch-on-demand
from the 'changing behind their back' point of view. If people say 'require
lib' they're relying as much in trusted source when everything was packaged
to one big bundle or when bits and packets are fetched when needed. 

I'm sure we make the system configurable so that we could limit when things
are fecthed and the possible set of libraries to be fetched (for example to
confine Ruby to fetch only from the standard libraries of some specific Ruby
version at only during the first test run). 

Standard distro could include script fetch_very_common_libs.rb:

  require RPAN
  fetch Tk
  fetch Net
  fetch Cgi
  fetch XML
  ...

which is executed normally by saying 'make local_lib_cache test install'.
This script could be changed by hand or skipped totally.

> > So while I think dynamic updating will certainly be a nice
> > capability to have 
> Except the static approach has its own set of disadvantages. 

The biggest problem with static one is exactly what Dave mentions:

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

I tried to be silent during this discussion because there's no problem with
the current way. Now. The distro is under 800k compressed. There will be the
day when it won't fit to one old fashioned 1.44MB disk. Today I'm going to
transfer new 1.4.5 to home, by carrying the disk. I will not smile in the
future if the distro won't fit to  one disk (eliminating already the
possibility for ruby-1.4.5+all_raa_sources.tar.gz :), but that's only if I'm
still forced to use (small) disks and don't have always-on-line net :).

These days we have big drives so the size of the distros is no problem. Or
is it? Would someone like to install Word using floppies or nfs over 2400
bps modem?

From my point of view, the current distro is way too big. There's plenty of
unnecessary stuff for plain Ruby programming. I'd like to see Ruby-core,
Ruby-std-libs and Ruby-common-libs. With time, the first package is changing
hardly ever while the last gets updates probably daily.

> > 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.

Dave is so right here. Several versions won't come without doing them. I'm
really glad about his enthusiasm.

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

And now the problems with dynamic way:
- security
- early adoption

Even if things are implemented intelligently and flexibly in the first place
we'll be facing few problems. First of all, I'm quite sure there's no way we
can get the security aspects right with first try. If we will, we're
probably ending up with way too complex product. In any event, this leads to
multiple versions just like Conrad said, and that imposes the second big
problem: early adoption.

There's really great danger we'll develop a system for dynamic library
handling. Then people start to use it. To make it better, we have to develop
the second generation, the second major version. This point I really hope we
haven't catched the majority of the users yet. Because if admins have spent
time to set up anything, it'll be painful to delete working system just to
get better, more secure, working system. That's the very reason the current
internet infrastructure at companies is full of security holes. "Unnecessary
work" won't get done.

If these problems start to get bigger than I now imagined, this
'intelligently and flexibly implemented' system will make bad name for Ruby.
There's the danger.

Anyway, I don't want to picture too dark view. I think Dave's thoughts are
really good, if not yet matured :), and I'm sure we can produce something
sound provided there are persons giving critique, like Conrad and I 8-].

	- Aleksi