In reply to Michael Smith who wrote:
> Nate Williams stands accused of saying:
> > >
> > > That's all well and good, but it presents a chicken-and-egg situation
> > > for anyone trying to work outside the decades-old BSD model. You may
> > > not consider this a problem; I do. Opinions differ.
> > Yes, but anyone capable of developing a 'cool tool' with TCL that we
> > can't live w/out is capable of installing a port, and *then* showing me
> > how wonderful it is to justify bringing in TCL as part of the base
> > system.
> > Put the cart *before* the horse.
> Chicken->egg, egg->chicken? I can say that I wouldn't have undertaken
> what I have if Tcl wasn't a part of the standard system - too many people
> would say "but it needs Tcl, and I don't want to install that because ...".
Because they dont have the space ?? :)
> I figure that once it is clear that Perl is intended to be a part of the
> base system, and that it's a stable item not going anywhere, people
> should pick up and start using it.
> And the ultimate comeback is; if I'm wrong, and after 12 months nothing
> has made use of it and everybody hates it, it can go away again. At
> that point, there can be (even though there would be 8) no argument.
THAT has proven almost NEVER to happen :( it will stay and rot in a
corner if that happens.
What is really scaring is the sheer size of our repository, half a year
ago I could have the whole CVS tree plus all CTM patches and and
obj tree on one 500M disk, now only the CVS tree fits there, no CTM
patches, no obj tree. All this **** and we haven gotten any
significant new functionality :(
With this current trend, we'll all be so busy putting in/maintaining
all those *cool tools*, that no real work will be done, and stagnation
on that part is not exactly what we need.
I still vote for ripping out the old (rottet) perl, and TCL, and
then put it in ports where it belongs. I anybody does a multo graeto
tool they want us to use, they can easily get it to install those
tools from ports during thier own install, no excuse there either.
Or we should invent a system (which could be based on the current
contrib system), where its selectable if you want those tools
and the utils that *might* depend on them. This solution I could
live with, and I'm sure many of the other "purists"...
Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team
So much code to hack -- so little time.