[TUHS] Mach for i386 / Mt Xinu or other

[scj@yaccman.com (Steve Johnson)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3928 bytes --]

I was responding to the comment about the stability of Linux for
product delivery.

Having a car with a transmission that works perfectly is of little
benefit if the engine and tires keep blowing up.

Linus does take responsibility for the kernel, and that is good.  But
nobody seems to take responsibility
for the other stuff, and that causes a ton of problems.

Steve

----- Original Message -----
From: "Larry McVoy" <lm@mcvoy.com>
To:"Steve Johnson" <scj at yaccman.com>
Cc:"Larry McVoy" <lm at mcvoy.com>, "Joerg Schilling"
<schily at schily.net>, <tuhs at minnie.tuhs.org>
Sent:Mon, 20 Feb 2017 15:18:42 -0800
Subject:Re: [TUHS] Mach for i386 / Mt Xinu or other

 I don't see how it is far to lay the userland issues at the feet of 
 Linus, he does the kernel. He's bitched about the same GCC issues
 as you are.

 And window managers? What does that have to do with Linus?

 On Mon, Feb 20, 2017 at 03:16:14PM -0800, Steve Johnson wrote:
 > I too have worked with Linus, and agree with the good programmer
and
 > good architect.
 > I think he managed the project well for quite a while, but never
quite
 > recovered from the
 > GNU incursions.
 > 
 > As far as stability and portability is concerned, GNU is a
disaster.??
 > Even when a feature is
 > the same across different architectures the option names and values
 > are often different.
 > In one company I worked for we had two releases nearly derailed
 > because of Linux/GCC
 > issues.?? In one case, the way locales worked was different between
 > different versions of
 > Linux.?? In another case, GCC simply silently removed an option
that
 > we depended on and we
 > nearly shipped a product that would have bombed out if the user had
 > already upgraded
 > to the newest GCC.
 > 
 > In terms of following the Unix philosophy, the widow managers on
Linux
 > are getting more
 > bizarre by the year.?? Hitting a key at random by mistake can cause
 > windows to disappear,
 > screens of unknown utility to appear, everything to disappear,
etc.??
 > Setting options to try to 
 > achieve some kind of consistency is totally different in each
 > system.?? Etc. etc.???? There seems 
 > to be no larger organizing principle at work...
 > 
 > ----- Original Message -----
 > From: "Larry McVoy" <lm at mcvoy.com>
 > To:"Joerg Schilling" <schily at schily.net>
 > Cc:<tuhs at minnie.tuhs.org>
 > Sent:Mon, 20 Feb 2017 14:24:57 -0800
 > Subject:Re: [TUHS] Mach for i386 / Mt Xinu or other
 > 
 > Oh brother.
 > 
 > On Mon, Feb 20, 2017 at 07:14:44PM +0100, Joerg Schilling wrote:
 > > Larry McVoy <lm at mcvoy.com> wrote:
 > > 
 > > > Linus had the qualities of being a good programmer, a good
 > architect,
 > > > and a good manager. I've never seen all 3 in a person before or
 > since.
 > > 
 > > My memory is different. He claims that his intention is to keep 
 > > kernel/userspace interfaces stable, but given the fact that this
 > did never 
 > > happen, I tend to believe that he lacks the understanding on what
 > all is part 
 > > of the kernel/userspace interface.
 > 
 > So you're taking on the guy who won the Unix wars, has stayed in
 > charge for
 > a couple of decades, created the OS that runs on 498 of 500 super
 > computers,
 > the OS that runs on more phones than apple's phones, tablets, and
 > computers
 > combined?
 > 
 > I've worked with Linus, I know him pretty well. I stand by my
 > description
 > above and nothing you've said has changed (and isn't likely to).
 > 
 > As for interfaces, huh. I've got two decades of supporting a
 > commercial
 > product that uses file system, networking, VM interfaces and I
can't
 > remember a time were we had to change something because Linux broke
 > an API.
 > 

 -- 
 ---
 Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170220/849b673f/attachment.html>