[TUHS] X and NeWS history (long)

[TUHS] X and NeWS history (long)

[Richard Tobin]

> The rest of your story is great, just one small correction.  SunView started
> as something Sun specific but it pretty quickly became a library on top of
> X11.  I'm not sure if it ever worked on X10, I think it did but I'm not sure.

As I recall it, SunTools (the original Sun window system) was renamed
SunView, and the API was ported to X11 under the name XView.

> Source: I've hacked up GUI interfaces for the SCM I did at Sun in Sunview.
> This would have been around 1990, is that still X10 or X11?

X11 came out in 1987.  I The first version I remember using is X11R3,
which came out in 1988.

See https://www.x.org/wiki/X11R1 (and .../X11R2 etc)

-- Richard

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

[TUHS] X and NeWS history (long)

[Jon Steinhart]

Richard Tobin writes:
> > The rest of your story is great, just one small correction.  SunView started
> > as something Sun specific but it pretty quickly became a library on top of
> > X11.  I'm not sure if it ever worked on X10, I think it did but I'm not sure.
> 
> As I recall it, SunTools (the original Sun window system) was renamed
> SunView, and the API was ported to X11 under the name XView.
> 
> > Source: I've hacked up GUI interfaces for the SCM I did at Sun in Sunview.
> > This would have been around 1990, is that still X10 or X11?
> 
> X11 came out in 1987.  I The first version I remember using is X11R3,
> which came out in 1988.
> 
> See https://www.x.org/wiki/X11R1 (and .../X11R2 etc)

Yes, it was originally SunTools and was renamed SunView.  But, XView was a
bit different although my memory of it all might be fading.

XView was a library that mapped SunView calls into X.  But, I have a faint
memory that there was more to it than that.  I think that there was a
conversion program that one had to run on the source code as part of the
conversion, and that that processor put flagging comments in for things
that couldn't automatically be converted.

My only clear memory of it is that it didn't work well right off the bat
because of the transition from 68K machines to Sparc.  Warren ??? hired
me on an emergency contract to fix it.  Turned out to be piles of pointer
alignment errors.  In what was typical for Sun, I fixed it promptly but
it took months to get paid.

The reason that that part sticks in my mind is that I got an IRS audit at
the time because it was right when they started looking at people claiming
to be contractors when they weren't.  I remember the IRS guy asking me for
the dates of work and payments.  I remember telling him when I worked for
Sun and having him respond with something like "oh yeah, for xxx dollars"
and realizing that he had all of the info that I did so I'd better be
accurate.  And I remember telling him "yeah, I worked on those dates and
billed for that amount but still haven't been paid."

[TUHS] X and NeWS history (long)

[Nemo]

On 13/09/2017, Jon Steinhart <jon at fourwinds.com> wrote (in part):
> Yes, it was originally SunTools and was renamed SunView.  But, XView was a
> bit different although my memory of it all might be fading.
>
> XView was a library that mapped SunView calls into X.  But, I have a faint
> memory that there was more to it than that.  I think that there was a
> conversion program that one had to run on the source code as part of the
> conversion, and that that processor put flagging comments in for things
> that couldn't automatically be converted.

My memory tends to be agree but as it last appeared in Solaris 9 and I
have no Solaris 9 machines left, I cannot verify.

N.

[TUHS] X and NeWS history (long)

[Larry McVoy]

On Wed, Sep 13, 2017 at 04:17:04PM +0100, Richard Tobin wrote:
> > The rest of your story is great, just one small correction.  SunView started
> > as something Sun specific but it pretty quickly became a library on top of
> > X11.  I'm not sure if it ever worked on X10, I think it did but I'm not sure.
> 
> As I recall it, SunTools (the original Sun window system) was renamed
> SunView, and the API was ported to X11 under the name XView.

Yeah, you are right, I dug up the makefile I was using and it says

LIBS            = -lxview -lolgx -lX11

I really kind of liked that toolkit, it was all key/value like so:

        panel = xv_create(
	    frame, PANEL,
            XV_WIDTH, WIDTH,
	    XV_HEIGHT, 30,
            PANEL_LAYOUT, PANEL_HORIZONTAL,
            XV_SHOW, FALSE,
	    NULL);

So the order of the args didn't really matter, I think the first one
maybe did because that was the parent but not sure, the rest could
be any order you wanted.  Pretty simple.

Not as simple as Ousterhout's TK stuff, to this day, that's my goto
gui toolkit.

[TUHS] X and NeWS history (long)

[Warner Losh]

On Thu, Sep 14, 2017 at 6:30 AM, Richard Tobin <richard at inf.ed.ac.uk> wrote:

> > I really kind of liked that toolkit, it was all key/value like so:
> >
> >         panel = xv_create(
> >           frame, PANEL,
> >             XV_WIDTH, WIDTH,
> >           XV_HEIGHT, 30,
> >             PANEL_LAYOUT, PANEL_HORIZONTAL,
> >             XV_SHOW, FALSE,
> >           NULL);
> >
> > So the order of the args didn't really matter, I think the first one
> > maybe did because that was the parent but not sure, the rest could
> > be any order you wanted.  Pretty simple.
>
> The first two were fixed; the prototype was
>
>   Xv_object xv_create (Xv_opaque owner, Xv_pkg *pkg, ...);
>
> The keywords (XV_WIDTH etc) contained a bitfield encoding the type and
> cardinality of the value argument(s) so that the argument list could
> be traversed without knowing every package's keywords.
>
> Using NULL as the terminating argument looks unportable.


It turned out to be portable enough. And no worse than calloc dependencies
in the base X11 library (which assumes that the address used when the
integer 0 is assigned to a pointer has no bits set). The only other
assumption was that pointers and ints were passed the same way, and that
whatever NULL expanded to was at least as long as an int.

So, yes this wouldn't work on a system whose null-pointer representation
contained bits set, but that was already an assumption of X11...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/122f19dc/attachment-0001.html>

[TUHS] X and NeWS history (long)

[Richard Tobin]

> I really kind of liked that toolkit, it was all key/value like so:
> 
>         panel = xv_create(
> 	    frame, PANEL,
>             XV_WIDTH, WIDTH,
> 	    XV_HEIGHT, 30,
>             PANEL_LAYOUT, PANEL_HORIZONTAL,
>             XV_SHOW, FALSE,
> 	    NULL);
> 
> So the order of the args didn't really matter, I think the first one
> maybe did because that was the parent but not sure, the rest could
> be any order you wanted.  Pretty simple.

The first two were fixed; the prototype was

  Xv_object xv_create (Xv_opaque owner, Xv_pkg *pkg, ...);

The keywords (XV_WIDTH etc) contained a bitfield encoding the type and
cardinality of the value argument(s) so that the argument list could
be traversed without knowing every package's keywords.

Using NULL as the terminating argument looks unportable.

-- Richard

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

[TUHS] X and NeWS history (long)

[ron minnich]

sorry if I missed it, but is the NeWS source lost forever? I could have
sworn it was released at some point.

On Wed, Sep 13, 2017 at 11:55 AM Nelson H. F. Beebe <beebe at math.utah.edu>
wrote:

> Here is a BibTeX entry for a book on the NeWS system:
>
> @String{pub-SV                  = "Spring{\-}er-Ver{\-}lag"}
> @String{pub-SV:adr              = "Berlin, Germany~/ Heidelberg,
>                                   Germany~/ London, UK~/ etc."}
>
> @Book{Gosling:1989:NBI,
>   author =       "James Gosling and David S. H. Rosenthal and Michelle
>                  Arden",
>   title =        "The {NeWS} Book: an introduction to the {Network\slash
>                  extensible Window System}",
>   publisher =    pub-SV,
>   address =      pub-SV:adr,
>   pages =        "vi + 235",
>   year =         "1989",
>   ISBN =         "0-387-96915-2",
>   ISBN-13 =      "978-0-387-96915-2",
>   LCCN =         "QA76.76.W56 A731 1989",
>   bibdate =      "Tue May 25 07:20:00 1999",
>   bibsource =    "http://www.math.utah.edu/pub/tex/bib/unix.bib",
>   keywords =     "NeWS (computer file); Windows (computer programs)",
> }
>
> It is the only book that I have recorded on NeWS (I have it on my
> office bookshelf).  If there is interest, I can post links to 10 or
> so journal articles and conference proceedings about NeWS from
> 1986 to 1990.
>
>
> -------------------------------------------------------------------------------
> - Nelson H. F. Beebe                    Tel: +1 801 581 5254
> <(801)%20581-5254>                  -
> - University of Utah                    FAX: +1 801 581 4148
> <(801)%20581-4148>                  -
> - Department of Mathematics, 110 LCB    Internet e-mail:
> beebe at math.utah.edu  -
> - 155 S 1400 E RM 233                       beebe at acm.org
> beebe at computer.org -
> - Salt Lake City, UT 84112-0090, USA    URL:
> http://www.math.utah.edu/~beebe/ -
>
> -------------------------------------------------------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/893f0f09/attachment-0001.html>

[TUHS] X and NeWS history (long)

[Nelson H. F. Beebe]

Here is a BibTeX entry for a book on the NeWS system:

@String{pub-SV                  = "Spring{\-}er-Ver{\-}lag"}
@String{pub-SV:adr              = "Berlin, Germany~/ Heidelberg,
                                  Germany~/ London, UK~/ etc."}

@Book{Gosling:1989:NBI,
  author =       "James Gosling and David S. H. Rosenthal and Michelle
                 Arden",
  title =        "The {NeWS} Book: an introduction to the {Network\slash
                 extensible Window System}",
  publisher =    pub-SV,
  address =      pub-SV:adr,
  pages =        "vi + 235",
  year =         "1989",
  ISBN =         "0-387-96915-2",
  ISBN-13 =      "978-0-387-96915-2",
  LCCN =         "QA76.76.W56 A731 1989",
  bibdate =      "Tue May 25 07:20:00 1999",
  bibsource =    "http://www.math.utah.edu/pub/tex/bib/unix.bib",
  keywords =     "NeWS (computer file); Windows (computer programs)",
}

It is the only book that I have recorded on NeWS (I have it on my
office bookshelf).  If there is interest, I can post links to 10 or
so journal articles and conference proceedings about NeWS from
1986 to 1990.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

[TUHS] X and NeWS history (long)

[Lawrence Stewart]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 688 bytes --]


> On 2017, Sep 12, at 8:52 PM, ron minnich <rminnich at gmail.com> wrote:
> 
> 
> 
> On Tue, Sep 12, 2017 at 5:30 PM Bakul Shah <bakul at bitblocks.com <mailto:bakul at bitblocks.com>> wrote:
> Unix still needs a decent graphics API (ideally one that can work over a network).
> 
> 
> does anyone know or care about network graphics any more? From what I can tell, no.
> 
> ron 

Well I do.  I’ve been looking at gigantic simulator trace files recently, and the graphics is far smaller than the underlying data.


-L

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/263b125a/attachment.html>

[TUHS] X and NeWS history (long)

[Jon Steinhart]

Tony Finch writes:
> Finally, a question: is there a good comparison of NeWS vs NeXT Display
> Postscript anywhere?

Not that I'm aware of.  The main difference was in the name; Display
Postscipt just displayed Postscript; it's what NeXT used for higher
quality rendering.  NeWS was a window management system that included
Postscript graphics.

[TUHS] X and NeWS history (long)

[Arthur Krewat]

On 9/12/2017 11:55 PM, Jon Steinhart wrote:
>
> I look at the systemd problem slightly differently.  In short, I was
> coming into work one night at BTL when Ken was heading out the door for
> his sabbatical at UCB with a stack of mag tapes under his arm.  I see
> that as a pivotal moment in computer history.  Students could learn from
> an actual real computer system; they had source code access.  And, they
> had the ability to modify and contribute to that code.  A lot of students
> from that era went out to do great things.  Years later, the lower cost
> of PCs resulted in students using them for their work.  Not only was MS-DOS
> not as advanced a system as UNIX, but source code access was gone.  Students
> had to learn from contrived projects, and didn't have the ability to play
> with the guts of the operating system that they were using.
Completely agree. To keep beating the dead horse, in high school we had 
access to a PDP-10, a KA10 running TOPS-10 5.06 - later they switched to 
4 KS10s running TOPS-10 6.03

I gained some notoriety as a hacker, and was tasked by the consulting 
firm that ran the things to build a "better" MIC (a batch scripting tool 
that allowed you to run things offline and go back later to look at the 
results). I had exploited the original DEC version to give me access to 
[1,2] ;)

Anyway, during that period, I was allowed to visit the installation, and 
if it was a weekend when students weren't on, to mount the "black" RP06 
pack that had all the TOPS-10 sources on it, and look at or print out 
anything I wanted (look or print, same thing, really, the access was via 
LA120). I learned a lot. Went on to work for the place for a few years.

Somewhere during that time, I was exposed to the IBM-PC and PCDOS. 
Except for my own projects in assembler, the IBM DOS and Technical 
Reference Manuals were all I had access to. HOWEVER - IBM in their 
infinite wisdom actually provided the sources to the BIOS in the manual. 
Still have that manual. That was awesome. I didn't have the DOS sources, 
but it wasn't hard to disassemble them with DEBUG and take a peak 
anyway. Back then, it was all written in assembler anyway, so it was 
only missing the symbols. Nothing was "out of reach".

Now, with C or C++, or worse, higher-level languages being the default 
choices, that optimize everything to death, it's hard to disassemble 
anything and really "see" what it's trying to accomplish, and how. Not 
impossible, I've done some reverse engineering of various OS's, but 
nothing spectacular.

For today's kids, well, it's a much different story. My son has a CS 
degree, but has almost no experience really peaking under the hood of 
any OS - some small ventures into kernels, but nothing huge like UNIX. 
Which brings me to another thing. Linux sources are freely available, 
and yet I don't see anyone really looking at them as an educational 
thing. I might be wrong, my experience in higher education is NONE.

[TUHS] X and NeWS history (long)

[Tony Finch]

A couple of NeWS-related links which I saved back in March:

A book / conference report surveying the state of Window Management in
1985, specifically the chapter on an early version of NeWS:

http://www.chilton-computing.org.uk/inf/literature/books/wm/p005.htm

The amazing NeFS, the Network Extensible File System, which was supposed
to be version 3 of NFS, based on in-kernel PostScript.

Thankfully it died :-)

http://www.donhopkins.com/home/nfs3_0.pdf

Last year, an appreciation of NeWS written from a modern perspective,
including some comparisons with the JS / HTML / CSS / SVG web:

https://medium.com/@slavapestov/yesterdays-news-c52f2be95205

Finally, a question: is there a good comparison of NeWS vs NeXT Display
Postscript anywhere?

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Dogger: North or northwest 6 to gale 8, increasing severe gale 9 or storm 10
at first. Moderate or rough, occasionally very rough at first. Rain or
thundery showers. Good, occasionally poor.

[TUHS] X and NeWS history (long)

[Jon Steinhart]

ron minnich writes:
> 
> I don't disagree. I just think the knowledge of all that is lost, the same
> way so much knowledge of unix is lost. That's why we have things like
> systemd.

It's amusing to me how many of the topics on this list I've included in
my book in process because I feel that they're important.

I look at the systemd problem slightly differently.  In short, I was
coming into work one night at BTL when Ken was heading out the door for
his sabbatical at UCB with a stack of mag tapes under his arm.  I see
that as a pivotal moment in computer history.  Students could learn from
an actual real computer system; they had source code access.  And, they
had the ability to modify and contribute to that code.  A lot of students
from that era went out to do great things.  Years later, the lower cost
of PCs resulted in students using them for their work.  Not only was MS-DOS
not as advanced a system as UNIX, but source code access was gone.  Students
had to learn from contrived projects, and didn't have the ability to play
with the guts of the operating system that they were using.  While there are
exceptions, I don't feel like students from the PC era are nearly as good.
While Linux has sort of brought us back to the golden age of source access
many of the people working on it are from the PC era and are trying to wedge
their Microsoft-nonsensibilities into Linux.  That's where things like
systemd come from.

Jon

[TUHS] X and NeWS history (long)

[ron minnich]

On Tue, Sep 12, 2017 at 7:06 PM Kurt H Maier <khm at sciops.net> wrote:

>
>
> In 2009 I could just ssh into my phone and launch its messaging program
> from my desktop.  It worked the other way, too -- I could log into my
> workstation from my phone.  We lost that when iOS and Android destroyed
> all the competition.
>


I don't disagree. I just think the knowledge of all that is lost, the same
way so much knowledge of unix is lost. That's why we have things like
systemd.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/50674af6/attachment.html>

[TUHS] X and NeWS history (long)

[Jon Steinhart]

Grant Taylor writes:
> "voxel"?  I'll have to look that up.

I'll save you the trouble.  3D.  Volume equivalent of a pixel.

[TUHS] X and NeWS history (long)

[Grant Taylor]

On 09/12/2017 09:01 PM, Jon Steinhart wrote:
> Well, I agree that this is one area in which X does OK.

I also like how X will allow me to have windows from remote programs 
mixed with local programs and does not require a full desktop.  (A 
feature that RDP has gotten in the last 10 ? years.)

> Although, being a command line sort of guy, I'm happy to ssh into a machine 
> and run commands.  I try to avoid non-scriptable GUIs.

I completely agree.

> I don't administer headless machines, and stay very far away from Oracle. 
>  I'm not sure what their installer does, but usually running X requires an 
> installed and running system.

Sadly my use case what proving to a ... questionable DBA that things 
could work as directed, despite his objections the other way.

Since I was not familiar with Oracle RAC and Oracle DB, I needed to go 
the front door route, taking screen shots and documenting each and 
everything I did.  (Partially for political reasons.)

Yes, you do need an installed (base) OS with some dependencies. 
Thankfully you don't need a full window manager or the bloat that comes 
with things like Gnome / KDE.

> So since a number of people have justified networked graphics we're back 
> to the question of what an API should look like.  At a very high level, 
> it needs to be modular because there is no one thing that gets done with 
> graphics, and there's no reason to carry a huge API around just because 
> you need a small part of it.  In particular, there is a distinction 
> between applications that spit out geometry and those that spit out mass 
> quantities of pixel/voxel data.

"voxel"?  I'll have to look that up.

> Also, because of the way that this discussion started, I'm not sure whether 
> or not resource management (windows, keyboard, etc.) falls under the 
> umbrella of graphics.

I expect that they should be included in such discussions.  After all, 
they are intimately related.  GUI applications are of questionable value 
if you can't interact with them.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3717 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/01b07472/attachment.bin>

[TUHS] X and NeWS history (long)

[Jon Steinhart]

Grant Taylor writes:
> I personally really like the ability to SSH to a machine (*) using -XY 
> and run Oracle's installer such that it's display shows up on my notebook.

Well, I agree that this is one area in which X does OK.

Although, being a command line sort of guy, I'm happy to ssh into a machine
and run commands.  I try to avoid non-scriptable GUIs.

I don't administer headless machines, and stay very far away from Oracle.
I'm not sure what their installer does, but usually running X requires an
installed and running system.

So since a number of people have justified networked graphics we're back
to the question of what an API should look like.  At a very high level,
it needs to be modular because there is no one thing that gets done with
graphics, and there's no reason to carry a huge API around just because
you need a small part of it.  In particular, there is a distinction
between applications that spit out geometry and those that spit out mass
quantities of pixel/voxel data.

Also, because of the way that this discussion started, I'm not sure whether
or not resource management (windows, keyboard, etc.) falls under the
umbrella of graphics.

Jon

[TUHS] X and NeWS history (long)

[Grant Taylor]

On 09/12/2017 06:56 PM, Jon Steinhart wrote:
> Wow, big topic.  Rather than getting into it in detail at the moment I'm curious
> as to why you think that it's important for it to work over a network.

I personally really like the ability to SSH to a machine (*) using -XY 
and run Oracle's installer such that it's display shows up on my notebook.

I find that SO MUCH EASIER than trying to get the iDRAC / RSA / IMM / 
etc to work.  Usually they require multiple ports and protocols (often 
UDP, which is a pain through SSH).

For me, X11 forwarding just works.  -  Thank you to everyone that spent 
so much time and energy getting it to work.

> Before you bite my head off for that question, I'm not suggesting that there's
> no value in taking data from somewhere on a network and using it on a local
> machine.

I think there's a distinct and large difference in data and display I/O.

> Back in the darker ages of the Green Flash (Tektronix storage tubes like the
> 4014) it was common to display remote data on a local system.  The data in
> those days arrived via RS-232.  Depending on the application, one could shovel
> 4014 commands over the wire or just raw data and use a local program to generate
> drawing commands.

I've often contemplated SIXEL graphics in an error prompt from remote 
systems.  (This is a different topic, which itself relies on answer back.)

> I've never been convinced that the way that X did it made sense.  Sure, you'd
> here people say things like "your remote Cray can draw stuff on your local
> screen."  But it wasn't just that; using X your Cray also had to draw and
> manage your user interface: scroll bars, buttons, and so on unless you wanted
> to create a separate protocol so that you could run your user interface
> locally and have it communicate with the remote application.  Of course, X was
> enough of a pig that maybe using a Cray to drive a scroll bar made sense :-)

Maybe I'm a n00b and don't know better, but I'd think that would be a 
use case for nested X running on a local (closer than the Cray) machine. 
  So all the Cray needed to do was to send program I/O to the (nested) X 
server.  Then the (nested) X server could handle scroll bars and other 
local window manager eye candy.

I think the Cray would run something much like X does if you aren't 
running a window manager.  Simple, single application, no frills.

I think.

> So before getting off into graphics APIs I think that it would be interesting
> to hash this out.
> 
> BTW, one of the best things about NeWS was the fact that with a reasonable set
> of conventions the user interface personality could live in the server and be
> applied to all applications.  Contrast that with X where each application links
> in a UI library, and if your screen looks anything like mine there isn't a lot
> of consistency because different applications use different libraries.
> 
> One of the problems with NeWS was that this was so much fun to play with that
> the people doing the work kept on coming up with new ideas faster than they
> could implement the old ones so there was difficulty completing toolkit
> projects.

LOL

Feeping Creatureism?



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3717 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/2e26e6b3/attachment-0001.bin>

[TUHS] X and NeWS history (long)

[Grant Taylor]

On 09/12/2017 07:42 PM, Arthur Krewat wrote:
> Try installing Oracle products on UNIX/Linux without X. Better yet, try 
> doing it on a remote machine on the other side of the world.

Ouch!  Doing it half way across the US was bad enough.  I'd hate to 
experience half way around the world.

> While KVMs like a Dell DRAC or Sun LOM, and virtualization consoles help 
> a lot, it's nice to be able to "ssh -X" to a remote machine and run that 
> installer back to my local VNC server.

(Don't forget the -Y to forward authentication. ;-)

I completely agree.

Also, I believe that graphic console has a completely different security 
exposure compared to allowing someone to use X remotely.  (Via ssh 
forwarding or more traditionally across the network.)

> If I had a decent X windows implementation locally, I'd use that instead 
> of VNC.

I actually ended up going the other way.  X11 is nice when it works. 
However, I found that I spent a LOT of time waiting on X11 to chat back 
and forth.  Comparatively VNC is (IMHO) a lot better at lower bandwidth 
and / or higher latency.

Also, running Xvnc (server) on the remote system allows you to 
(dis)connect the VNC client at will.  Same advantages as screen / tmux, 
but for X11.

> X had it's issues. But it's still alive and well - maybe because of Java ;)

I personally look fondly on the days when you could set the DISPLAY 
variable and launch your GUI application.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3717 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/f0e379c5/attachment.bin>

[TUHS] X and NeWS history (long)

[Kurt H Maier]

On Wed, Sep 13, 2017 at 12:56:26AM +0000, ron minnich wrote:
> Why does a phone need it? That's the determinant.
       
Apple and Google spend a hell of a lot of time syncing everyone's data
between phones, tablets, computers, surveillance platforms, and the
like.  Microsoft is making a lot of noise about jamming your phone into
your computer to do things in a consistent manner.  They call it
'convergence.'
       
In 2009 I could just ssh into my phone and launch its messaging program
from my desktop.  It worked the other way, too -- I could log into my
workstation from my phone.  We lost that when iOS and Android destroyed
all the competition.  
       
khm

[TUHS] X and NeWS history (long)

[Arthur Krewat]

Try installing Oracle products on UNIX/Linux without X. Better yet, try 
doing it on a remote machine on the other side of the world.

While KVMs like a Dell DRAC or Sun LOM, and virtualization consoles help 
a lot, it's nice to be able to "ssh -X" to a remote machine and run that 
installer back to my local VNC server.

If I had a decent X windows implementation locally, I'd use that instead 
of VNC.

X had it's issues. But it's still alive and well - maybe because of Java ;)



On 9/12/2017 8:52 PM, ron minnich wrote:
>
>
> On Tue, Sep 12, 2017 at 5:30 PM Bakul Shah <bakul at bitblocks.com 
> <mailto:bakul at bitblocks.com>> wrote:
>
>     Unix still needs a decent graphics API (ideally one that can work
>     over a network).
>
>
> does anyone know or care about network graphics any more? From what I 
> can tell, no.
>
> ron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/7f00c728/attachment-0001.html>

[TUHS] X and NeWS history (long)

[Bakul Shah]

> On Sep 12, 2017, at 5:56 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> 
> Bakul Shah writes:
>> 
>> Unix still needs a decent graphics API (ideally one that can work over a network).
>> Any thoughts on that?
> 
> Wow, big topic.  Rather than getting into it in detail at the moment I'm curious
> as to why you think that it's important for it to work over a network.

Heavy number crunching generating some data for display may be far
from the one displaying the data.

[sensor input | storage] => [computation} <=> [display/user input]

> Before you bite my head off for that question, I'm not suggesting that there's
> no value in taking data from somewhere on a network and using it on a local
> machine.
...
> So before getting off into graphics APIs I think that it would be interesting
> to hash this out.

Indeed. The question really is where in the pipeline from gobs 
of raw data to number crunching transformations to display
does the network split lie.  In a sense we already have a
split (GPU vs CPU) but it is highly specialized.
 
Camera, mouse, graphics tablet, keyboard, other sensor inputs 
will be (or should be) near the display but may be processed far
away in an application specific manner.
 
I suspect here too we may go through Sutherland's wheel of 
reincarnation.  We can offload more GUI processing in the
server but as GUI becomes more sophisticated (or complicated),
it will feel slow.
 
I can envision using a RaspberryPi as a "graphics processor"
but we still need a protocol between the 'Pi and the
"backend". If done right, I wouldn't want to touch the innards
of the s/w running on the 'Pi when writing a game or something
needing visualization.

> BTW, one of the best things about NeWS was the fact that with a reasonable set
> of conventions the user interface personality could live in the server and be
> applied to all applications.  Contrast that with X where each application links
> in a UI library, and if your screen looks anything like mine there isn't a lot
> of consistency because different applications use different libraries.

[TUHS] X and NeWS history (long)

[Warner Losh]

On Tue, Sep 12, 2017 at 6:56 PM, ron minnich <rminnich at gmail.com> wrote:

>
>
> On Tue, Sep 12, 2017 at 5:54 PM Warner Losh <imp at bsdimp.com> wrote:
>
>>
>>
>> I still use them all the time...  But maybe I'm a nobody...
>>
>>
> I know I am :-)
>
> It's strange nowadays to try to explain network graphics to interns. I
> feel like I'm giving them a tour of Jurassic Park. They like the idea once
> they get it, but they have no particular use for it from what I can see.
> Why does a phone need it? That's the determinant.
>

VNC to the phone is the best thing ever... But I like a real keyboard...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/c53d3688/attachment.html>

[TUHS] X and NeWS history (long)

[ron minnich]

On Tue, Sep 12, 2017 at 5:54 PM Warner Losh <imp at bsdimp.com> wrote:

>
>
> I still use them all the time...  But maybe I'm a nobody...
>
>
I know I am :-)

It's strange nowadays to try to explain network graphics to interns. I feel
like I'm giving them a tour of Jurassic Park. They like the idea once they
get it, but they have no particular use for it from what I can see. Why
does a phone need it? That's the determinant.

ron

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/c3212f7b/attachment.html>

[TUHS] X and NeWS history (long)

[Jon Steinhart]

Bakul Shah writes:
> 
> Unix still needs a decent graphics API (ideally one that can work over a network).
> Any thoughts on that?

Wow, big topic.  Rather than getting into it in detail at the moment I'm curious
as to why you think that it's important for it to work over a network.

Before you bite my head off for that question, I'm not suggesting that there's
no value in taking data from somewhere on a network and using it on a local
machine.

Back in the darker ages of the Green Flash (Tektronix storage tubes like the
4014) it was common to display remote data on a local system.  The data in
those days arrived via RS-232.  Depending on the application, one could shovel
4014 commands over the wire or just raw data and use a local program to generate
drawing commands.

I've never been convinced that the way that X did it made sense.  Sure, you'd
here people say things like "your remote Cray can draw stuff on your local
screen."  But it wasn't just that; using X your Cray also had to draw and
manage your user interface: scroll bars, buttons, and so on unless you wanted
to create a separate protocol so that you could run your user interface
locally and have it communicate with the remote application.  Of course, X was
enough of a pig that maybe using a Cray to drive a scroll bar made sense :-)

So before getting off into graphics APIs I think that it would be interesting
to hash this out.

BTW, one of the best things about NeWS was the fact that with a reasonable set
of conventions the user interface personality could live in the server and be
applied to all applications.  Contrast that with X where each application links
in a UI library, and if your screen looks anything like mine there isn't a lot
of consistency because different applications use different libraries.

One of the problems with NeWS was that this was so much fun to play with that
the people doing the work kept on coming up with new ideas faster than they
could implement the old ones so there was difficulty completing toolkit
projects.

Jon

[TUHS] X and NeWS history (long)

[Warner Losh]

On Tue, Sep 12, 2017 at 6:52 PM, ron minnich <rminnich at gmail.com> wrote:

>
>
> On Tue, Sep 12, 2017 at 5:30 PM Bakul Shah <bakul at bitblocks.com> wrote:
>
>> Unix still needs a decent graphics API (ideally one that can work over a
>> network).
>>
>>
> does anyone know or care about network graphics any more? From what I can
> tell, no.
>

I still use them all the time...  But maybe I'm a nobody...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/b3e4f3dd/attachment.html>

[TUHS] X and NeWS history (long)

[ron minnich]

On Tue, Sep 12, 2017 at 5:30 PM Bakul Shah <bakul at bitblocks.com> wrote:

> Unix still needs a decent graphics API (ideally one that can work over a
> network).
>
>
does anyone know or care about network graphics any more? From what I can
tell, no.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/17a08332/attachment-0001.html>

[TUHS] X and NeWS history (long)

[Bakul Shah]

> On Sep 12, 2017, at 3:11 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> 
> 
> As
> a result, the X API is wide and shallow like the Mac, and full of interesting
> race conditions to boot.  The whole thing could have been done with less than
> a dozen API calls.


Unix still needs a decent graphics API (ideally one that can work over a network).
Any thoughts on that?

[TUHS] X and NeWS history (long)

[Jon Steinhart]

Adam Sampson writes:
> Jon Steinhart <jon at fourwinds.com> writes:
> 
> > I think that I'm the only person to write an X server outside of the X
> > Consortium.
> 
> When I was doing my PhD a few years ago, one of the case studies I used
> was an X11 server that was written in occam 2 by Colin Willcock at the
> University of Kent at Canterbury. I managed to recover Colin's source
> code for the X server (in Transputer Development System format), which
> is dated November 1988, from a very dusty machine backup...
> 
> I also found the sources for Colin's 1991 report to the funding body on
> the completion of the project, and his 1992 PhD thesis which describes
> the same work. I rebuilt these in 2010 using a modern version of TeX, so
> the appearance is probably different from what Colin intended (and the
> cover-page dates are definitely wrong), but they're quite readable:
> 
> https://stuff.offog.org/cw3-report-rebuilt.pdf
> https://stuff.offog.org/cw3-thesis-rebuilt.pdf
> 
> Note in particular the motivation stated in the report: "The worst of
> these problems was the MEiKO C compiler, which (by mid-1988) proved
> incapable of making any significant headway when presented with the
> public-domain X-sources. [...] After consultation with the project
> monitoring officers at RAL, we took the decision to investigate the
> prospects for a complete re-implementation of the X-server in occam 2,
> making no use of the public domain C sources."
> 
> There have of course been other X server implementations more recently,
> but they're less historically interesting!

Cool, thanks for the info.  Based on the date, this was probably X10, not
X11.

[TUHS] X and NeWS history (long)

[Chris Torek]

>Well, just to nitpick, I remember that much of SunView was a library but it
>relied on special device drivers with complicated ioctls and such.  I don't
>recall that it be easily separated from the OS.

My (fuzzy) memory was that you called library routines to do
rasterops, and they consulted with the specific frame buffer
hardware in a way that, to (mis)quote Dennis Ritchie, had:

   unwarranted chumminess with the ... implementation

[see http://c-faq.com/struct/structhack.html for actual quote].

This meant if your rasterop was misbehaving, it could be a
bug in a driver, or in the hardware.

(I remember this from trying to chase down some weird rasterop
behavior, or some such.)

Chris

[TUHS] X and NeWS history (long)

[Adam Sampson]

Jon Steinhart <jon at fourwinds.com> writes:

> I think that I'm the only person to write an X server outside of the X
> Consortium.

When I was doing my PhD a few years ago, one of the case studies I used
was an X11 server that was written in occam 2 by Colin Willcock at the
University of Kent at Canterbury. I managed to recover Colin's source
code for the X server (in Transputer Development System format), which
is dated November 1988, from a very dusty machine backup...

I also found the sources for Colin's 1991 report to the funding body on
the completion of the project, and his 1992 PhD thesis which describes
the same work. I rebuilt these in 2010 using a modern version of TeX, so
the appearance is probably different from what Colin intended (and the
cover-page dates are definitely wrong), but they're quite readable:

https://stuff.offog.org/cw3-report-rebuilt.pdf
https://stuff.offog.org/cw3-thesis-rebuilt.pdf

Note in particular the motivation stated in the report: "The worst of
these problems was the MEiKO C compiler, which (by mid-1988) proved
incapable of making any significant headway when presented with the
public-domain X-sources. [...] After consultation with the project
monitoring officers at RAL, we took the decision to investigate the
prospects for a complete re-implementation of the X-server in occam 2,
making no use of the public domain C sources."

There have of course been other X server implementations more recently,
but they're less historically interesting!

-- 
Adam Sampson <ats at offog.org>                         <http://offog.org/>

[TUHS] X and NeWS history (long)

[Jon Steinhart]

Larry McVoy writes:
> 
> The rest of your story is great, just one small correction.  SunView started
> as something Sun specific but it pretty quickly became a library on top of
> X11.  I'm not sure if it ever worked on X10, I think it did but I'm not sure.
> 
> Source: I've hacked up GUI interfaces for the SCM I did at Sun in Sunview.
> This would have been around 1990, is that still X10 or X11?

Well, just to nitpick, I remember that much of SunView was a library but it
relied on special device drivers with complicated ioctls and such.  I don't
recall that it be easily separated from the OS.

BTW, on a historically amusing note, I still have two old Sun machines in the
basement, a SparcStation 20 and an Ultra-60.  The 20 has whatever graphics card
supported double-buffering.  It has a modified kernel thanks to some unnamed
(and unremembered at this point) soul who provided source code.  I hacked it so
that SunView ran in one of the buffers and X ran in the other.  Moving the mouse
off of the edge of the screen switched which buffer was displayed.  My answer to
being able to run both SunView and X.

> I sure did, love to meet you some time, where are you?

I live in Oregon, about 50 miles southwest of Portland.  I will probably be
in San Francisco the first full weekend of October for the Hardly Strictly
Bluegrass Festival if you're in the bay area.  Will be staying at Sun employee
#5's house.

Jon

[TUHS] X and NeWS history (long)

[Larry McVoy]

On Tue, Sep 12, 2017 at 03:11:03PM -0700, Jon Steinhart wrote:
> In many respects Sun botched NeWS politically.  Large numbers of businesses
> relied on applications that ran on Sun's SunView window system which was
> heavily hooked into the OS and not even remotely portable.  

The rest of your story is great, just one small correction.  SunView started
as something Sun specific but it pretty quickly became a library on top of
X11.  I'm not sure if it ever worked on X10, I think it did but I'm not sure.

Source: I've hacked up GUI interfaces for the SCM I did at Sun in Sunview.
This would have been around 1990, is that still X10 or X11?

> We showed XTool off at some shows.  People would come by the booth and ask
> "how did you get it to run so fast?"  Being me, I loudly answered "We cheated.
> We designed ours first."  Turns out that one of these times Keith Packard and
> Jim Gettys were walking by which resulted in some long-standing animosity.

Heh.  I can only imagine.  ROTFLMAF.

> Wrapping this up on a happy note, some years ago I was hanging out yakking at
> the Hacker's Conference when this guy I didn't recognize due to hair loss came
> up to me and said "I'm not going to say that you weren't an asshole because
> you were, but you were right."  It was Keith Packard who was trying to get X
> running on the OLPC and had run into the issue of clients allocating server
> memory that couldn't be freed.  Been good friends since.  Same with Gettys.

Awesome.

> Well, that's the whole sordid take from my point of view.  Hope that you
> enjoyed it.

I sure did, love to meet you some time, where are you?

--lm

[TUHS] X and NeWS history (long)

[Jon Steinhart]

> Jon Steinhart wrote:
> As the guy who single-handedly prevented X from becoming an ANSI standard,
> I'd be happy to start another thread on this topic if people are interested.

Arthur Krewat writes:
> Oh, do, please go on ;)

Larry McVoy writes:
> I'd like to hear that too.  I like X11, use it all the time, take advantage
> of the remote display all the time, have done some sunview programming and
> a little of just the base libraries.  I can imagine that standardizing all
> that stuff would be more than a mouthful.  But what else ya got?

OK, you asked for it.  I think that I need to ask the Thing King to zark in a
few crates of old memories...

I spent mt teenage years as a graphics person as a result of my summer job at
Murray Hill working on the Glance-G terminal project.  Side-tracked into test
and measurement after getting my EE degree and doing cool black magic
electronics at Tektronix.  Got back into graphics and software when Tek tried
to get into the UNIX workstation business.  Started working on window systems
at that time, and continued after I quit Tek and moved to the bay area to
play at the startup game.  Started consulting after the third startup failed
which I'm still doing today.

While at Tek one of my jobs was to come up with a C language binding for GKS,
the Graphical Kernel System standard.  That itself is a funny story which ties
into the earlier troff thread.  I designed a language binding and wrote it up.
My friend Ed, author of "Real Programmers Don't Use Pascal", worked down the
road at GSS (Graphics Software Systems).  He told me that "yours looks better
than ours, you should bring it to the standards committee".  Amazingly enough
my management bought off on it, I brought my draft to the Huntsville meeting,
and it was adopted as the draft standard.  Why?  Because we had troff and an
Imprint-10!  Those were the days when people equated typeset with professional.
I recall discussing the issues with the C binding at an ANSI C committee
meeting in San Franscisco; probably met some you there.

ANSI X3X3 formed a window management subcommittee X3H3.6 somewhere along the
line.  I moved over there as I was pretty much done with the GKS stuff and the
window management end of things was more interesting.  Life changed in that
committee when the X push happened.  But first, a bit on a parallel track.

I knew Keith Lantz at Stanford who, if I remember correctly, had a graduate
seminar and wanted to talk about window management systems.  I came in as a
guest lecturer.  Partly because of this I became aware of the origins of X as
those weren't the days when one could easily just get technical papers on line.

For those of you unfamiliar with this, Stanford had developed the V operating
system which featured very fast synchronous IPC.  I believe that this ran on
the original Stanford University Network (SUN) boards.  They also developed
the W window system which ran on top of V.

I'm a bit fuzzy on the continental shift, but I believe that W made the cross
country trip to MIT via some sort of DEC connection.  Maybe they had funded
some of the Stanford research.

Gosling and Rosenthal had been working on the Andrew window system at CMU.  I
don't remember whether or not this was UNIX-based, but one of their early
design decisions was to minimize round-trips because they didn't have fast
synchronous IPC.

Despite this prior art, Scheifler took the W code, ported it to UNIX, and
called it X.  As one would expect, the performance was terrible.  X got
stuck at this state, version 10, for a long time.  Sun announced NeWS during
this stagnant period.  Freaked out Apollo, DEC, HP, etc. who got together at
DEC's Hamilton Avenue building to plot the "anything but Sun" strategy.  They
were successful in holding off the adoption of NeWS until they could rewrite
X to eliminate many of the synchronous round trips from the protocol resulting
in X version 11 which was pretty much completely incompatible with version 10.

In many respects Sun botched NeWS politically.  Large numbers of businesses
relied on applications that ran on Sun's SunView window system which was
heavily hooked into the OS and not even remotely portable.  They couldn't
use NeWS instead of SunView because they were running real businesses.  There
was no way to run SunView and NeWS at the same time so businesses couldn't
run new NeWS-based applications and old SunView applications at the same time.

I'm a bit fuzzy here, but the decision to merge X and NeWS was a bad technical
solution to a political problem.  Sun wanted to be able to say "We have X too."
Unfortunately, folks at Sun agreed to do this project without knowing what they
were talking about; it got rough when they realized that the NeWS and X
graphics models were completely incompatible.

Oh, despite all of the hype, there was actually nothing useful that one could
do using X at the time.  Not being very well socially adjusted, I annoyed a
lot of people by going to show floors and looking at X running things like maze
and loudly proclaiming "Oh, that's exactly what I do for a living."

Somewhere along the line Sun also decided to produce a mostly automated system
to convert SunView programs to use X.  I think that this was called XView.  I
remember billing for many a late night to actually get the thing working.

One of my other clients at the time was AED (advanced electronic displays).
If you were lucky enough to have a color frame buffer in those days it was
likely one of theirs.  They had a project to build X accelerator boards that
plugged into Sun workstations.  I think that I got called in because it
wouldn't work on the 3/260 which I eventually tracked down to the behavior of
the cache that only the 260 had.

AED was trying to figure out what to do as the world had changed and frame
buffers couldn't compete with workstations.  I came up with the idea to make
an X server that would run in a SunView window so that companies that relied
on SunView applications could run X applications concurrently.  We called this
XTool in keeping with the SunView application naming scheme.  I think that I
still have a few "XTool - Safe X for Suns" tee shirts around somewhere.  This
project unfortunately failed because AED was bought by someone with a "ship it
now, that'll force folks to fix the bugs" attitude.  XTool was very small and
fast compared to the X sample server because I wrote the server from scratch.
I think that I'm the only person to write an X server outside of the X
Consortium.  One of the things that I learned by doing it was that the X
Consortium folks were wrong when they said that the documentation was the
standard, not the sample server.  There were significant differences between
the two.

We showed XTool off at some shows.  People would come by the booth and ask
"how did you get it to run so fast?"  Being me, I loudly answered "We cheated.
We designed ours first."  Turns out that one of these times Keith Packard and
Jim Gettys were walking by which resulted in some long-standing animosity.

Back to the standards track.  Any of you that have done ANSI work know that
CBEMA has a one organization, one vote policy.  When Scheifler showed up at
X3H3.6 all other work stopped and X became a draft standard.  Whenever there
was a vote everybody would look to see how Bob was voting and voted with him.
For political reasons, all of the voting members from X Consortium member
companies had been told that they couldn't vote against X for technical reasons.

You may also know that one has to pay to be on an ANSI committee.  I wrote the
ANSI Secretariet and told them that I felt that by having both the X Consortium
and their member companies voting violated the spirit of the one organization
one vote rule, and that I couldn't justify continuing to pay to be on the
committee with this behavior.  They took it under advisement.

Eventually, public review time came around.   I submitted a document containing
something on the order of 800 comments.  These were pretty repetitious because
I had to hit the document one request at a time, but the major themes were:

 o  The only really worthwhile thing about X was the distributed extension
    registration mechanism.  All of the input, graphics and other crap
    should be moved to extension #1.  That way, it won't be mandatory in
    conforming implementations once that stuff was obsolete.  As you probably
    know, that's where we are today; nobody uses that stuff but it's like the
    corner of an Intel chip that implements the original instruction set.  As
    an aside, I upset many when working on OpenDoc for Apple and saying the
    same thing there.

 o  The atom/property mechanism allows clients to allocate memory in the server
    that can never be freed.  Some way to free memory needs to be added.

 o  The bit encodings should be part of a separate language binding, not part
    of the functional description.

I received a reply from the committee that said "Thank you for you comments."
I wrote the ANSI Secretariet and asked "Don't the rules for milestone 9 say
that the technical committee must make all reasonable efforts to accomodate
public review comments?"  The Secretariet wrote the committee.  Everybody on
the committee from companies such as Sun who had bee prohibited from voting
no for technical reasons all jumped up and cried "procedural violation" and
voted against forwarding the standard.  Scheifler stormed out.

I heard later than Scheifler wrote an angry letter to the Secretariet saying
"how dare you listen to that one lone consultant when I have the backing of
all of these major companies?"  The response was "Didn't you read our rules
before joining?"

Of course, by the time all of this settled out X was entrenched setting back
the state of UNIX UI for a long time.  A couple of decades ago I bough a Sun
Ultra-60 and asked whether it was worth paying for the dual processor version.
The answer that I got was "Yes.  You need one processor to run X and another
for everything else."

Wrapping this up, I have a section in the book that I'm writing where I talk
about how to design a good API.  I pose the question of why none of the original
Apple Mac API published in 1985 taking about 1,200 pages is in use today
whereas almost all of the UNIX V6 API published in 1975 taking 321 pages is
still in use and has been copied by many other systems.  I'm sure that everyone
on this list knows the answer.

X suffers from the same problems as the original Mac API.  Scheifler et. al.
didn't really do any system level design and modelling.  I know this because
I discussed it with Scheifler at an ANSI meeting in Tulsa, the only place that
I have travelled to on business that had no redeeming qualities.  He said "I
don't believe in models because they predispose the implementation."

Had he done some real design work and looked at what others were doing he might
have realized that at its core, X was a distributed database system in which
operations on some of the databases have visual side-effects.  I forget the
exact number, but X includes around 20 different databases: atoms, properties,
contexts, selections, keymaps, etc. each with their own set of API calls.  As
a result, the X API is wide and shallow like the Mac, and full of interesting
race conditions to boot.  The whole thing could have been done with less than
a dozen API calls.

Wrapping this up on a happy note, some years ago I was hanging out yakking at
the Hacker's Conference when this guy I didn't recognize due to hair loss came
up to me and said "I'm not going to say that you weren't an asshole because
you were, but you were right."  It was Keith Packard who was trying to get X
running on the OLPC and had run into the issue of clients allocating server
memory that couldn't be freed.  Been good friends since.  Same with Gettys.

Well, that's the whole sordid take from my point of view.  Hope that you
enjoyed it.

Jon