Looking for a small fast VAX development machine

[Mouse]

> X.org has gone modular at some point and that does help -- compared
> to monolithic X servers as they used to be -- with computers which
> are not the richest in resources, [...]

I don't quite see how; I'd rather have a non-modular server for my
hardware than a modular server plus modules for my hardware.  I really
dislike the current trend to dynamically loading everything in sight;
it is a security disaster waiting to happen and it is bloat.  And the
current trend to expect the X server to run as root, even on hardware
without the peecee video disaster to excuse it, is just insane.  (For
example, on SPARCs I found the server trying to do its own sbus
enumeration, something it has no business going anywhere near,
presumably because someone thought it was a sane way to "port" code
that did PCI enumeration.)  On hardware where it works, I still use
X11R6.4p3.

But, well, if you find it helps you, whatever works.  I hold my nose
and use X.org servers on a few peecees that X11R6.4p3 doesn't support.
(I do insist on fixing the cursor extension bug, though; it's annoying.
Not that older X servers are perfect either; I found a crasher bug in
wide line drawing the hard way....)

>> But, yes, consider it a warning to look into it before just assuming
>> that the support will (a) be there and (b) be non-bitrotted.  [...]
> Honestly I'd expect dumb frame buffer support to just work, as there
> isn't much there to break or maintain.

You'd think so, but in a day when "everything" has a (by our standards)
high-end 3D rendering engine in front of it, it would not surprise me
if dumb memory-mapped framebuffer access had bitrotted.  Indeed, one of
the things I fuzzily recall is that X.org requires the device-dependent
layers to support some kind of acceleration framework (the alphabet
soup that comes to mind is "XAA", but I could be misremembering).

> A pixel array and a RAMDAC handled entirely by the kernel via generic
> calls isn't rocket science after all.

No, it isn't.  But apparently modern X has advanced enough that it can
no longer do some things X Consortium sample servers from three decades
ago could.  It's a bit like monitors: apparently flatscreen technology
has improved to the point where monitors can no longer do what CRTs
from multiple decades ago did routinely.

> So if they broke some generic parts (DIX) by the lack of due
> attention, then I'm really concerned.

I don't think they did, but AIUI their DIX code expects the DDX code to
support a bunch of cr...er, stuff, that has no relevance if you don't
have a 3D rendering engine in your hardware, which may well mean that
the dumb-framebuffer DDX implementations have been thrown away because
they no longer work with the modern DIX code and nobody stepped up to
continue twisting them into nastier and nastier pretzels to accommodate
more and more DIX-layer peecee-world assumptions....

Fortunately, old X still works as well as it ever did.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse at rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B