On Wed, Feb 20, 2002 at 07:31:57PM -0600, Richard Rauch wrote:
> 
> Someone, I thought, was suggesting that we have something like KDE bundled
> with the system.  That effectively means either hiding the nice pkgsrc
> system behind some new interface, or replacing the package system
> entirely.  (I assumed that some kind of interface was what was in mind.
> But in any case, it seems to be a matter of fixing something that isn't
> broken.)  Even if you just layer a new interface over the existing one,
> I don't see the point, except to do something similar to meta-packages for
> easy selection of large sets of packages.  So why not just add
> meta-packages?

I like the meta-packages idea; I've not used any of them myself, but one
"package" that really just throws in a bunch of others sounds like it should
save a good bit of effort on the user end.

> (Well, it *is* a little broken re. shared libraries, last I updated
> pkgsrc.  I don't know if there's a sane way to fix it.  People have
> assured me that the nature of shared libraries means that we can never
> have sane upgrades.  I miss my Amiga, where you could just drop in a new
> shared library and it would just work.  It didn't matter if the library
> was commercial or not; people just didn't break their API's in general.
> This was virtually guaranteed because the normal behavior is to add a new
> entry point if the old interface turns out to be unsatisfactory.  I
> thought that the UNIX shared library major version numbers were supposed
> to be an author's guarantee that the API is keeping backwards-compatible
> to the same major version, but apparently that is either wrong, or isn't
> actually done in practice.)

I'd love shared libraries that "just worked" like you describe on Amiga, but
in all my experience on Linux, FreeBSD, NetBSD, Solaris.. I've never seen it
happen. I've seen some shared libraries go  in better than others, that's
about it.

> > > (And if it's not point-and-click, or doesn't offer the user choices and
> > > flexibility, then I *really* don't see the point of not just using
> > > pkgsrc.)
> > >
> >
> > Whats wrong with a nice interface for pkgsrc? It could be part of the same
> 
> Nothing.  And we've got one.  (^&  ``cd /usr/pkgsrc/graphics; ls; cd
> <foo>; cat DESCR; <ponder>; make update''.
> 
> That the database is accessed with standard filesystem operations is not a
> liability, IMHO.  What particular features would you like to see that
> don't come as a natural result of having everything in a filesystem?

What I mean is a single program with menus, etc, for selecting what packages
you want. I haven't used FreeBSD's sysinstall much for installing packages,
but I have used it, and I like how straightforward it is. I think it would
be easier on the newcomer to NetBSD, and perhaps on the NetBSD veteran who
is feeling lazy ;)

> > thing I was just talking about (something-ala-sysinstall) and maybe just a
> > "build from source" option instead of install from binary pkg.
> 
> Um, we do have a ``build from source option''.  It's called pkgsrc.  What
> am I missing here?  (I haven't used binary packages in a long time.  I got
> burned by out of synch. versions that left me unable to install certain
> combinations of packages.  I think that things are a bit better now, but I
> also prefer to have compiled-in defaults set according to my preference
> rather than according to some binary-package-maintainer's preference.)

What I meant was along the lines of FreeBSD's sysinstall, where you select a
(binary, invariably) package you want, and it downloads it and adds it. A
binary packages menu and a built-from-pkgsrc menu would be handy, I think.
Sometimes binary packages are a better idea, for example really slow
machines, but generally (at least IMHO) building it from pkgsrc is the best
way.

>  [...]
> > > Unless XFree86 4.x now supports *all* hardware supported by 3.x, I'm not
>  [...]
> > Hmm. I was under the impression that 4.x did support everything 3.x did.
> 
> Last I heard, there were certain cards that they did not yet support (and
> I got the impression that there was no hurry to round them all out).
> Maybe that's changed in 4.2?

Oh, I'm not really sure there. It seems to me that 4.x has support for a lot
more of the newer cards, I had (incorrectly?) assumed that 4.x was more or
less built on 3.x and had everything 3.x did.

> > And as for newer cards, my Riva TNT2 wasn't by any means expensive, and it
> > performed like absolute crap in 3.x but flies in 4.x.
> 
> I'm not sure how the Riva compares; I had the impression that it was
> considered a pretty good card about 3 or 4 years ago, though.  The card
> that I use in my main system is an STB Nitro 3D.  Although it has some 3D
> features, I never heard them touted much; about 4 years ago, it could be
> found in the low end of what retail stores offered, for about $40.  I
> assume that it's pretty anemic, but it works nicely for what I need from
> it.

The model I have, Riva TNT2 Vanta, is the cheapo model of the TNT2 as far as
I know, AGP with 8mb of ram. I love mine, it does 1280x1024x24bit at 85hz
very nicely on my viewsonic monitor, and most everything graphics-oriented
is a lot faster for me on 4.x versus 3.x.

I also really like 4.x's autoconfiguration ability. xf86cfg comes up with
the exact refresh rates and stuff I need for the best res with my monitor
and video card, I just have to decide which res and color depth I want. I
couldn't do that in 3.3.6: I had to manually enter a lot of data on clocks
and vert/horiz frequencies to get the resolution where I wanted it.

-Sean

-- 
/~\ The ASCII                         Sean Davis
\ / Ribbon Campaign                    aka dive
 X  Against HTML
/ \ Email!               http://eros.endersgame.net:8000/~dive