Re: [tlug] Printers for linux, was: refurbished Thinkpad X60 with Coreboot & Linux

["Stephen J. Turnbull" <stephen@example.com>]

Benjamin Tayehanpour writes:

 > Do you have any tips on recommended reading if I want to know more
 > about why X is the way it is?

Heh.  As old as I am, that's still before my time.  The X protocol
itself took more or less its current form by late 1987 with the
release of X11R2 (there was no public X11R1 release).  X11R4 (the
first version I came into contact with) was out at the end of 1989.
X11R5 was late 1991, at which point Xlib was fully internationalized.

I don't know where you'd find the politics (it was a huge academic/
industrial consortium, after all), but O'Reilly's The X Window System
does provide a lot of the rationale.  I guess on the Web I'd start
with Wikipedia's "X Window System" page, and then from there the
chapter on "X-Windows" from The Unix-Haters Handbook.
http://web.mit.edu/~simsong/www/ugh.pdf

Also, a lot of things that today would "obviously" be primitives
(specifically, Porter/Duff compositing[1] technology) in 1985 were
closely held secrets of folks like Tom Duff at LucasFilm.  (Note that
Wayland describes itself as a protocol for communicating with a
compositor, not as a protocol for driving a console.)

 > Wayland seems to be the only "X-killer" project which is actually
 > going places. At least as far as I know. First off, the alternatives
 > are few to begin with;

Note that actually none of these are really "X killers", in the sense
that none of them define a rendering wire protocol AIUI -- I haven't
looked very closely though.  So for the foreseeable future, at least
for the projects I've looked at, X is going to be the portable
rendering protocol for clients that don't need super-high-performance
graphics.

So, for example, Wayland basically seems to be a way to give the
window manager (Wayland compositor) finer control over what goes on
the screen (including grabbing the root window and turning it into a
surface composited into the actual display!), while getting the window
manager/compositor out of the data path when direct rendering is
possible.

How that is going to be done when using transparent or translucent
windows is beyond me.  There's a comment on the Wayland site to the
effect that when using a rotating cube effect while changing users --
and therefore for security reasons, X servers -- the X screen is
copied to a buffer in Wayland and transformed appropriately.  I would
assume that translucent windows would have to be handled the same way.
So I kinda suspect that Wayland displays will end up being either flat
or slow -- just like X. :-)

What all of these projects seem to be aiming at is giving games and
eye candy a standard way to access direct rendering functionality.  In
theory, there could be a standard rendering protocol (eg, cairo[2])
without going through the X server.  Wayland doesn't give you that,
instead you have to go relatively low-level with *GL -- or stay
portable but relatively low-level with X.  I'm not sure what Mir does,
but I think it opens the door to low-level rendering protocols.

So as I said to Edward, I see fragmentation happening here.  Maybe
that's a good thing, if it means development can move forward fast
enough for Ubuntu to muscle up to the handheld trough, and compete
with Microsoft, Apple, and Google.

 > > [I] just want to type \nopagebreak and get on with [my] life!
 > 
 > You're preaching to the choir. :-)

Yeah, I know.  But there is a big constituency for "if we could just
make Linux more popular...".  People seem to think that means copying
Microsoft's successes (as horrible as I think Word is, in the market
it's a success).  As a response to that, "you're looking in the wrong
place" (ie, everywhere but on smartphones) was dead on, but to the
extent that we're free software advocates[3], that kind of success isn't
good enough.  IMHO YMMV TINLA YHBT HAND (or something like that :-).

 > I just wish I could *get* TeX.

Ah, well, TeX is hard.  I'm really interested to see what Simon has to
say about this, but since I'm not going to have time to be in "TeX-
killer" space for a while, I'll just wing it here.

You need to remember that TeX was written by a single brilliant mind
in the early 1980s, and like Emacs and Ghostscript, it bears the stamp
of its author's personality.  Like Emacs and Ghostscript, it bears the
burden of an idiosyncratic language.  At least Emacs Lisp really is a
Lisp, even if it's one of the suckiest surviving members of the
family, and even if Postscript is Forth basically, by the same token
it's pretty easy to generate it algorithmically.  Like Ghostscript,
but unlike Emacs, TeX's language is sufficiently arcane that "ordinary
users" find it difficult to contribute to it.  (Paradoxically -- or
maybe not :-) -- that's why TeX and Ghostscript were historically in
universal use in free software distributions, and Emacs isn't.)

But TeX is a macro language, and one that is very much exposed to
users.  Like most macro languages, it is asyntactic -- one of the
important contributions of LaTeX was the introduction of the concept
of "environment" with properly nested \begin and \end, and of
"elements" (to borrow the SGML term) like \emph{}.  Yet the underlying
TeX macros remain exposed, and they make the language very stateful.
Worse, state often changes implicitly (at paragraph or page
boundaries, for example).  Syntax of control structures is horrible,
and almost never used by ordinary users, except in the very watered-
down form of LaTeX environments (which are actually quite nice).

TeX is also unable to take advantage of improvements around it, most
importantly Unicode, but also font technology.  The font specification
model is deeply embedded in TeX, and while it is possible to shim in a
different technology (as in the case of XeTeX), until quite recently
there wasn't really an industry standard either for selection of fonts
or for querying characteristics.  So you choose one such technology,
but that often ties you to a particular platform (as XeTeX was tied to
the Mac for quite a long time).  But the basic complexity of quite
detailed knowledge about fonts remains in TeX, and it often shows
through even at the user level, and definitely for style writers.

 > hitherto most tutorials (and even some documentation) too often
 > state "we'll ignore what this actually means and move on for
 > now".

Unfortunately, that's sort of inevitable given the architecture of
TeX.  All too often "what this actually means" is a change in global
state that more or less subtly changes the meaning of hundreds of TeX
macros.

    Luke:  But Master, what does this actually mean?
    Yoda:  Far far away galaxy there was, and long ago time is.  Named
    parameter changes were there, widely galactic, and ... oh, let's
    ignore what this actually means and move on for now, OK?  Darth
    Vader for you waiting is!  But parametric galaxies forget thee
    not, for in the Force change subtle yet today there is.

Yes, this is horrible, but I think Don Knuth of all people would be
aware of the dangers of premature optimization, so I conclude that the
optimization (globals everywhere) must have been necessary at the
time.


Footnotes: 
[1]  Here compositing refers to pixel blending, whereas in Wayland
AFAICT it refers to window management (windows as "big pixels"?)

[2]  I wonder if it would be possible to create an RPC protocol bound
to Cairo, and if that would beat X?

[3]  Versus "hacker privilege" advocates.  "All software yours now
ours is", anybody? ;-)