The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Dan Cross <crossd@gmail.com>
To: Paul Ruizendaal <pnr@planet.nl>
Cc: "tuhs@tuhs.org" <tuhs@tuhs.org>
Subject: [TUHS] Re: Early GUI on Linux
Date: Mon, 27 Feb 2023 15:30:14 -0500	[thread overview]
Message-ID: <CAEoi9W5ErcCG0W+jqHmWnsuBsB27JtUq77yei6tFaCtpAgoqgw@mail.gmail.com> (raw)
In-Reply-To: <A3308FD9-F130-48BA-903A-4F7AA6CF2CC3@planet.nl>

On Mon, Feb 27, 2023 at 12:22 PM Paul Ruizendaal via TUHS <tuhs@tuhs.org> wrote:
> Thanks all for the insights.  Let me attempt a summary.
>
> What it boils down to is that X arrived on Linux very early, because what the Linux hackers needed/wanted was a familiar terminal multiplexer.

While that was literally true, I think it was a little more nuanced.
I'd perhaps put it that people wanted their familiar environments.
Many people were used to running a lot of xterms on their
workstations, of course, but there were other X applications people
used regularly.

Some I remember where `gv` to look at PostScript documents, `xv` to
view image files, `gnuplot` could generate plots in a window, `xdvi`
to look at TeX/LaTeX output, and text editors like `emacs` had X
front-ends that offered syntax highlighting and the like; some folks I
knew liked `nedit`. `exmh` was my preferred email client for a while,
and things like `xman` (was there a `tkman`, too?) was nice. Some
system monitoring tools `xload` were considered essentials; `xbiff`
could be useful (I could have sworn there was a `tkbiff`, too). A
clock like `xclock` or `oclock` or something was also nice. Some folks
liked graphical newsreaders, chat programs (I guess IRC was a thing
back then, and I believe some `talk` client had an X front-end). There
was a fractal viewer that I thought was fun, but I don't remember it
much anymore (even the name...). Oh, and lots of games; I had a nice
Solitaire version that I can no longer recall the name of. `xeyes` was
cute, and running `xroach` was a popular (?) prank for an unsuspecting
(but amenable) colleague.

A lot of us spent a lot of time customizing our environments, and many
eschewed the vendor-standard environment. For instance, a lot of
people I knew used `twm` and derivatives (`ctwm` and `tvtwm` were
popular), and spent a lot of time tweaking menus and stuff to set
things up the way we liked. A lot of folks also wrote custom tools
using `tk` or `expectk`. Giving all of that up to run on Linux was a
bitter pill to swallow, so there was a real impetus to get X running
quickly. Personally, I kept my `tvtwm`-based environment going until I
switched to plan9 and then to the Mac as a daily driver. I'm not sure
I miss it, but at the time it was head-and-shoulders above anything
you could get on Windows or (classic) MacOS.

So it wasn't just that people wanted a "familiar terminal multiplexor"
as that people wanted the environments they had put a lot of time and
energy into building up for themselves, and again, that often meant X.

> It seems that the pattern persists till the present day (and yes, it matches with my own dev setup/needs). I wonder to what extent this is a generational thing though. Maybe today’s twenty-somethings spend their days in front of Xcode, VStudio, Eclipse, etc. more than using multiple terminals.

I think it probably depends on what people are doing. I more or less
switched to using VS Code for my editor, and I'm using a Mac Studio to
write this, but my desktop is still littered with terminal windows,
I've got a `drawterm` session open to my local Plan 9 network, and am
logged into a bunch of old systems (Multics, TOPS-20, VMS, an IBM
mainframe, CDC Cyber, RSTS/E, PR1ME), etc.

But the way we write software has changed pretty dramatically in the
last 3 or so decades. I used to start with an empty C file and write
my stuff. Things like linked-lists? Mostly implemented by hand. These
days, there are other languages and vast collections of libraries for
almost anything imaginable; much of what "programming" is today is
glueing together different libraries and making them interact in
sophisticated, often quite complex ways. I don't know that it's
better, nor that it's always worse, but it is qualitatively different.
So almost necessarily the toolsets and environment have changed
accordingly.

> This ties in with another observation on early window systems. The earliest Unix window system that I could find (i.e. documented) was NUnix from 1981/82. Its desktop was designed around the idea of a dozen or so top level windows, each one being either a shell window or a graphics canvas, with no real concept of a widget set, dialogs, etc., or even of sub-windows. This paradigm seems to have been more or less the same in the Blit terminal, and carried through in MGR, Mux and even as late as 8 1/2. In the context where this serves the needs of core user group, such makes sense.

It may be instructive to look at the early X window managers in this
regard.  One I remember was `uwm` (I think); I recall being struck
that it reminded me of rio when I saw it.

> It is in stark contrast with developments at the lower/consumer end of the market. The original Mac, GEM and Windows all placed much more emphasis on being a graphical user interface, with standard widgets and UI design elements. On Unix and X it remained a mess. It seems that this was both for technical reasons (X not imposing a standard) and for economic reasons (the Unix wars). Linux then inherited the mess and the core user/developer demographic had no need/wish/time to fix it.

I remember the X mantra was, "mechanism, not policy." Which was fine,
except that there wasn't much of even a default policy, which made X
(IMHO) a bit of a bear to program and meant that interfaces were
pretty wildly inconsistent across programs. By contrast, writing
simple programs to draw lines on the Mac was easy.

Interestingly, frustration with this caused an almost cambrian
explosion of new windowing environments within a few years of Linux's
arrival on the scene. From larger efforts like Gtk (and then GNOME),
KDE, GNUStep (which I guess might predate Linux, but not by much...),
etc, to less ambitious things components like fvwm and Enlightenment,
we kind of went from "OpenWindows or Motif or roll your own stuff
around twm or something" to a whole plethora of things. It's still a
bit of a mess, though.

> It makes me wonder when true graphical applications started to appear for X / Unix / Linux (other than stuff like terminal, clock, calculator, etc.). The graphical browser certainly is one (1993). StarOffice and Applix seem to have arrived around 1995. Anything broadly used before that?

Lots!  See above.

        - Dan C.

  parent reply	other threads:[~2023-02-27 20:31 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
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     ` Dan Cross [this message]
2023-02-28  1:10       ` [TUHS] Re: Early GUI on Linux 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=CAEoi9W5ErcCG0W+jqHmWnsuBsB27JtUq77yei6tFaCtpAgoqgw@mail.gmail.com \
    --to=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).