Re: What Window Manager/Desktop Environment do you use, and why?

On Thu, 12 Jun 2025 21:49:40 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

Classic MacOS *almost* nailed this, if only it hadn't been so quick
to dismiss the keyboard and the command line (and were designed from
the start for preemptive multitasking and memory protection...) 

 
It took extra-cost hardware to do that stuff back then. That’s why
the Unix boxes cost so much more.

MMUs cost extra at the time, yes, but that changed pretty quickly - by
the time the 68030 rolled out in 1987 it was built in to the CPU (and
the Mac line adopted the '030 just a year later, with the Mac IIx.)
Unfortunately, as Andy Hertzfeld has written, there were a couple parts
of MacOS where they failed to "design ahead" for this; the transition
to 32-bit addressing was more complicated than it should've been as a
result, and I'm not sure if they ever did get memory protection going.
The memory model, while forward-thinking in some respects, also imposed
weird limitations on application heap size that never did get cleared
up 'til the OSX transition finally obsoleted the whole thing. It
*worked,* sure, but it could've been done a lot better from the get-go
even without an MMU.

https://folklore.org/Mea_Culpa.html?sort=date
https://en.wikipedia.org/wiki/Classic_Mac_OS_memory_management

As for pre-emptive multitasking, all you need for *that* is a timer
interrupt, which the Mac had from the very start. They just didn't
design with it even considered as a possibility, which made things
clunkier than necessary when they finally did embrace multi-tasking
later on:

https://en.wikipedia.org/wiki/MultiFinder

The Classic MacOS GUI was purpose-built for the technology of its
day, but it grew increasingly complex to cope as the technology
evolved. Same is true of every GUI. They don’t scale, or evolve
gracefully. That’s why they keep needing to be redesigned.
 
And that’s why a platform where the GUI layer is fully modular and
replaceable, indeed optional (*cough* Linux, BSD *cough*), is the
best- placed to cope with ongoing technological evolution in
computing.

I can't fully agree with this. The GUI layer in an OS certainly ought
to be modular enough that the rest of the system doesn't depend on it,
or it becomes difficult to use in server environments (and tends to
limit scripting/automation.) Classic MacOS certainly fell short on that
front.

But the *nix approach of treating it as a secondary (tertiary?) priority
tends to lead to exactly what we saw in the *nix world, historically: a
handful of disparate efforts that mostly tend to make it to "eh, good
enough" and never quite achieve *niceness.* X deferring behavioral
specifications to the WM/toolkit layer certainly made things more
modular...

...but the downside to that is there's fundamentally no such thing as a
*consistent* GUI experience in *nix-land; GTK programs work differently
from Qt programs work differently from Motif programs work differently
from the handful of programs that some lunatic really did write in raw
Xlib calls, and unless you're one of the extremely vanilla users whose
needs really *are* met by the default set of applications provided with
GNOME or KDE, you just *won't* reach a point of never having to *think*
about the differences.

It's better to have the ability to choose than to not have it; but it's
*nicer* to have and not *need* it. The *nix approach to the GUI, sadly,
achieves the first aim but never does fulfill the second.