Re: The Joy of Forking
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
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
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
> > 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
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
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 > > > 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
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
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
Re: The Joy of Forking
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
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
>> 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
> > 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 > > 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
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 CRLF 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
RE: The Joy of Forking
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
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
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
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
Re: The Joy of Forking
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
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 CRLF 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
Re: The Joy of Forking
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
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
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
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 > 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
Re: The Joy of Forking
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
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
> > 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
> 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
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
> 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
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/
The Joy of Forking
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 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 - 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/
The Joy of Forking
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 CRLF 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 - 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
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/
RE: The Joy of Forking
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
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
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
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
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
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
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 CRLF 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,
