[KLUG Advocacy] Linux Outpacing Macintosh On Desktops

[Peter Buxton]

Speaking of MacOS....

http://slashdot.org/article.pl?sid=02/09/26/0058238&mode=thread&tid=107

On Thu, Sep 26, 2002 at 09:29:40AM -0400, Adam Williams wrote:

> > X does not look as good on a local display as Windows or Mac.
> 
> Ok.  As someone who is red-green color blind it is self-defeating to
> argue on such a point.  But I can tell you that X looks *MUCH* better
> than it did when I first started using it in ~1993.

That's pretty much what I said. Apple's Mac didn't look so much better
than X in the '80's than it does today. See two more below.

> Again, here we are comparing Xt and ROM Mac.  Pragmatically, neither
> of these technologies exist anymore except as archaeological foot
> notes.

The fiend is in the footnotes.

> > Fast forward 18 years. We have the same gap.

See? That *was* my point. X is still not as pretty/simple/polished as
Windows/Macintosh, and none of the three is sitting still.

> I'm not so convinced of this.  It seems to depend in large part on the
> application.  Most Open Source spreadsheet simply gag on large
> spreadsheets anyway, including Open Office and Gnumeric.  I use
> massive spreadsheets in Star Office every day, scrolling seems fine
> (much better then OO, interestingly enough)

I'm referring to the way they draw on the screen. Windows is smoother
than any X app I've seen, even the advanced ones. I maintain that they
need to fix this before people will give them widespread acceptance. I,
as a technically-interested user, know that X opted for network
transparence first and double-buffering second. I see utility where
others see a lack of polish. Most people aren't like me at all.

> I'm all for extending X, replacing its rendering model, etc... to a
> point.  I think rendering, etc..., in kernel space is a VERY bad idea,
> but so long as I can disable it, so be it.  Performance at the cost of
> flexibility and stability just isn't real performance.

> Sure.  I'm not dissin' Aqua (or whatever they call that part of it
> now) as a solution or a technology.  I just think it would have been
> great, and possibly helped Apple's corporate adoption (which is still
> a big problem) had they built it as an X module.

Considering how they have leveraged every kind of existing tech to
create OS X in the first place, I think the fact that they didn't
leverage X is prima facie proof that they couldn't in the time allowed.
Perhaps they needed a fundamental change in X that would have rendered
them incompatible with every other X implementation in the world: since
the whole idea of X is the remote display, writing their own X-prime
protocol would have put their Activity in X, if you'll allow the pun.

I don't think the kernel needs to 'render' but the kernel already has
certain structures that facilitate rendering, e.g., DRI. I think the
kernel should provide certain timing functions and memory handlers for a
display server to leverage *if* it is there, and I think those services
should be as fast, general, powerful and stable as open(2). If X runs on
a server without those structures, or is exporting so that they may
exist on each machine but, with network lag, be unavailable, then the
functions normally provided by those structures would be either software
emulated or somehow 'thunked' so that their loss would be covered/
emulated/bandaged by the X server and client.

Your calculator-app doesn't have to explode if you don't have an FPU.
You can emulate it, for most of the same reasons we have virtual memory
and buffered disk writes, which are also emulations of non-existant
resources.

> To use such an application on a remote display one typically has to
> set a parameter to specifically disable that X feature.  The frame
> buffer support in recent kernels and hooks for kernel space video
> modules is also a part of this.

One would think X, being network transparent, would be network aware as
well and would know when it is being exported. It probably does, some
coder just didn't know how to do it. Or perhaps we have another lousy
design decision: transparency == ignorance. I hope not.

> Rendering - Modular.  So if it isn't good enough some one needs to get
> coding.  I don't know enough about the ins-n-outs of drawing a display
> to comment much on this.  There is a display postscript rendering module
> at http://dps.sourceforge.net/ for example.

I know. That's why I included the URL. But not everything is a module in
X--sometimes you have to go deeper.

-- 
http://www.killdevil.org/~peter