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&LF
The one thing Dos got right and unix got wrong. Also, in my 2-month experience in a cube on a LAN, the most annoying thing about trying to be a Linux end-user in a Dos shop. Printers are CRLF, fer crissakes.
This is not a difficult mod, but it's a lot of little changes throughout a box. Things that look for EOLs are the part that has to be fixed by hand, and can be inclusive of CRLF and LF.
Plan 9-style header files structure
Plan 9's most amazing stuff to me is the subtle refinements, like sane header files. Sane C header files, _oh_ _my_ _God_.
excellent localizability
e.g. kernel error strings mapped to a file, or an #include that can be language-specific. My DSFH stuff also.
What about GUI's, and "desktops" and such? They're nice. They are secondary, however. The free unix world doesn't often enough make the point that GUI's are much more important when the underlying OS sucks, which it doesn't in Linux.
In short, an open source OS for end-users should be very serious about simplicity, and not just pay lip-service to it. There is evidence of the value of this in the marketplace. What doesn't exist is an OS where simplicity is systemic. This is why end-user issues pertain to the kernel at all. This is how open source should be. Simple, or at least clear, through and through. Linux has lost a lot of simplicity since I got into it in '96, and that is a loss.
Rick Hohensee
www.clienux.com
Every man forks.
Not every man really lives.
Quoted 2 lines
no SMP
x86 only (and similar, e.g. Crusoe)
Never
Quoted 4 lines · George Bonser
Quoted 2 lines
no SMP
x86 only (and similar, e.g. Crusoe)Never
YHBT. YHL.
Quoted 1 line
YHBT.
Evidently so.
Quoted 5 lines
Quoted 4 lines
no SMP
x86 only (and similar, e.g. Crusoe)
Is this a joke?
I hope it is.
Luigi
Quoted 5 lines · Luigi Genoni
Quoted 3 lines
Quoted 2 lines
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)
is IRQ enabled or disabled ?
Hi
i was looking for a way to check during execution of some kernel code whether hardware interrupts are enabled or disabled, but could not find a way.
can anyone point me to the right place ?
thanks
Hilik
Quoted 7 lines · Luigi Genoni
Quoted 2 lines
Quoted 2 lines
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
Hi!
Quoted 2 lines · Rob Landley
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.
Signature · 2 lines
best regards, Rok Papež.
Quoted 30 lines · Rick Hohensee
2.4.5 is 26 meg now. It's time to consider forking the kernel. Alan has already stuck his tippy-toe is that pool, and his toe is fine.
The "thou shalt not fork" commandment made sense at one point, when free unix was a lost tribe wandering hungry in the desert. When you have a project with several million users that has a scope that simply doesn't scale, it doesn't. Forking should be done responsibly, and with great joy. As in nature, software success breeds diversity. Linux should diversify. This is cause for celebration, ceremony, throwing of bouquets and so on.
I have done a few trivial things that people with rather shallow ideas of what unix is about have excoriated as "NOT UNIX!". So far that's been absurd, but my stuff is getting more intrusive. Linux is far more interesting to me for it's general usefulness and openness, which are inextricably related, than for it's unixness, although unix is certainly beautiful.
Alan was going to file for divorce over
dev_t. Isn't is funny how estranged couples so often are so much alike?dev_tis 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).
Quoted 7 lines
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.
Quoted 4 lines
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.
Quoted 1 line
x86 only (and similar, e.g. Crusoe)
Again, Linux is the only system that CAN run on anything from PDA thorough supercomputer clusters.
Quoted 5 lines
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.
Quoted 2 lines
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.
Quoted 8 lines
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.
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 5 lines
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?
Quoted 7 lines
In short, an open source OS for end-users should be very serious about simplicity, and not just pay lip-service to it. There is evidence of the value of this in the marketplace. What doesn't exist is an OS where simplicity is systemic. This is why end-user issues pertain to the kernel at all. This is how open source should be. Simple, or at least clear, through and through. Linux has lost a lot of simplicity since I got into it in '96, and that is a loss.
For the most part, the base Linux appears simple to the user. There are no desktops to worry about. Desktops are an application, not part of Linux at all It is becoming better for the administrator. As better desktops are developed, it is becoming for "user friendly".
Signature · 5 lines
------------------------------------------------------------------------- Jesse I Pollard, II Email: [email protected] Any opinions expressed are solely my own.
Quoted 13 lines · Rick Hohensee
Quoted 7 lines
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.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 7 lines
Quoted 5 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 10 lines
Quoted 9 lines
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.
Quoted 2 lines
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.
Quoted 5 lines
Quoted 3 lines
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".
Quoted 14 lines
Quoted 4 lines
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.
Quoted 5 lines
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.
Quoted 5 lines
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.
Quoted 9 lines
Quoted 7 lines
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?
Quoted 3 lines
desktops to worry about. Desktops are an application, not part of Linux at all It is becoming better for the administrator. As better desktops are developed, it is becoming for "user friendly".
Thanks for replying civilly to something you clearly don't agree with. Basically, your reply says to me that kernel hackers can't imagine unix as an end-user OS. Your points are all "that will suck as a server". Of course. A solid true multi-user open source operating system is a solid base for a variety of things.
Rick Hohensee
www.clienux.com
Quoted 8 lines
Signature · 6 lines
-- ------------------------------------------------------------------------- Jesse I Pollard, II Email: [email protected] Any opinions expressed are solely my own.
Quoted 11 lines · Rick Hohensee
Quoted 4 lines
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/
Signature · 4 lines
: __o : -\<, : 0/ 0 -----------
Quoted 11 lines · Rick Hohensee
Quoted 8 lines
Quoted 5 lines
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.
Quoted 10 lines
Quoted 7 lines
Quoted 3 lines
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.
Quoted 11 lines
Quoted 9 lines
Quoted 7 lines
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.
Quoted 11 lines
Quoted 11 lines
Quoted 7 lines
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".
Quoted 8 lines
Quoted 2 lines
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.
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
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.
Quoted 3 lines
Quoted 1 line
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.
Quoted 11 lines
Quoted 5 lines
desktops to worry about. Desktops are an application, not part of Linux at all It is becoming better for the administrator. As better desktops are developed, it is becoming for "user friendly".
Thanks for replying civilly to something you clearly don't agree with. Basically, your reply says to me that kernel hackers can't imagine unix as an end-user OS. Your points are all "that will suck as a server". Of course. A solid true multi-user open source operating system is a solid base for a variety of things.
I would say that users needs top feel the system to be fast. That is true for desktop even more than for servers.
anyway, many of changes someone push to bring linux on the desktop will make it slower, and that way users will never use it.
No desktop user will way 2 minutes to bring up an office suite. Linux has a tradition it has to refer to, and inside of this tradition Linux can find the way also for the desktop.
There is nothing wrong if you separe the OS from the desktop, and you say, "desktops are on the application side". Then you, as OS can provide the best performance as possible, disk speed, optimal memory usage, and so on. Then the applications have to be able to use this optimal system at best.
Luigi
Rick Hohensee <[email protected]>:
Quoted 9 lines
Quoted 9 lines · Rick Hohensee
Quoted 7 lines
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.
Quoted 5 lines
Quoted 3 lines
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).
Quoted 10 lines
Quoted 7 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
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
Quoted 9 lines
Quoted 7 lines
Quoted 5 lines
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.
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
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.
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 6 lines
Quoted 5 lines
Quoted 3 lines
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.
Quoted 7 lines
Dennis Ritchie, who signs the checks for the people that wrote Plan 9, said an interesting thing about portability. He said "good code is portable code." I infer from that, and from the Plan 9 sources, and from the design of unix and the two-character commands in
/bin/, that he relates good very strongly with simple. Not slavish adherance to standards. Plan 9 C isn't ANSI, for example. The unix portability suite is called "ape".
Yup - yet another software layer to achive portability. Unfortunately, code developed for Plan 9 isn't very portable; so it has to be done twice on the same system. There is no standard for Plan 9, other than Plan 9 itself. This has made it very difficult to make portability claims. POSIX was from the UNIX base, and defined in an attempt to improve portability. It could be better (the security and RT definitions are the "weakest"). But they are standards. Linux attempts to meed the accepted standards where reasonable and necessary to the developers. They too have to port application level software among different systems.
Quoted 33 lines
Quoted 13 lines
Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 5 lines
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.
Quoted 8 lines
Quoted 7 lines
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.
Quoted 3 lines
Quoted 1 line
For the most part, the base Linux appears simple to the user. There are no
Which distro appears simple to the user?
For the most part, Red Hat. I use Red Hat for a general desktop base, but prefer Slackware for the better controls over the system for things like firewalls/Servers (also for fewer security problems caused by the additional "auto-configuration" software that RH insists on creating).
Quoted 10 lines
Quoted 4 lines
desktops to worry about. Desktops are an application, not part of Linux at all It is becoming better for the administrator. As better desktops are developed, it is becoming for "user friendly".
Thanks for replying civilly to something you clearly don't agree with. Basically, your reply says to me that kernel hackers can't imagine unix as an end-user OS. Your points are all "that will suck as a server". Of course. A solid true multi-user open source operating system is a solid base for a variety of things.
I was trying to say that mixing user-application interfaces into a kernel results in poor everything. The kernel should do what kernels do best - hardware resource management and security enforcement (could be shortened to "hardware resource management" since security enforcement can be considered part of "resource managment").
This frees the applications from also having to do hardware/security functions (which they do poorly IMHO). It frees the user-application interface from having to implement applications or hardware and security enforcement.
Granted, better isolation is needed, and that is where KDE/Gnome (both a bit bloated) and/or CORBA (even more bloated with accounting and distributed access controls) were intented to fit. More areas of research and improvement; but not part of the kernel.
And yes, X really really needs to be split into a device driver/module + X display server. The current setup causes a LOT of problems that are hard to diagnose. The recent addition of a frame buffer console goes a long way to improvements, but isn't yet generic enough to support all (enough? how many is enough?) graphics adapters. And fbdev doesn't yet work for laptops well enough (at least the two I've tried with Red Hat).
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
Quoted 10 lines · Rick Hohensee
Quoted 7 lines
Quoted 4 lines
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.
Signature · 5 lines
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
Quoted 7 lines · Rick Hohensee
2.4.5 is 26 meg now. It's time to consider forking the kernel. Alan has already stuck his tippy-toe is that pool, and his toe is fine.
For a client-use Linux kernel, I suggest, and will be and have been persuing, features and non-features such as...
forget POSIX
[junk]
Quoted 7 lines
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.
Quoted 2 lines · Rick Hohensee
2.4.5 is 26 meg now. It's time to consider forking the kernel. Alan has already stuck his tippy-toe is that pool, and his toe is fine.
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.
Signature · 2 lines
Horst von Brand [email protected] Casilla 9G, Vin~a del Mar, Chile +56 32 672616
Quoted 5 lines
Quoted 2 lines · Rick Hohensee
2.4.5 is 26 meg now. It's time to consider forking the kernel. Alan has already stuck his tippy-toe is that pool, and his toe is fine.
Quoted 8 lines
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
Quoted 4 lines
Signature · 2 lines
Horst von Brand [email protected] Casilla 9G, Vin~a del Mar, Chile +56 32 672616
Fork nothing, stop taking stupidity. The kernel SOURCES may be 26MB but that does NOT mean you have to use every driver!
Shawn.
Quoted 33 lines · Rick Hohensee
Quoted 5 lines
Quoted 2 lines · Rick Hohensee
2.4.5 is 26 meg now. It's time to consider forking the kernel. Alan has already stuck his tippy-toe is that pool, and his toe is fine.
Quoted 8 lines
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.comQuoted 4 lines
--
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/