[NCLUG] Re: Thoughts on Linux Users

[Chad Perrin]

On Thu, Nov 15, 2007 at 02:08:14AM -0700, John L. Bass wrote:
> Chad Perrin <perrin at apotheon.com> writes:
> > There's little I find as odious as argument from authority, and you do
> > that a *lot*.  No wonder I have my "knickers" in a knot.
> 
> and you don't?

Point out a single instance where I've argued from authority, please.
Put up or shut up.


> 
> > I don't disregard the fact that some specious percentage guesstimate of
> > users avoid the CLI at "any cost" -- I just don't regard that as a sign
> > that the CLI is "obsolete" or "evil".
> 
> Then don't ..."obsolete" or "evil" are your words.

I didn't say they were your words.  They're just your implications.


> 
> > Who the *hell* said anything about "going back to character interfaces"
> > and "forcing users to abandon the GUI's[sic]"?  The irony is actually so
> > strong here it smells.
> >
> > What you *did* say is this, by the way:
> >
> >    native GUI support as a general and primary user interface
> >
> > Thus, you *did* say something that roughly equate to what I said above,
> > namely that you want to eliminate the CLI as native, primary interface.
> > Note that I didn't say you'd necessarily want to eliminate *all*
> > potential CLI functionality, and made a point of saying that you might
> > possibly condone a secondary text-based interface like a macro system.
> 
> There is a big difference actually ... has to do with reading english.
> 
> "native GUI support as a general and primary user interface" means EXACTLY
> what is says, and not a bit more ... the primary user interface. Nothing
> I said implied that the CLI would be removed, the implication is that it
> becomes secondary if the GUI is primary.

. . . and as I pointed out, you want to eliminate the CLI "as native,
primary interface".  There can only be one such thing.  Please argue
against something I said, not something you're imagining I said because
it's easier to refute.


> 
> >   1. I never said I believe that "advancement comes without studing[sic]
> >   both the good and the bad first", or anything that even hinted at such
> >   a conclusion.
> 
> True ... just as I never said that I was a proponent of several technologies
> you went off on a rant and charged me with pushing.

Uh . . . no, I didn't.  Again -- where are you getting this stuff?


> 
> >   2. I never argued that "doing so somehow embraces those failed
> >   choices," either.  You're just making crap up out of thin air here.
> >   Remember the bit about irony and smell?
> 
> The crap, is just yours ... as you quote below, I was just responding to your
> half baked assumptions.

I quoted you directly in your statement that I argued that "doing so
somehow embraces those failed choices," and you have failed to either own
up to that error or dispute it.  All you've done here is say "The crap,
is just yours", in some sort of kindergarten-style "I know you are, but
what am I?" feat of logic.  Will you address this at some point?


> 
> >   3. Something you *did* say:
> >
> >     You also need to clearly understand the fundamentals of GUI based
> >     architectures, which requires solid study of the Plato, Alto, Lisa,
> >     evolution of the Apple OS's, as well as MSWin and X11/Gnome/KDE.
> >
> >   I made an assumption, here -- that you were not saying we should
> >   study X11, GNOME, or KDE for *good* qualities.  You also said:
> 
> And that assumption was wrong, and you proceeded to rant based on that
> assumption puting missplaced words in my mount. ... your crap, not mine.

So . . . you *like* X11/GNOME/KDE, but you also *hate* it.  Perhaps you
could sort out the inherent contradictions in your statements for me.


> 
> What I said was that they needed to be studied, citing them as prior art.
> The implication is that they be studied for both their successes and failures.

Uh-huh.  Did you notice that you essentially said that X11, GNOME, and
KDE were all failures in terms of advancing the state of the art when you
said there hasn't been any innovation in that realm in the last 20 years?
Perhaps you aren't aware that the KDE project (the older of the two) was
only founded in 1996 -- eleven years ago, which is *less* than 20 years
ago.


> 
> >     
> >     UI and operating system innovation stopped dead for 30 years ...
> >     failing to advance the art as hordes of programmers set out to clone
> >     what should have been a dieing[sic] UNIX/X11 standard, and kept it
> >     revived for 20 years past it's point of innovation on a desktop.
> >
> >   So . . . unless my assumption was mistaken, and you were actually
> >   saying *good* things about X11, GNOME, and KDE, you *did* indeed say
> >   that nobody has been doing anything useful with GUI design in the Unix
> >   world for the last twenty years, and you *did* use GNOME and KDE as
> >   your examples thereof.
> 
> Your assumption is both right and wrong ... there are both good and bad
> things about each of those technologies. That you assume less, and rant
> about your missplaced assumptions is your problem.

Well, then -- you only said that nobody has been doing anything useful
with GUI design in the Unix world for the last twenty years, and GNOME
and KDE were *not* actually intended as examples of that, judging by the
inescapable implications of your previous words.  I'm not sure how KDE
and GNOME could be anything *but* examples of that, since your statements
cover all the realm of GUI design in the Unix world -- which includes KDE
and GNOME -- but hey, it's your party.


> 
> > > > 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.
> >
> > So . . . slower systems are the answer to poor performance?  I never
> > would have guessed.
> 
> How did you ever come up with such a half baked conclusion? Since you want
> to be the expert, and have a difficult time with authority, please enlighten
> us.

I came to that conclusion based on this:

  1. You seem to think the MIT Exokernel and GNU HURD kernel are better
  than any of the available Unix-like system kernels in their design, and
  thus we should be using them (despite the fact that the GNU HURD
  basically *is* a Unix kernel).

  2. One of the reason nobody is using them is that it's difficult to eke
  reasonable operational speed out of a complete OS built on either of
  them.

  3. Your complaint with Linux and FreeBSD kernels is, at least in part,
  that they don't perform well.

  4. The Linux and FreeBSD kernels are being used widely in part because
  operational speeds greater than can currently be had with, say, the GNU
  HURD kernel, are achievable.

  5. Thus, your measure of performance must involve allowing the system
  to run more slowly.

QED

That appeal to ridicule nonsense with the "you want to be the expert"
line is pretty silly, too, by the way.


> 
> Amdahl's law gives us a clear picture of where to look for performance gains.
> When cache faults to memory are 250 times slower than cpu cycles, and there
> are a lot of cache faults, then continuing to increase processor performance
> yeilds increasingly smaller performance gains. That has been the state for
> some time. To fix the performance problems, we need to address cache faults
> to memory. That problem is the direct result of many layers of indirection
> in the kernel and poor data locality -- a software architecture problem.
> 
> What I said above, is that those of us that are experts in UNIX system performance
> grew concerned about this problem back in UNIX SVR4 days, and that problem
> is worse with Linux today ... and with hardware today when the cpu clock
> to memory cycle time ratio is even higher.

That's great.  The examples you provided of kernels that are the "right
direction" still fail to perform up to the requirements of most people
doing real work in the real world, however -- and until that discrepancy
is rectified, all the performance-related theory in the world won't
change the fact that where the rubber meets the road they still don't
perform sufficiently to satisfy enough people to actually become the much
anticipated technological revolution you want.

Thus, as was my point all along, something other than just poking fun at
Linux and FreeBSD as failures is needed -- like continuing to advance the
state of the art, not just in systems nobody's using yet, but in systems
people *are* using, too.


> > > 
> > > Clearly expanding on the UNIX SVR5 bloat in the way that current linux
> > > releases have, is the wrong direction.
> 
> > Maybe so.  Maybe you've just completely ignored my discussion of the
> > Linux kernel architecture where the traditional monolithic kernel design
> > approach has been gentled a bit by kernel modules.  Maybe you've just
> > completely failed to explain how SVR5 bloat has anything at all to do
> > with BSD Unix, too.
> 
> Actually I didn't ignore it at all. I was clear that it's increasing size
> and number of layers of indirection is causing serious problems with cache
> and memory aliasing resulting in excessive and unpredicatable cach to memory
> faulting. This "bloat" is a serious problem.

A few points are begging to be made here:

  1. The Linux kernel has, in some respects, cut down on the SVR5 bloat
  to which you refer by way of providing that modular monolithic kernel
  architecture.  While it is bloating over time (something that concerns
  me as well), that is in respect to its own previous versions -- and is
  not directly tied to SVR5 in any way.

  2. If you want to eliminate indirection, something like GNU HURD or the
  MIT Exokernel is exactly the wrong direction.

  3. You still haven't addressed the matter of how SVR5 bloat has
  anything at all to do with BSD Unix.


> > > 
> > > > 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.
> 
> > You're long on name-dropping and insults to any and all developers
> > working on open source OS design that aren't building their OSes around
> > something like the MIT Exokernel, but pretty short on saying anything
> > substantive.  You're also long on (apocryphal, at best) accusations of
> > misrepresentation, but short on accurate representation of what I have
> > said in return.
> 
> I'm sorry that you are having a difficult time with being an objective
> Linux evangelist. Everything has both it's good and bad points. Being
> open about linux faults is never an insult as you are suggesting.

I'm not a Linux evangelist at all.  I guess if I'm not a Linux
evangelist, I would indeed have a hard time being an "objective Linux
evangelist" since a prerequisite of that is being a Linux evangelist.

There's far more to what you're doing than "being open about linux[sic]
faults".  You're saying that nothing in the realm of Unix-like OSes has
produced innovation at all for at least twenty years.  In other words,
you're saying that all the blood, sweat, tears, and ingenuity applied to
development of SCO UNIX, Solaris, FreeBSD, OpenBSD, the Linux kernel, and
a truckload of others has amounted to nothing but perpetuating a mistake,
and all those developers are doing nothing but spinning their wheels.
The obvious conclusion would be that all those developers are
congenitally incapable of innovatoin, or perhaps maliciously unwilling to
contribute their efforts to advancing the state of the art.

If I was a core Linux developer, I'd be insulted by that.

I'm quite open about Linux faults.  I just think it also has value and is
not an evolutionary dead end so behind the times it was stillborn sixteen
years ago.


> 
> The insults have been yours, mostly because you hastily jump to conclusions
> and are frustrated that someone dares to be objectively candid about the
> faults in the current Linux product and it's direction. You have decided to
> be openly sarcastic and less than civil, while lacking the ability to openly
> discuss the problems and provide your own suggestions for improving the areas
> that need it.

Show me an insult from any previous email to back up that accusation,
please.  Quote me.


> 
> I did my several years on the UNIX standards committee, even released code into
> the public domain so it could be included in the standard ... file locking.
> If you have problems with that first hand knowledge and experience with both
> the people and the technology .... get over it. I've done my 20 years as a
> systems programmer, and with that comes experience thats invaluable in any
> discussion about where to proceed in the future.

I don't have any problem with the fact you have first hand knowledge.  I
have a problem with the fact that you think name-dropping entitles you to
try to make arguments without evidence or a logical progression of ideas,
and be taken at your word nonetheless.


> 
> My direct observation, and suggestion, is that we need to either start over, or
> seriously overhaul Linux to address fitting it's working sets into the available
> technologies. Dennis and Ken decided to start over for a number of reasons, with
> their Plan 9 (see the Plan 9 FAQ: What Unix Problems Were Too Deep to Fix?)
> RMS felt the same way, in doing HURD.

That's great.  I never actually took issue with any of those ideas --
that perhaps we need to develop something new, something that isn't a
continuation of the Unix architecture in some sense, or that it needs a
severe overhaul at some point.  I took issue with the statements that
there hasn't been any innovation in the Unix world for the last twenty
years, that text is somehow anathema except as a thin veneer over a GUI,
and so on.


> 
> There is a problem with equating "Linux the OS" with "Linux the Distribution".
> It's the distribution that makes what most people consider Linux great. The
> OS, however has some serious problems for a number of application areas. Ditto
> with some toolset areas, which we can also discuss if you can be objective.

I'm not sure what you're even saying here.  A distribution *is* an OS.
Are you using "OS" to refer to the kernel, perhaps?


> 
> > I am unimpressed.  You think you can do better?  Show me the code.
> 
> That goes both ways ... show me your code and experience to solve the problems
> presented ... since you so passionately wish to discredit my experience and
> observations.

I'm not the one saying we have to throw it all away.  You're the one
making a positive assertion.  You're the one claiming it can all be done
better, and we're all idiots for not having done better starting twenty
years ago.  You're the one with something to prove here -- something that
can be proved, and solved, with fresh code.

Get cracking.


> 
> You have a strong problem with others experience and position of authority,
> yet ... you so freely claim that without any credientials whatsoever. So far,
> you haven't made any suggestions about how to improve Linux. Just personal
> attacks to discredit and discourage any discussion which includes faults with
> the Linux OS and Distribution.

Nope.  I think that, if that's what you think my "problem" is, you have
some "strong" problems with concepts like logical validity and fallacy.
My arguments stand or fall on their own -- I don't present credentials in
part because credentials do not make my arguments any more or less valid.

I haven't made any suggestions about how to improve Linux because you're
the one that seems to think Linux hasn't improved at all in its sixteen
years of life, or that the Unix archetype hasn't improved at all in the
last twenty (or, at least, hasn't seen any "innovation").

Please quote my "personal attacks" from previous posts.  Again, put up or
shut up.


> 
> Or ... as I suggested, maybe it's just time to agree to disagree.

Feel free.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Anonymous: "Eat your crow early, while it's young and tender.  Don't wait
until it's old and tough."