On Sat, Feb 25, 2023, 8:29 PM Dan Cross <crossd@gmail.com> wrote:

> On Sat, Feb 25, 2023 at 9:40 PM Theodore Ts'o <tytso@mit.edu> wrote:
> > I think it's fair to say that in the very early days of Linux, most of
> > the people who were using it were people who kernel hackers; and so we
> > didn't have all that many people who were interested in developing new
> > windowing systems.  We just wanted to be able to have multiple xterms
> > and Emacs windows.
>
> This is another important thing to bear in mind: this predates the
> explosion of the world wide web; most people back then paradoxically
> ran a lot more local software on their machines (applications weren't
> de facto mediated by a web browser), but a lot of that software was
> simpler. xterm and a text editor and a lot of folks were good to go.
>

The graphical www... Lynx was a thing for a long time... spent a lot of
time looking for info on how too boot Linux to get it going. Usenet
archives and mailing lists searching for clues. www and gopher and wais..

> In fact, support for X Windows predated the development of a
> > networking stack; we had Unix domain sockets, so that was enough for
> > X, but we didn't have a working networking stack at that point!  I
> > would be running X, and then running C-Kermit to download files from
> > MIT over a dialup modem.
>
> !!
>
> > At that point, X windows wasn't *flaky* per se, but remember that back
> > then monitors were very persnicky about exactly what resolutions and
> > frequences they would accept.  And this was before monitors supported
> > EDID (Extended Display Identification Data), which allowed the X
> > server to figure out what the parameters were of the monitor.  So that
> > meant that configuring the X server with the correct resolution,
> > frequencies, etc., was tricky.  There were long and complex documents
> > explaining how to do it, and it was a very manual process.  If you got
> > the calculations wrong, the image might not be stable, but that wasn't
> > a software bug so much as it was a configuration error.
>
> Yeah, this: once you got something configured and working it wasn't
> like it crashed all the time or anything like that. But getting it
> working in the first place was challenging; it was a _far_ cry from
> today, where it seems like most of the time, X "just works" out of the
> box. Or even from most workstations of the era, which largely worked
> with little or no tedious configuration (because the vendor had done
> the hard work to bring X up on their hardware already).
>
> But on x86, I recall that even slight perturbations in a system could
> keep X from running. For example, one might have the right model of
> xfree86-supported video card, but from a manufacturing run of cards
> that did not work (because they used rev B of an internal component
> instead of A, perhaps). Or the card might not work on a different
> motherboard, etc.
>
> Getting it working could be a real exercise in frustration.
>

Taught me patience as I brute forced a solution... then worked backwards to
make the next one work faster.... front porches and backporches seemed
concrete when reading the svga howtos...  that died a flaming death when I
read data sheets... wasn't until I read video demystified that I started to
get it... and only then because I was working with video engineers that
explained the differences... so yea..  super frustrating...

> There were programs (for example, the most famous was the graphical
> > game "Tuxracer") which wrote directly to the frame buffer, but there
> > wasn't anyone who was interested in developing their own compositor.
> > We just wanted xterms and (later) Firefox to work!
>
> Firefox? Wow, talk about a Johnny Come Lately. :-) I can still
> remember compiling NCSA Mosaic on a SPARCstation 2. Those were the
> days...very painful days....
>

Yes... lots of pain and patches and rebuilding... on slow machines...

Warner

>         - Dan C.
>
>
> > As far as discussion about what should and shouldn't go into the
> > kernel, most people agreed that as much as possible, especially in
> > graphics land, should be out of the kernel.  The fact that we didn't
> > have a lot of graphics specialists in the kernel development
> > community, and that in those early days the vast majority of Linux
> > boxen where single user machines just sealed the deal.
>