Re: Native X.Org: testers wanted

[Izaac <izaac%setec.org@localhost>]

On Mon, Sep 22, 2008 at 10:13:09PM +0200, Manuel Bouyer wrote:
> You seem to have a fast box where you can natively build the X system,
> that's fine. But some NetBSD ports (most ?) runs on slow hardware,
> where natively building X isn't a viable option.

Quite to the contrary, I'm most decidedly stuck in the pre-Cambrian
for hardware.  I still adore my SPARC's, m68k's, and the like.
There's even a pmax around here somewhere that I ought to just give
to someone who will enjoy it.  Anyone want a 3B2 and BLiT, for that
matter?

I do indeed find pkgsrc to be a horrible behemoth when it comes to
building nearly anything with a dependency.  But this needs to be
done only once, for binary packages are easily built and readily
available.  If one wishes to download them pre-built, they're usually
only a few directories away from binary/sets, too.  Would not
providing a binary distribution pkgsrc infrastructure via sysinst be
just as adept at providing Xorg binaries as x*.tgz sets?

But if you'd like to consider the lethargic execution on ancient
hardware as a reason not to build an Xserver natively once, why not
consider the performance /of/ an Xserver on such a system /daily/.
In such a situation, a modular Xorg with only the required libs for
building applications to hit another DISPLAY on a swifter, headed
machine starts looking alot more useful, too.

It is my sole point that because something can be done doesn't
necessarily mean it should be done.  Keeping Xorg in the src tree
requires an enormous investment in maintenance.  It has already been
tried once, with the result of atrophy and obsolescence for XFree86.
Now, the old arguments have vanished and we even have a framework for
handling third party software.  Why repeat history?

Now that I've caused plenty of strife and perhaps a little thought,
I'll disappear back into the woodwork.

-- 
. ___ ___  .   .  ___
.  \    /  |\  |\ \
.  _\_ /__ |-\ |-\ \__