<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 25, 2023, 8:29 PM Dan Cross <<a href="mailto:crossd@gmail.com">crossd@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, Feb 25, 2023 at 9:40 PM Theodore Ts'o <<a href="mailto:tytso@mit.edu" target="_blank" rel="noreferrer">tytso@mit.edu</a>> wrote:<br>
> I think it's fair to say that in the very early days of Linux, most of<br>
> the people who were using it were people who kernel hackers; and so we<br>
> didn't have all that many people who were interested in developing new<br>
> windowing systems.  We just wanted to be able to have multiple xterms<br>
> and Emacs windows.<br>
<br>
This is another important thing to bear in mind: this predates the<br>
explosion of the world wide web; most people back then paradoxically<br>
ran a lot more local software on their machines (applications weren't<br>
de facto mediated by a web browser), but a lot of that software was<br>
simpler. xterm and a text editor and a lot of folks were good to go.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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..</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> In fact, support for X Windows predated the development of a<br>
> networking stack; we had Unix domain sockets, so that was enough for<br>
> X, but we didn't have a working networking stack at that point!  I<br>
> would be running X, and then running C-Kermit to download files from<br>
> MIT over a dialup modem.<br>
<br>
!!<br>
<br>
> At that point, X windows wasn't *flaky* per se, but remember that back<br>
> then monitors were very persnicky about exactly what resolutions and<br>
> frequences they would accept.  And this was before monitors supported<br>
> EDID (Extended Display Identification Data), which allowed the X<br>
> server to figure out what the parameters were of the monitor.  So that<br>
> meant that configuring the X server with the correct resolution,<br>
> frequencies, etc., was tricky.  There were long and complex documents<br>
> explaining how to do it, and it was a very manual process.  If you got<br>
> the calculations wrong, the image might not be stable, but that wasn't<br>
> a software bug so much as it was a configuration error.<br>
<br>
Yeah, this: once you got something configured and working it wasn't<br>
like it crashed all the time or anything like that. But getting it<br>
working in the first place was challenging; it was a _far_ cry from<br>
today, where it seems like most of the time, X "just works" out of the<br>
box. Or even from most workstations of the era, which largely worked<br>
with little or no tedious configuration (because the vendor had done<br>
the hard work to bring X up on their hardware already).<br>
<br>
But on x86, I recall that even slight perturbations in a system could<br>
keep X from running. For example, one might have the right model of<br>
xfree86-supported video card, but from a manufacturing run of cards<br>
that did not work (because they used rev B of an internal component<br>
instead of A, perhaps). Or the card might not work on a different<br>
motherboard, etc.<br>
<br>
Getting it working could be a real exercise in frustration.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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...</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> There were programs (for example, the most famous was the graphical<br>
> game "Tuxracer") which wrote directly to the frame buffer, but there<br>
> wasn't anyone who was interested in developing their own compositor.<br>
> We just wanted xterms and (later) Firefox to work!<br>
<br>
Firefox? Wow, talk about a Johnny Come Lately. :-) I can still<br>
remember compiling NCSA Mosaic on a SPARCstation 2. Those were the<br>
days...very painful days....<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes... lots of pain and patches and rebuilding... on slow machines...</div><div dir="auto"><br></div><div dir="auto">Warner </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
        - Dan C.<br>
<br>
<br>
> As far as discussion about what should and shouldn't go into the<br>
> kernel, most people agreed that as much as possible, especially in<br>
> graphics land, should be out of the kernel.  The fact that we didn't<br>
> have a lot of graphics specialists in the kernel development<br>
> community, and that in those early days the vast majority of Linux<br>
> boxen where single user machines just sealed the deal.<br>
</blockquote></div></div></div>