[NCLUG] Re: Thoughts on Linux Users

[John L. Bass]

Chad Perrin <perrin at apotheon.com> writes:
> Thank goodness.  Until this email, you were starting to sound like a
> broken record.

Well probably time to agree to disagree. You have your knickers in a knot
arguing about things I didn't say or assert. You clearly believe that you
know more about the issues at hand, than the folks like Ken and Dennis
that believe starting from scratch is the only reasonable solution. And
disregard that 95% of folks avoid command line interfaces at any cost.
I'm sure you have a solution to the critical memory aliasing problems that
have developed from excessive internal interfaces and software layers that
leave systems limping from cache misses, that result from the poor architectural
design of the current systems.

John


I clearly didn't say or assert this:

> . . . and yet, you seem to want to eliminate the underlying text-based
> command interface, and just have the GUI (possibly with some kind of
> text-based macro system shoehorned into it, or more likely bolted on,
> with less pervasive control capability).  I can't help but think that
> such an opinion of how OS design should advance is incredibly naive, and
> worthy of someone who hasn't been working with anything but MS Windows
> and MacOS "classic" for the most part.

I can say that it's increadibly naive to believe that the industry would be
enhanced by going back to character interfaces, and forcing users to abandon
the GUI's.


I clearly didn't say or assert this:

> If GNOME and KDE are your primary examples of GUI design in the Unix
> world, I can certainly see how you think that nobody has been doing
> anything useful with GUI design in the Unix world for the last twenty
> years.  I'd think so too, if those were my examples.

You have to understand what's wrong with a design before you can do better,
as well as understand what works well. You are incredibly naive to belive
that advancement comes without studing both the good and bad first, or to
argue that doing so somehow embraces those failed choices.

> I find it interesting that you dismiss Linux and FreeBSD development so
> quickly, in light of your reference to things like HURD, the MIT
> Exokernel, and so on.  After all, such projects are still in the realm of
> academia rather than in that of widespread, commodity OS use, largely
> because of some practical failings that nobody has managed to figure out
> how to solve yet (performance being a big one).

performance is exactly the problem with the current Linux architecture, in
that it greatly exceeds the 4 and 8 way caches, with excessive aliasing and
faults to memory. That by the way, was ALSO the problem we saw with the
direction that UNIX was taking 20 years ago. Huge scaling problems. Huge
problems with minor code changes, or compiler changes, stacking the aliasing
up unprodictibly resulting in performances differences of 3X or more. That
was with a CPU clock to Memory cycle time ratio of 18. Today that ratio is
better than 250. It was masked for a while with Moore's law, which has come
to and end more or less. Now it's time to start cleaning up the code paths
and architectural problems which are creating the performance bounds.

> Ultimately, slimming things down to the level of the HURD or Exokernel
> level might be The One True Way.  The hybrid Mach/BSD kernel of
> OpenDarwin might be the next stepping stone.

Clearly expanding on the UNIX SVR5 bloat in the way that current linux
releases have, is the wrong direction.

> In the meantime, modular
> monolithic kernel design such as that used in the Linux and FreeBSD
> kernels seems to be the de facto Right Answer to getting things done
> while we wait for the technological revolution to overcome its own
> limitations.

yeah ... as shining examples of what not to do.

John