Re: The Joy of Forking

2001-06-27 Thread 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' |  [EMAIL PROTECTED]
-"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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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

2001-06-25 Thread 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
> > 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 [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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

2001-06-25 Thread Rick Hohensee

> 
> Rick Hohensee <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
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

2001-06-25 Thread Horst von Brand

Rick Hohensee <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
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

2001-06-25 Thread Jesse Pollard

Rick Hohensee <[EMAIL PROTECTED]>:
> > 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
>

Re: The Joy of Forking

2001-06-25 Thread 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ž.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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

2001-06-25 Thread 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 trad

Re: The Joy of Forking

2001-06-25 Thread 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
---



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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

2001-06-25 Thread 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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

2001-06-25 Thread 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)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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

2001-06-25 Thread 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

Re: The Joy of Forking

2001-06-24 Thread 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 i

Re: The Joy of Forking

2001-06-24 Thread 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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

2001-06-24 Thread 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 [EMAIL PROTECTED] (spam digging piggy)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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

2001-06-24 Thread Luigi Genoni



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

Luigi


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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

2001-06-24 Thread George Bonser

> YHBT. 

Evidently so.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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

2001-06-24 Thread Alexander Viro



On Sun, 24 Jun 2001, George Bonser wrote:

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

YHBT. YHL.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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

2001-06-24 Thread George Bonser

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

Never 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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

2001-06-24 Thread Jeff Garzik

Every man forks.
Not every man really lives.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/