The Joy of Forking

The Joy of Forking

[Rick Hohensee]

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.

The "thou shalt not fork" commandment made sense at one point, when free
unix was a lost tribe wandering hungry in the desert. When you have a
project with several million users that has a scope that simply doesn't
scale, it doesn't. Forking should be done responsibly, and with great joy.
As in nature, software success breeds diversity. Linux should diversify.
This is cause for celebration, ceremony, throwing of bouquets and so on.

I have done a few trivial things that people with rather shallow ideas of
what unix is about have excoriated as "NOT UNIX!". So far that's been
absurd, but my stuff is getting more intrusive. Linux is far more
interesting to me for it's general usefulness and openness, which are
inextricably related, than for it's unixness, although unix is certainly
beautiful.

Alan was going to file for divorce over dev_t. Isn't is funny how
estranged couples so often are so much alike? dev_t is crucial, of course,
but it's not the biggest geological fault in the kernel. SMP is. I have
dropped hints about this before. An SMP system is more fundamentally
different than UP than a 386 is different than other big microprocessors.

As I mentioned that Steve Ballmer mentioned, Linux isn't getting any
traction on the client, the end-user desktop box. That's a huge and poorly
served market, so there are lots of tragically shallow ideas of how to
approach it. A few variations on the Linux theme are in order, that
preserve unixness, openness, but that don't have pretenses of being Big
UNIX(TM).

For a client-use Linux kernel, I suggest, and will be and have been
persuing, features and non-features such as...

	forget POSIX
		The standards that matter are de-facto standards. Linux is the
		standard. Congratulations. Take your seat in the chair for 
		First Violin. 
	rtlinux by default
	no SMP
		SMP doesn't scale. If this fork comes, the smart maintainer
		will take the non-SMP fork.
	x86 only (and similar, e.g. Crusoe)
	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.
	in-kernel interpreter
		I have one working. It's fun. 
	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.
	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_.  
	excellent localizability
		e.g. kernel error strings mapped to a file, or an #include
		that can be language-specific. My DSFH stuff also. 


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. 

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.

Rick Hohensee
www.clienux.com

Re: The Joy of Forking

[Jeff Garzik]

Every man forks.
Not every man really lives.

RE: The Joy of Forking

[George Bonser]

> 	no SMP
> 	x86 only (and similar, e.g. Crusoe)

Never 

RE: The Joy of Forking

[Alexander Viro]

On Sun, 24 Jun 2001, George Bonser wrote:

> > 	no SMP
> > 	x86 only (and similar, e.g. Crusoe)
> 
> Never 

YHBT. YHL.

RE: The Joy of Forking

[George Bonser]

> YHBT. 

Evidently so.

RE: The Joy of Forking

[Luigi Genoni]

> > 	no SMP
> > 	x86 only (and similar, e.g. Crusoe)
>
Is this a joke?
I hope it is.

Luigi

Re: The Joy of Forking

[Rob Landley]

On Sunday 24 June 2001 09:46, Luigi Genoni wrote:
> > > 	no SMP
> > > 	x86 only (and similar, e.g. Crusoe)
>
> Is this a joke?
> I hope it is.
>
> Luigi

Nah, I think it's an intentional troll.

Either that or somebody who's So naieve they honestly think that having 
different "text mode" and "binary mode" attributes of files (the cr/lf thing) 
can in some strange way actually improve a system.  (Justifying it with the 
way printers work when sent an ascii text stream, despite the fact that most 
printers these days receive postscript or something equally distant from 
ascii after the printer drivers get done with it.  And that text processing 
itself is, regrettably, moving to Unicode.)

Rob

Re: The Joy of Forking

[Rok Papež]

Hi!

On Sunday 24 June 2001 16:50, Rob Landley wrote:

> distant from ascii after the printer drivers get done with it.  And that
> text processing itself is, regrettably, moving to Unicode.)

Bad standard is better than no standard.

-- 
best regards,
Rok Papež.

RE: The Joy of Forking

[Rik van Riel]

On Sun, 24 Jun 2001, Luigi Genoni wrote:

> > > 	no SMP
> > > 	x86 only (and similar, e.g. Crusoe)
> >
> Is this a joke?
> I hope it is.

Must be. I mean, who wants "rtlinux by default" and a
FORTH interpreter in the kernel ? ;)

Either the guy's box got rooted and somebody sent an
email in his name or he's gone completely nuts.

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

is IRQ enabled or disabled ?

[Hilik Stein]

Hi
i was looking for a way to check during execution of some kernel code
whether hardware interrupts are enabled or disabled, but could not find a
way.
can anyone point me to the right place ?
thanks
Hilik

Re: The Joy of Forking

[Horst von Brand]

Rick Hohensee <humbubba@smarty.smart.net> said:
> 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.

Stop that nonsense. Alan Cox has _not_ forked anything, neither has Dave
Miller, or any of the arch maintainers. Alan has said several times that he
will sync up with Linus, and he still stages patches upwards. Alan doesn't
like the "all shall be devfs" ukase (and neither do I, BTW), and will
maintain non-devfs systems for the time being.

I do see the merit of some kind of devfs, but there still is a lot of stuff
that needs a more reasonable solution, so no thanks for now.
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Re: The Joy of Forking

[Rick Hohensee]

> 
> Rick Hohensee <humbubba@smarty.smart.net> said:
> > 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.
> 
> Stop that nonsense. Alan Cox has _not_ forked anything, neither has Dave
> Miller, or any of the arch maintainers. Alan has said several times that he
> will sync up with Linus, and he still stages patches upwards. Alan doesn't
> like the "all shall be devfs" ukase (and neither do I, BTW), and will
> maintain non-devfs systems for the time being.
> 
> I do see the merit of some kind of devfs, but there still is a lot of stuff
> that needs a more reasonable solution, so no thanks for now.

I've had quite a good two rants lately and will be happy to get on to
other things for now. My point is to think of devfs and dozens of other
things in the context of more than one Linux. Just a thought. 

Rick Hohensee
www.clienux.com

> -- 
> Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
> Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616
> 

Re: The Joy of Forking

[Shawn Starr]

Fork nothing, stop taking stupidity. The kernel SOURCES may be 26MB but
that does NOT mean you have to use every driver!

Shawn.

On Mon, 25 Jun 2001, Rick Hohensee wrote:

> >
> > Rick Hohensee <humbubba@smarty.smart.net> said:
> > > 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.
> >
> > Stop that nonsense. Alan Cox has _not_ forked anything, neither has Dave
> > Miller, or any of the arch maintainers. Alan has said several times that he
> > will sync up with Linus, and he still stages patches upwards. Alan doesn't
> > like the "all shall be devfs" ukase (and neither do I, BTW), and will
> > maintain non-devfs systems for the time being.
> >
> > I do see the merit of some kind of devfs, but there still is a lot of stuff
> > that needs a more reasonable solution, so no thanks for now.
>
> I've had quite a good two rants lately and will be happy to get on to
> other things for now. My point is to think of devfs and dozens of other
> things in the context of more than one Linux. Just a thought.
>
> Rick Hohensee
> www.clienux.com
>
> > --
> > Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
> > Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616
> >
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>

Re: The Joy of Forking

[Jesse Pollard]

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.
>
>The "thou shalt not fork" commandment made sense at one point, when free
>unix was a lost tribe wandering hungry in the desert. When you have a
>project with several million users that has a scope that simply doesn't
>scale, it doesn't. Forking should be done responsibly, and with great joy.
>As in nature, software success breeds diversity. Linux should diversify.
>This is cause for celebration, ceremony, throwing of bouquets and so on.
>
>I have done a few trivial things that people with rather shallow ideas of
>what unix is about have excoriated as "NOT UNIX!". So far that's been
>absurd, but my stuff is getting more intrusive. Linux is far more
>interesting to me for it's general usefulness and openness, which are
>inextricably related, than for it's unixness, although unix is certainly
>beautiful.
>
>Alan was going to file for divorce over dev_t. Isn't is funny how
>estranged couples so often are so much alike? dev_t is crucial, of course,
>but it's not the biggest geological fault in the kernel. SMP is. I have
>dropped hints about this before. An SMP system is more fundamentally
>different than UP than a 386 is different than other big microprocessors.
>
>As I mentioned that Steve Ballmer mentioned, Linux isn't getting any
>traction on the client, the end-user desktop box. That's a huge and poorly
>served market, so there are lots of tragically shallow ideas of how to
>approach it. A few variations on the Linux theme are in order, that
>preserve unixness, openness, but that don't have pretenses of being Big
>UNIX(TM).
>
>For a client-use Linux kernel, I suggest, and will be and have been
>persuing, features and non-features such as...
>
>	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.

>	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.

>	x86 only (and similar, e.g. Crusoe)

Again, Linux is the only system that CAN run on anything from PDA thorough
supercomputer clusters.

>	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.

>	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.

>	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.

>	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.

>	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?

>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
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".

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: jesse@cats-chateau.net

Any opinions expressed are solely my own.

Re: The Joy of Forking

[Rick Hohensee]

> 
> 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.
> 

Re: The Joy of Forking

[Ben Ford]

Rick Hohensee wrote:

>>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.
>

http://www.atheos.cx/
http://www.be.com/
http://www.apple.com/macosx/


-- 
:    __o
:   -\<,
:   0/ 0
-----------

Re: The Joy of Forking

[Luigi Genoni]

On Mon, 25 Jun 2001, Rick Hohensee wrote:

> >
> > >	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.
biprocessor are starting to be also end-user systems. About clustering,
actually it is very usefull, the most of times is a cost effective
solution to avoid to buy an unusefull 64 processor system,
but basically, in front of the computational needs you could have, it can
be used for different things in front of SMP systems.
It happens to me to have a cluster
composed by 4 dual processor systems, because i need a cluster, and i need
the single nodes to be dual processor. With an 8 nodes cluster composed by
uniprocessor I wuld give a mutch less efficient service to my users
computational needs.
>
> >
> > >	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.
yes, but to run on every kind of processor is a BIG strenght for Linux.
I don't think it is necessary to explain why.
>
>
> > >	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.
not true. Desktops have to be very responsive to users.
If a users run an application (read click on icon application),
let's say mozilla, and it will not start in about one second, he will
feel the desktop is slow. You need the best throughtput and speed
efficiency with disks on desktops.
Desktop users will never pay atention if the system is efficient, but if
it is fast in a way they can feel fastness. That means, fast to bring up
an application the same second the command is runned.
>
> >
> > >
> > >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.
??? I do not understand the point. I would say that is not a point.
>
> > >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?
I write for a review in Italy, we usually include distro's cd every month.
I have readers feed back. You would never say.
Newbies, who never saw a linux before, mandrake, red hat,
newbies coming from some Unix experience as users, slackware, someone
debian.
They write back to the redation, telling us how fonderfully easy it was,
and that they could not figure it was so easy.
>
>
> > 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.
I would say that users needs top feel the system to be fast.
That is true for desktop even more than for servers.
anyway, many of changes someone push to bring linux on the desktop will
make it slower, and that way users will never use it.
No desktop user will way 2 minutes to bring up an office suite.
Linux has a tradition it has to refer to, and inside of this tradition
Linux can find the way also for the desktop.
There is nothing wrong if you separe the OS from the desktop, and you say,
"desktops are on the application side". Then you, as OS can provide
the best performance as possible, disk speed, optimal memory usage, and so
on. Then the applications have to be able to use this optimal system at
best.

Luigi

Re: The Joy of Forking

[Jesse Pollard]

Rick Hohensee <humbubba@smarty.smart.net>:
> > 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. 

That depends entirely on the definition of "Realtime". UNICOS can be used
as realime (I understand it used to monitor nuclear reactors). If you need
microsecond response times, then unix of any flavor is not suitable. If you
mean "fast enough to watch DVDs" then you are into 100s of milliseconds where
Linux should be fast enough (with read-ahead caching).

> > >	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.

Alpha based systems and UltraSparc systems are used for desktops. As are MIPS.
They are also used for servers and clusters.

> > >	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.

When performance is below a PDA, fourth IS a reasonable system. It is also
reasonable for single purpose dedicated functions like sensor monitoring,
printers (without network, though it can be coerced). Fourth just isn't
that usefull (well... less so than other languages) on system that can afford
the software for compilers/linkers/multi-tasking/multi-processing
 
> > >	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. 

Refer to the DVD complaints about lack of performance. Linux does need
improving in the IO throughput. CPU throughput is a real pain if the
decryption isn't fast enough.
 
> > 
> > >	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. 

A kernel module to compile/link source code ???. The security hassels alone
arn't worth the effort. I've also seen reports of a "postscript" virus that
takes over a printer, and discards any output other than the person who
"printed" the virus; also (hazy memory) of taking over some printers to use
as a platform to launch other attacks. Don't like in-kernel interpreters.

> > >	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.

The phone company wasn't the first to do that - DEC PDP-8 systems also had
a tendancy to drop CR. Their "All-in-One" office hardware dropped both CR
and LF in favor of a record length field for text files (RMS-8/10/11
products - RMS => Record Management System). It was both faster and with smaller
files that way.

> > >	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".

Yup - yet another software layer to achive portability. Unfortunately, code
developed for Plan 9 isn't very portable; so it has to be done twice on the
same system. There is no standard for Plan 9, other than Plan 9 itself. This
has made it very difficult to make portability claims. POSIX was from the
UNIX base, and defined in an attempt to improve portability. It could be
better (the security and RT definitions are the "weakest"). But they are
standards. Linux attempts to meed the accepted standards where reasonable
and necessary to the developers. They too have to port application level
software among different systems.

> > >	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? 

For the most part, Red Hat. I use Red Hat for a general desktop base, but
prefer Slackware for the better controls over the system for things like
firewalls/Servers (also for fewer security problems caused by the additional
"auto-configuration" software that RH insists on creating).

> 
> > 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.

I was trying to say that mixing user-application interfaces into a kernel
results in poor everything. The kernel should do what kernels do best -
hardware resource management and security enforcement (could be shortened
to "hardware resource management" since security enforcement can be
considered part of "resource managment").

This frees the applications from also having to do hardware/security
functions (which they do poorly IMHO). It frees the user-application
interface from having to implement applications or hardware and security
enforcement.

Granted, better isolation is needed, and that is where KDE/Gnome (both a bit
bloated) and/or CORBA (even more bloated with accounting and distributed
access controls) were intented to fit. More areas of research and improvement;
but not part of the kernel.

And yes, X really really needs to be split into a device driver/module +
X display server. The current setup causes a LOT of problems that are
hard to diagnose. The recent addition of a frame buffer console goes a
long way to improvements, but isn't yet generic enough to support all
(enough? how many is enough?) graphics adapters. And fbdev doesn't yet work
for laptops well enough (at least the two I've tried with Red Hat).

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: The Joy of Forking

[Troy Benjegerdes]

On Mon, Jun 25, 2001 at 04:03:54AM -0400, Rick Hohensee wrote:

> > >	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.

You don't get much more end-user than a $2500 Dual Processor Mac G4. 
(And as soon as you say $2500 is a lot of money, I can probably find a 
dual CPU PentiumIII system for < $1000)

We would be perfectly happy if you have the time and ability to maintain a 
fork that can do all of this, and those of us that have more than one CPU 
type will be perfectly happy to ignore it.

-- 
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's 
why I draw cartoons. It's my life." -- Charles Shulz

Re: The Joy of Forking

[Matthias Andree]

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.
 
> For a client-use Linux kernel, I suggest, and will be and have been
> persuing, features and non-features such as...
> 
> 	forget POSIX

[junk]

> 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.

Don't feed the trolls. The underlying kernel is nothing compared to an
entire system. End-users don't mock with kernels but install their
vendor's RPM, plus compiled Linux kernels are usually so much smaller on
my machines than FreeBSD kernels. So just ignore this.

RE: The Joy of Forking

[Heusden, Folkert van]

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

What about NetBSD? :o)