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.