All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rick Hohensee <humbubba@smarty.smart.net>
To: jesse@cats-chateau.net
Cc: linux-kernel@vger.kernel.org
Subject: Re: The Joy of Forking
Date: Mon, 25 Jun 2001 04:03:54 -0400 (EDT)	[thread overview]
Message-ID: <200106250803.EAA20874@smarty.smart.net> (raw)
In-Reply-To: <01062422482200.18805@tabby> from "Jesse Pollard" at Jun 24, 2001 10:34:42 PM

> 
> On Sun, 24 Jun 2001, Rick Hohensee wrote:
> >2.4.5 is 26 meg now. It's time to consider forking the kernel. Alan has
> >already stuck his tippy-toe is that pool, and his toe is fine.
> >
> >	forget POSIX
> >		The standards that matter are de-facto standards. Linux is the
> >		standard. Congratulations. Take your seat in the chair for 
> >		First Violin. 
> 
> NO. I port too many programs both ways. I need POSIX compliancy as much as
> is possible. That way the programs will compile and go among Linux, UNICOS,
> IRIX, Solaris, AIX, and sometimes HP-UX.

That's fine for things unix does well. Realtime is one counterexample. 

> 
> >	rtlinux by default
> >	no SMP
> >		SMP doesn't scale. If this fork comes, the smart maintainer
> >		will take the non-SMP fork.
> 
> Depends on platform and bus. From reports, it seems to scale just fine on
> non-intel systems.

Big expensive systems. Non-desktop systems. Non-end-user systems. And
clustering will eat its lunch eventually anyway.

> 
> >	x86 only (and similar, e.g. Crusoe)
> 
> Again, Linux is the only system that CAN run on anything from PDA thorough
> supercomputer clusters.
> 

NetBSD claims 24 platforms. Forths run on everything you've never heard of
below a PDA. 


> >	mimimal VM cacheing
> >		So you can red-switch the box without journalling with
> >		reasonable damage, which for an end-user is a file or two.
> >		Having done a lot of very wrong things with Linux, I'm 
> >		impressed that ext2 doesn't self-destruct under abuse.
> 
> Not if you want some speed out of it.

Again, throughput is a server thing. 

> 
> >	in-kernel interpreter
> >		I have one working. It's fun.
> 
> VIRUSES, VIRUSES, and MORE VIRUS entry points. Assuming you mean both
> translator and execution at the same time.

And assembler. This is called get your hands greasy. Fun. Your box. Not
the admin's box. 

> 
> >	EOL is CR&LF
> >		The one thing Dos got right and unix got wrong. Also, in my
> >		2-month experience in a cube on a LAN, the most annoying thing
> >		about trying to be a Linux end-user in a Dos shop. Printers
> >		are CRLF, fer crissakes.
> >		This is not a difficult mod, but it's a lot of little changes
> >		throughout a box. Things that look for EOLs are the part that
> >		has to be fixed by hand, and can be inclusive of CRLF and LF.
> 
> I've used both. They are equivalent. Live with it.
> 

We disagree, but I wont rant about the phone company breaking a perfectly
good telegraphy protocol called ASCII.

> >	Plan 9-style header files structure
> >		Plan 9's most amazing stuff to me is the subtle refinements,
> >		like sane header files. Sane C header files, _oh_ _my_ _God_. 
> 
> As long as source code portability is maintained.

Dennis Ritchie, who signs the checks for the people that wrote Plan 9,
said an interesting thing about portability. He said "good code is
portable code." I infer from that, and from the Plan 9 sources, and from
the design of unix and the two-character commands in /bin/, that he
relates good very strongly with simple. Not slavish adherance to
standards. Plan 9 C isn't ANSI, for example. The unix portability suite is
called "ape".

> 
> >	excellent localizability
> >		e.g. kernel error strings mapped to a file, or an #include
> >		that can be language-specific. My DSFH stuff also. 
> 
> This is quite reasonable. Actually, unless you are referring to Kernel internal
> error codes, it's already done with perror.
> 
> >
> >What about GUI's, and "desktops" and such? They're nice. They are
> >secondary, however. The free unix world doesn't often enough make the
> >point that GUI's are much more important when the underlying OS sucks,
> >which it doesn't in Linux. 
> 
> If you only use a compute/disk server. Otherwise you are saying "no desktop
> publishing, word processing, or image analysis".
> 
> Are you still using DOS only?
> 

I haven't started X in about a year. I read pdf's as jpegs, I have Xaos
running in SVGA, and so on. Not-unix != Dos . I don't dislike X
particularly, but I live in what I ship, and for maintenance I can't keep
up with console, considering that I'm doing a bit more than just bundling
things up.

> >In short, an open source OS for end-users should be very serious about
> >simplicity, and not just pay lip-service to it. There is evidence of the
> >value of this in the marketplace. What doesn't exist is an OS where
> >simplicity is systemic. This is why end-user issues pertain to the kernel
> >at all. This is how open source should be. Simple, or at least clear,
> >through and through. Linux has lost a lot of simplicity since I got into
> >it in '96, and that is a loss.
> 
> For the most part, the base Linux appears simple to the user. There are no

Which distro appears simple to the user? 


> desktops to worry about. Desktops are an application, not part of Linux at all
> It is becoming better for the administrator. As better desktops are developed,
> it is becoming for "user friendly".

Thanks for replying civilly to something you clearly don't agree with.
Basically, your reply says to me that kernel hackers can't imagine unix as
an end-user OS. Your points are all "that will suck as a server". Of
course. A solid true multi-user open source operating system is a solid
base for a variety of things.

Rick Hohensee
www.clienux.com


> 
> -- 
> -------------------------------------------------------------------------
> Jesse I Pollard, II
> Email: jesse@cats-chateau.net
> 
> Any opinions expressed are solely my own.
> 


  reply	other threads:[~2001-06-25  7:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-24  9:50 The Joy of Forking Rick Hohensee
2001-06-24  9:48 ` Jeff Garzik
2001-06-24  9:50 ` George Bonser
2001-06-24  9:54   ` Alexander Viro
2001-06-24 10:01     ` George Bonser
2001-06-24 13:46   ` Luigi Genoni
2001-06-24 14:50     ` Rob Landley
2001-06-25  7:24       ` Rok Papež
2001-06-24 15:13     ` Rik van Riel
2001-06-24 16:31       ` is IRQ enabled or disabled ? Hilik Stein
2001-06-24 17:22 ` The Joy of Forking Horst von Brand
2001-06-26  0:04   ` Rick Hohensee
2001-06-26  0:09     ` Shawn Starr
2001-06-25  3:34 ` Jesse Pollard
2001-06-25  8:03   ` Rick Hohensee [this message]
2001-06-25  9:32     ` Ben Ford
2001-06-25 10:37     ` Luigi Genoni
2001-06-25 14:05     ` Jesse Pollard
2001-06-28  0:11     ` Troy Benjegerdes
2001-06-25  9:23 ` Matthias Andree
  -- strict thread matches above, loose matches on Subject: below --
2001-06-25  9:14 Heusden, Folkert van

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200106250803.EAA20874@smarty.smart.net \
    --to=humbubba@smarty.smart.net \
    --cc=jesse@cats-chateau.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.