From: Warner Losh <imp@bsdimp.com>
To: Dan Cross <crossd@gmail.com>
Cc: Paul Ruizendaal <pnr@planet.nl>,
The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: [TUHS] Re: Early GUI on Linux
Date: Sat, 25 Feb 2023 20:45:04 -0700 [thread overview]
Message-ID: <CANCZdfonbY4ENTEAwceT+id7umwsjwf8AwyThwbnf4P0rWXf_A@mail.gmail.com> (raw)
In-Reply-To: <CAEoi9W5DW9Z6n6YoqDxzEQGtQAjUqsJmBmxi1_o7AuZOFWmPog@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4377 bytes --]
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.
>
[-- Attachment #2: Type: text/html, Size: 5833 bytes --]
next prev parent reply other threads:[~2023-02-26 3:45 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-25 21:31 [TUHS] " Paul Ruizendaal
2023-02-25 22:49 ` [TUHS] " Dan Cross
2023-02-26 1:27 ` Larry McVoy
2023-02-26 0:39 ` Warner Losh
2023-02-26 1:14 ` Steffen Nurpmeso
2023-02-26 15:50 ` Leah Neukirchen
2023-02-26 16:13 ` Larry McVoy
2023-02-26 16:23 ` Leah Neukirchen
2023-02-26 16:32 ` Warner Losh
2023-02-26 16:39 ` Will Senn
2023-02-26 19:58 ` Dave Horsfall
2023-02-27 0:16 ` Adam Thornton
2023-02-27 10:09 ` Ralph Corderoy
2023-02-26 2:21 ` Jonathan Gray
2023-02-27 17:22 ` Paul Ruizendaal
2023-02-27 18:32 ` Warner Losh
2023-02-26 2:27 ` Will Senn
2023-02-26 2:30 ` Will Senn
2023-02-26 2:40 ` Theodore Ts'o
2023-02-26 3:28 ` Dan Cross
2023-02-26 3:45 ` Warner Losh [this message]
2023-02-26 5:24 ` John Cowan
2023-02-26 5:36 ` Steve Nickolas
2023-02-28 3:35 ` Dave Horsfall
2023-02-27 17:22 ` Paul Ruizendaal via TUHS
2023-02-27 17:59 ` Arno Griffioen via TUHS
2023-02-27 18:07 ` Warner Losh
2023-02-27 20:04 ` [TUHS] Generational development [was Re: Re: Early GUI on Linux] arnold
2023-02-27 20:08 ` [TUHS] " Chet Ramey
2023-02-27 20:22 ` arnold
2023-02-27 20:46 ` segaloco via TUHS
2023-02-27 21:04 ` Dan Cross
2023-02-28 7:59 ` arnold
2023-02-28 15:28 ` Clem Cole
[not found] ` <CAP2nic1STmWn5YTrnvFbexwwfYWT=pD28gXpVS1CVSfOOwxx7g@mail.gmail.com>
2023-02-28 15:50 ` [TUHS] Fwd: " Adam Thornton
2023-02-27 20:50 ` [TUHS] " Chet Ramey
2023-02-27 20:55 ` Bakul Shah
2023-02-27 21:01 ` segaloco via TUHS
2023-02-27 21:15 ` Chet Ramey
2023-02-27 21:22 ` Dan Cross
2023-02-27 20:30 ` [TUHS] Re: Early GUI on Linux Dan Cross
2023-02-28 1:10 ` Alexis
2023-02-28 1:27 ` Dan Cross
2023-03-01 16:39 ` Paul Ruizendaal
2023-03-01 16:54 ` Larry McVoy
2023-03-01 17:22 ` Paul Ruizendaal
2023-03-01 17:52 ` Larry McVoy
2023-03-02 1:17 ` Jonathan Gray
2023-03-02 4:28 ` Larry McVoy
2023-03-02 6:46 ` [TUHS] X timeline Lars Brinkhoff
2023-03-01 18:59 ` [TUHS] Re: Early GUI on Linux Theodore Ts'o
2023-03-02 7:27 ` arnold
2023-02-28 1:08 ` Jonathan Gray
2023-02-28 1:15 ` Clem Cole
2023-02-27 20:56 ` Will Senn
2023-02-27 22:14 ` Andru Luvisi
2023-02-27 22:31 ` David Arnold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANCZdfonbY4ENTEAwceT+id7umwsjwf8AwyThwbnf4P0rWXf_A@mail.gmail.com \
--to=imp@bsdimp.com \
--cc=crossd@gmail.com \
--cc=pnr@planet.nl \
--cc=tuhs@tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).