The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Larry McVoy <lm@mcvoy.com>
To: Paul Ruizendaal <pnr@planet.nl>
Cc: "tuhs@tuhs.org" <tuhs@tuhs.org>
Subject: [TUHS] Re: Early GUI on Linux
Date: Wed, 1 Mar 2023 08:54:46 -0800	[thread overview]
Message-ID: <20230301165446.GB26409@mcvoy.com> (raw)
In-Reply-To: <A925EAF7-9BA8-403E-83CB-81A9FEE9B305@planet.nl>

It's worth pointing out that X had won before Linux.  I was a contractor
in 1987, worked on all sorts of different workstations with all sorts of
vendor provided window systems, and the first thing I did was to bring
up my trusty X10R3 tape.  

The vendor windowing systems were all oh-so-great (according to the
vendors) but as a contractor, I could have cared less.  I wanted my
dev enviroment so I could get work done, learning the ins and outs of
$VENDOR's $WINDOW_SYSTEM was just a waste of my time, I'd be done and
on to the next job and all that specific knowledge was a waste of effort.

All of that predated my exposure to Linux (which was early, way before
Linux had networking or distributions, I brought it up from floppies).

As a useful (to me) aside, I got very good at what I call "pruning the
tree" when bringing up X10.  There were a ton of #ifdefs and (even then)
quite a few frame buffer drivers and there was no way I could have brought
it up in any reasonable time if I tracked down the root cause of each
reason it wouldn't compile.  So I got good at looking at the source,
going, huh, I don't need this and changing stuff like

int whatever_function_that_I_did_not_need(<args)
{
	/* lots of code that wouldn't compile */
}

to

int whatever_function_that_I_did_not_need(<args)
{
#if 0
	/* lots of code that wouldn't compile */
#else
	return (0);	/* or whatever meant success for that function */
#endif
}

I had very little actual understanding of the code, just barely enough to
guess that I didn't need something.  So it was way quicker to ifdef it
out and keep moving.

That skill has served me well over the years, you don't need deep
understanding to know you don't need $FEATURE.

On Wed, Mar 01, 2023 at 05:39:48PM +0100, Paul Ruizendaal wrote:
> Thank you for highlighting that!
> 
> Several folks had already hinted at such, but your comments make clear that by 1991 the X ecosystem had come out on top in a winner-takes-all dynamic: people wanted X because that had the apps, and the apps were for X because that was the most prevalent.
> 
> This also explains that MGR on Linux was so short-lived: although it provided the terminal multiplexing that was the key use case, it did not have the application ecosystem that was apparently already important enough to motivate people to make X run on Linux very early in its existence. I had always thought of those early X applications as little more than gimmicks, but apparently they were more appreciated than I thought.
> 
> 
> > On 27 Feb 2023, at 21:30, Dan Cross <crossd@gmail.com> wrote:
> > 
> > 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.

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

  reply	other threads:[~2023-03-01 16:54 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     ` [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 [this message]
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=20230301165446.GB26409@mcvoy.com \
    --to=lm@mcvoy.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).