NetBSD had AMD64/x86-64 earlier than Linux, and it was done in a fraction of the time. The framework for running 32-bit binaries on AMD64 is much cleaner and simpler in NetBSD than any Linux distro I've seen attempt it.
http://web.ivy.net/~carton/academia/java_languageo ftomorrow.html
You might like to read all of these things about the Newton (and all of why Java stinks) and consider that maybe running NetBSD won't get the most out of it. The Newton is [according to this] an engineering marvel and NetBSD on it would just make it any other ARM rig.
Yes, because that's what small businesses and home users and insititutions are going to be doing. Linux fills niches that only the biggest corporations or government agencies even NEED. iPaqs and so on are more common, but who needs a nix on them anyway? I wouldn't buy an iPaq and reduce it to the same level of functionality as a dumb terminal with IrDA. Hard fact is Microsoft's offerings are still much more convenient for those hand-held devices than anything a nix has offered. Sure they may be buggy (and boy are they buggy), but they have bugs in doing things the nixes just can't do.
EHCI is proper in -CURRENT, now with interrupt routing from OpenBSD. That closes the gap with Linux in sensible host controllers. Device drivers are another story of course, but only those that aren't part of the standard have trouble.
This might be a Right Place to mention, NetBSD/sparc64 uses a 64-bit user land but every Linux distro I've seen sticks with a 32-bit one (and says "you won't notice the difference", which is a huge copout). That's one positive example of NetBSD doing something Right (the negative example is lack of SMP on the same arch, from what I hear).
You're kidding right? All of the BSDs have package managers that get dependencies, they INVENTED that years before any Linux distro had it. I also have yet to find hardware that Linux supports but [for instance] NetBSD doesn't, but I know this becomes a bigger difference on newer or more exotic machines. 1.5 years old should definitely be supported. I have run BSDs on a range of machines going back from 1998 to 2005 with everything working great (check that: also have an early 90s SGI Indy which NetBSD does very well on). I'm certainly not the only one.
If you have problems with hardware, Google around, and/or submit a PR. Do your civic duty.
Well, if the BSDs got the same amount of corporate backing as Linux did, you'd find nobody would use Linux: and then the thousands of distributions Linux offers would be irrelevant. You'd have three (DragonFly, Net, Open - and maybe even their advantages over each other would flatten out) BSDs which can do everything, as opposed to a plethora of distributions which can do something or other.
Or, on the other hand, you could de-fragment the Linux code (as in, all these separate projects have to somehow fit in the mainline kernel, and fit WELL, including clean code which doesn't seem to bother them), and then have one grand unified distribution. If it doesn't support source and binary updating and package management, it's useless. The BSDs can do that: and they've been doing it for years so it's well established. NetBSD especially has a good foundation laid down for any kind of expansive work needed: DragonFly will get there eventually but right now it still runs on almost no architectures, which sets it back in this regard. Everything else in it is great though. OpenBSD requires a hard-core code audit before anything can even be considered, so that might put off contributions.
You have to wonder why corporations chose Linux to help out back in the old days, any of the projects could have been a viable work horse and gone to great places now, but Linux did and we're stuck with countless half-baked distributions and no consistency even in file system layout (yes, I know this will be 'fixed', a few years too late), and almost as many different kernel source branches which can rarely be merged trivially and so keep their separate advantages and bugs. What SGI, IBM, Intel, etc. think they're doing is beyond me. But, it works on my D600 so I'll keep using it.
You can't do that with Linux either. The name aside, the Linux you run on one arch is not the Linux on another arch. This is especially true if you have an architecture Linux' corporate sponsors don't care about (hint: Linux is all about corporate sponsorship. If you don't believe me, read the changelogs and notice that 99% of the submissions are from employees of big corporations).
Some distros (e.g. Debian) smooth this out, and some make it a nightmare (e.g. Gentoo), but until there's a GNU/Linux distribution that is consistent across all archs in source AND binary deployment and a kernel that contains all architecture fixes at once and keeps up with mainline development, Linux will not be as easy to 'jump between' archs as NetBSD.
NetBSD has the same build procedure on any architecture, using the same headers, sources, and resulting software (sans tools that only make sense one some archs). THAT is the same OS on every arch. The same name of kernel on every arch doesn't even compete. Being able to cross-compile consistently is a great bonus too, but this sometimes breaks down if you're following a development branch. Not all archs have an installer, but those that do appear to have the SAME installer, with extra functionality for those architectures needed.
My example of where even Debian does not have this: SGI MIPS. It does NOT automatically handle the SGI Volume Header (hint: NetBSD does, and installs its own bootloader), nor even tell you what to do: you have to figure out how to use the fdisk-like editor and hope you left enough space for arcsboot or your kernel. On some machines which have very tiny hard drives and need all the space they can get, Debian's way leaves a lot of user calculation to be done. You could call this "well if you're incompetent then don't use Linux", but then that's supporting my argument: NetBSD is an OS for all archs, Linux is a kernel that got ported to some archs at some point in time, and if they're not used by corporate sponsors you can kiss them good bye. Distros won't care either - why should they?
Linux' 'technical excellence' in supporting every arch and every feature anyone could want (to at least some extent) is nice, but that's beside the point of which system is actually more convenient for the architectures it supports. I know if I was running a polyarchitectural (cool word) network I wouldn't use Linux no matter how much faster it was, the administrative mess of managing a plethora of different kernel sources and base packages would be a nightmare. That's how it is in Gentoo at least, maybe Debian is better after installation (but then you lose the source-based flexibility NetBSD still offers without compromise).
Playstation 2 does run NetBSD, so does the Dreamcast: and there's some thought going towards Gamecube. Doubt Playstation 1 though.
NetBSD still relies on having an MMU which reduces its processor support capabilities. This is on the roadmap to be 'fixed' within the next major version or two. However, if it comes with Solaris-like SMP the system itself might be in a lot of trouble.
Why XBox isn't supported is beyond me. NetBSD was ported to AMD64 in a small fraction of the time Linux was, with all the same resources if not less: given XBox is just some i386 quirks and cards it should be trivial. I've read mailing lists where people have some progress and then are never heard from again, probably silenced by the Linux Police which maintain that Linux is the only platform for pissing off Microsoft.
All UNIX is user friendly. It's not idiot friendly. If you know what you're doing and understand the designs, it becomes a paradise of intellect. There are some exceptions (who invented dd?). I find, if you're a decent C programmer, you probably already have the mind set: C programmers wrote the system back in the old days and the new generations are still compatible in design.
Let's take package managers. A one-liner is all it takes to install software and its dependencies, and later keep it all up to date. How do you do that in Windows? With a browser and a cup of coffee and several man-hours. User friendliness really breaks down when users start to want more than just Notepad.
That varies from distro to distro, actually. I do Gentoo so as to maximise the work required without creating user errors. I hate it when too much is done for me.
What you said is "Why isn't Linux a clone of Windows?", and the answer is "Because Windows is broken by design and nothing should ever be like it". If you want Windows, you know where to find it. If you want security, you know where to find it (BSD). If you want to run everywhere, Linux does that.
Then there are no drivers. You can't use legacy x86 drivers on a 64-bit Windows kernel. The advantage of Linux/*BSD in this is that they just recompile already-portable drivers.
The hell with AMD64, what about Windows ever supporting non-end-user architectures? There are dozens. I think of the ones end-users aren't likely to have, IA64 is the only one Windows has supported, and I use that word loosely since it's dropped again.
Linux and NetBSD [except for ppc64 and ia64 and MMU-less archs] can run on anything. If the PC died today, Windows would die with it. And to some degree FreeBSD since it didn't put enough attention in to portability to compete with NetBSD.
Well, X and Firefox aren't exactly small. Would ELinks in a large framebuffer be enough for your needs? That would take a LOT less resources and especially loading times.
Is it still unstable? I heard it's now very stable in 2.0, and I used it without problems for some time. It has been used for self-hosted world builds (where LFS was for the sources and output) with good results.
Maybe it's another story with RaidFrame. I have heard it is very slow serving NFS, but haven't heard an update on this lately. Should check the mailing list archives.
By watching the exploit tickers on distribution/etc sites. No way can a well-audited system have even an exploit per month, let alone a few per week like I've seen (don't believe me? watch the exploit ticker on forums.gentoo.org)
You may say "but you can run that software under bsd too!", but that's not the point: the target platform is invariably GNU/Linux, making it a GNU/Linux camp.
...who previously had an nVidia Go 5200FX (or whatever order those tokens are meant to come in), and now a Radeon 9000, I can only say I'd rather have out-of-tree drivers that work perfectly for a good card than half-baked drivers for an average card (where good/bad are measured in usability, not necessarily performance).
The Radeon under Linux (and I assume anywhere with an XOrg server) is a huge pain. Doesn't manually switch output displays with Fn+F8 like it should, and xv [the direct output mode, not the graphics program] only goes to the lappy panel, never to an external monitor. It might be a really trivial change in the driver source, but in the mean time it's an uneccessary frustration.
Everything there is true, but NetBSD WILL give you the option of saving network configuration if you give it at any point during install (e.g. networked install, or just asking it to).
The BSDs really are conscious about security though, especially Open. I've heard a lot of FUD to the contrary (wideopenbsd.org?) but the hard truth is OpenBSD is just amazing. A nice contrast to those GNU/Linux machines in which a code audit is looking to see if typing random crap in telnet crashes a machine or not (seriously, this is how some camps do it).
Help the effort to port LFS to FreeBSD (or run NetBSD to begin with); it's even more complete than journalling. In performance it still falls short of ReiserFS, but at least there's no fscking. Works as a good/var.
You've made your point a dozen times, get over it. Nobody cares what you know about architectures and page tables. I quoted a source that could have been better chosen. I did NOT say page tables are an i386 specific feature, I assumed that the pdf therein implied that implementations were different and NetBSD was abstract where Linux compensated for differences with layers. Excuse me for trusting third-party resources. I can see you're the authority because you personally reviewed the low level hardware documentation for all of these processors and then the source of NetBSD and Linux relevant to them, and so are completely pure of 'reading disease'.
Get over it. I'm not anti-Linux, I'm anti-(people who say that Linux portability is a work of art and NetBSD is irrelevant). Hell I have four machines powered up in this room and three of them are Linux. That doesn't mean it's a work of art; it happens to be convenient in ways NetBSD won't be until Gentoo Portage or something like it is available. We all have our reasons.
http://www.linux-mips.org/archives/linux-mips/2004 -09/msg00112.html
That's from a friend of mine off another forum.
Gentoo's documentation on running MIPS agrees that 2.6 isn't flying on it. In 2.6.10 it might be fixed, but the changelogs don't show anything like that - after all, it's old and irrelevant right? Who cares about hardware not actively in use by big corporations?
I'm now using this as a reference to Linux unportability because it DOES support what I'm saying, unlike your dumb ass.
An example you'll find elsewhere in this sub-thread: The Linux memory management system is designed around the three-level MMU available on Intel x86 processors. For these and similar processors, this works extremely well. However, systems with other MMU designs are forced to suffer the complexity and performance impact of making the underlying hardware appear to function like a three level MMU system. In many cases this requires code to perform specific low level hardware access (for example to flush TLBs) to be scattered throughout the kernel. NetBSD, by comparison, has a cleanly designed pmap abstraction that provides a well-defined interface for the high level routines to perform virtual memory related operations. Each processor's low-level pmap code can then implement the data instructions and algorithms best suited to its MMU.
Will you please just die now? Give up: Linux is not abstract among architectures. It's a hack job and it's a damn miracle it even boots. It can't sustain many ports in-tree, that's why there are mips-sources, sparc-sources, alpha-sources, and so on. Fixes and improvements are not properly shared or cross integrated, so you never know how F'd up your Linux is compared to others. NetBSD has every port in one tree and it IS abstracted, so improvements affect everything related. If you had even once run it you'd notice. I have run Linux and NetBSD and I know the difference. It's nice to have corporations who research operating system architecture back it up.
Found your i386 centric Linux core:
http://www.wasabisystems.com/pdfs/Linux_or_BSD.pdf The Linux memory management system is designed around the three-level MMU available on Intel x86 processors. For these and similar processors, this works extremely well. However, systems with other MMU designs are forced to suffer the complexity and performance impact of making the underlying hardware appear to function like a three level MMU system. In many cases this requires code to perform specific low level hardware access (for example to flush TLBs) to be scattered throughout the kernel. NetBSD, by comparison, has a cleanly designed pmap abstraction that provides a well-defined interface for the high level routines to perform virtual memory related operations. Each processor's low-level pmap code can then implement the data instructions and algorithms best suited to its MMU.
It being written aeons ago does not justify it staying outdated. NetBSD replaces old code. If Linux can't do that (however far from the 'core' as you seem to love, which is completely irrelevant because hardware support - the issue being discussed - is never at the core) it's always going to have these little things holding it back. You can stick on all the wonderful clustering and file systems and whatever else you want, but it won't support hardware to its fullest, at least not without dirty hacks or redundant drivers.
If you even watched the changelogs you'd see all of the mangling needed to get some drivers working properly. I'm not even going to bother looking through it all if you won't; I've told you of something and you told me it's not true. Unless you do a full audit of Linux and prove that it does NOT use any hacks, you can only assume it does. This is logical. In software, assume the worst until you prove otherwise.
The one thing that sets apart NetBSD from other systems is the necessity for code quality, not just as a 'nice thing to have'. If it was really that shoddy, it wouldn't be here. It also wouldn't be praised by anyone who's worked with its code as the cleanest, because you just don't make that shit up.
Try to develop a port for both systems, like the developer whose comment I posted, and see for yourself.
Slashdot Mirror
NetBSD had AMD64/x86-64 earlier than Linux, and it was done in a fraction of the time. The framework for running 32-bit binaries on AMD64 is much cleaner and simpler in NetBSD than any Linux distro I've seen attempt it.
http://web.ivy.net/~carton/academia/java_languageo ftomorrow.html
You might like to read all of these things about the Newton (and all of why Java stinks) and consider that maybe running NetBSD won't get the most out of it. The Newton is [according to this] an engineering marvel and NetBSD on it would just make it any other ARM rig.
Yes, because that's what small businesses and home users and insititutions are going to be doing. Linux fills niches that only the biggest corporations or government agencies even NEED. iPaqs and so on are more common, but who needs a nix on them anyway? I wouldn't buy an iPaq and reduce it to the same level of functionality as a dumb terminal with IrDA. Hard fact is Microsoft's offerings are still much more convenient for those hand-held devices than anything a nix has offered. Sure they may be buggy (and boy are they buggy), but they have bugs in doing things the nixes just can't do.
EHCI is proper in -CURRENT, now with interrupt routing from OpenBSD. That closes the gap with Linux in sensible host controllers. Device drivers are another story of course, but only those that aren't part of the standard have trouble.
There's an MP3 player running NetBSD. I think that's cool enough, especially since it can actually *gasp* function as an MP3 player.
This might be a Right Place to mention, NetBSD/sparc64 uses a 64-bit user land but every Linux distro I've seen sticks with a 32-bit one (and says "you won't notice the difference", which is a huge copout). That's one positive example of NetBSD doing something Right (the negative example is lack of SMP on the same arch, from what I hear).
You're kidding right? All of the BSDs have package managers that get dependencies, they INVENTED that years before any Linux distro had it. I also have yet to find hardware that Linux supports but [for instance] NetBSD doesn't, but I know this becomes a bigger difference on newer or more exotic machines. 1.5 years old should definitely be supported. I have run BSDs on a range of machines going back from 1998 to 2005 with everything working great (check that: also have an early 90s SGI Indy which NetBSD does very well on). I'm certainly not the only one.
If you have problems with hardware, Google around, and/or submit a PR. Do your civic duty.
Well, if the BSDs got the same amount of corporate backing as Linux did, you'd find nobody would use Linux: and then the thousands of distributions Linux offers would be irrelevant. You'd have three (DragonFly, Net, Open - and maybe even their advantages over each other would flatten out) BSDs which can do everything, as opposed to a plethora of distributions which can do something or other.
Or, on the other hand, you could de-fragment the Linux code (as in, all these separate projects have to somehow fit in the mainline kernel, and fit WELL, including clean code which doesn't seem to bother them), and then have one grand unified distribution. If it doesn't support source and binary updating and package management, it's useless. The BSDs can do that: and they've been doing it for years so it's well established. NetBSD especially has a good foundation laid down for any kind of expansive work needed: DragonFly will get there eventually but right now it still runs on almost no architectures, which sets it back in this regard. Everything else in it is great though. OpenBSD requires a hard-core code audit before anything can even be considered, so that might put off contributions.
You have to wonder why corporations chose Linux to help out back in the old days, any of the projects could have been a viable work horse and gone to great places now, but Linux did and we're stuck with countless half-baked distributions and no consistency even in file system layout (yes, I know this will be 'fixed', a few years too late), and almost as many different kernel source branches which can rarely be merged trivially and so keep their separate advantages and bugs. What SGI, IBM, Intel, etc. think they're doing is beyond me. But, it works on my D600 so I'll keep using it.
You can't do that with Linux either. The name aside, the Linux you run on one arch is not the Linux on another arch. This is especially true if you have an architecture Linux' corporate sponsors don't care about (hint: Linux is all about corporate sponsorship. If you don't believe me, read the changelogs and notice that 99% of the submissions are from employees of big corporations).
Some distros (e.g. Debian) smooth this out, and some make it a nightmare (e.g. Gentoo), but until there's a GNU/Linux distribution that is consistent across all archs in source AND binary deployment and a kernel that contains all architecture fixes at once and keeps up with mainline development, Linux will not be as easy to 'jump between' archs as NetBSD.
NetBSD has the same build procedure on any architecture, using the same headers, sources, and resulting software (sans tools that only make sense one some archs). THAT is the same OS on every arch. The same name of kernel on every arch doesn't even compete. Being able to cross-compile consistently is a great bonus too, but this sometimes breaks down if you're following a development branch. Not all archs have an installer, but those that do appear to have the SAME installer, with extra functionality for those architectures needed.
My example of where even Debian does not have this: SGI MIPS. It does NOT automatically handle the SGI Volume Header (hint: NetBSD does, and installs its own bootloader), nor even tell you what to do: you have to figure out how to use the fdisk-like editor and hope you left enough space for arcsboot or your kernel. On some machines which have very tiny hard drives and need all the space they can get, Debian's way leaves a lot of user calculation to be done. You could call this "well if you're incompetent then don't use Linux", but then that's supporting my argument: NetBSD is an OS for all archs, Linux is a kernel that got ported to some archs at some point in time, and if they're not used by corporate sponsors you can kiss them good bye. Distros won't care either - why should they?
Linux' 'technical excellence' in supporting every arch and every feature anyone could want (to at least some extent) is nice, but that's beside the point of which system is actually more convenient for the architectures it supports. I know if I was running a polyarchitectural (cool word) network I wouldn't use Linux no matter how much faster it was, the administrative mess of managing a plethora of different kernel sources and base packages would be a nightmare. That's how it is in Gentoo at least, maybe Debian is better after installation (but then you lose the source-based flexibility NetBSD still offers without compromise).
Playstation 2 does run NetBSD, so does the Dreamcast: and there's some thought going towards Gamecube. Doubt Playstation 1 though.
NetBSD still relies on having an MMU which reduces its processor support capabilities. This is on the roadmap to be 'fixed' within the next major version or two. However, if it comes with Solaris-like SMP the system itself might be in a lot of trouble.
Why XBox isn't supported is beyond me. NetBSD was ported to AMD64 in a small fraction of the time Linux was, with all the same resources if not less: given XBox is just some i386 quirks and cards it should be trivial. I've read mailing lists where people have some progress and then are never heard from again, probably silenced by the Linux Police which maintain that Linux is the only platform for pissing off Microsoft.
All UNIX is user friendly. It's not idiot friendly. If you know what you're doing and understand the designs, it becomes a paradise of intellect. There are some exceptions (who invented dd?). I find, if you're a decent C programmer, you probably already have the mind set: C programmers wrote the system back in the old days and the new generations are still compatible in design.
Let's take package managers. A one-liner is all it takes to install software and its dependencies, and later keep it all up to date. How do you do that in Windows? With a browser and a cup of coffee and several man-hours. User friendliness really breaks down when users start to want more than just Notepad.
That varies from distro to distro, actually. I do Gentoo so as to maximise the work required without creating user errors. I hate it when too much is done for me.
What you said is "Why isn't Linux a clone of Windows?", and the answer is "Because Windows is broken by design and nothing should ever be like it". If you want Windows, you know where to find it. If you want security, you know where to find it (BSD). If you want to run everywhere, Linux does that.
Then there are no drivers. You can't use legacy x86 drivers on a 64-bit Windows kernel. The advantage of Linux/*BSD in this is that they just recompile already-portable drivers.
The hell with AMD64, what about Windows ever supporting non-end-user architectures? There are dozens. I think of the ones end-users aren't likely to have, IA64 is the only one Windows has supported, and I use that word loosely since it's dropped again.
Linux and NetBSD [except for ppc64 and ia64 and MMU-less archs] can run on anything. If the PC died today, Windows would die with it. And to some degree FreeBSD since it didn't put enough attention in to portability to compete with NetBSD.
Well, X and Firefox aren't exactly small. Would ELinks in a large framebuffer be enough for your needs? That would take a LOT less resources and especially loading times.
Is it still unstable? I heard it's now very stable in 2.0, and I used it without problems for some time. It has been used for self-hosted world builds (where LFS was for the sources and output) with good results.
Maybe it's another story with RaidFrame. I have heard it is very slow serving NFS, but haven't heard an update on this lately. Should check the mailing list archives.
By watching the exploit tickers on distribution/etc sites. No way can a well-audited system have even an exploit per month, let alone a few per week like I've seen (don't believe me? watch the exploit ticker on forums.gentoo.org)
You may say "but you can run that software under bsd too!", but that's not the point: the target platform is invariably GNU/Linux, making it a GNU/Linux camp.
Say what you will, it's insecure. Move on.
...who previously had an nVidia Go 5200FX (or whatever order those tokens are meant to come in), and now a Radeon 9000, I can only say I'd rather have out-of-tree drivers that work perfectly for a good card than half-baked drivers for an average card (where good/bad are measured in usability, not necessarily performance).
The Radeon under Linux (and I assume anywhere with an XOrg server) is a huge pain. Doesn't manually switch output displays with Fn+F8 like it should, and xv [the direct output mode, not the graphics program] only goes to the lappy panel, never to an external monitor. It might be a really trivial change in the driver source, but in the mean time it's an uneccessary frustration.
Everything there is true, but NetBSD WILL give you the option of saving network configuration if you give it at any point during install (e.g. networked install, or just asking it to).
The BSDs really are conscious about security though, especially Open. I've heard a lot of FUD to the contrary (wideopenbsd.org?) but the hard truth is OpenBSD is just amazing. A nice contrast to those GNU/Linux machines in which a code audit is looking to see if typing random crap in telnet crashes a machine or not (seriously, this is how some camps do it).
Help the effort to port LFS to FreeBSD (or run NetBSD to begin with); it's even more complete than journalling. In performance it still falls short of ReiserFS, but at least there's no fscking. Works as a good /var.
You've made your point a dozen times, get over it. Nobody cares what you know about architectures and page tables. I quoted a source that could have been better chosen. I did NOT say page tables are an i386 specific feature, I assumed that the pdf therein implied that implementations were different and NetBSD was abstract where Linux compensated for differences with layers. Excuse me for trusting third-party resources. I can see you're the authority because you personally reviewed the low level hardware documentation for all of these processors and then the source of NetBSD and Linux relevant to them, and so are completely pure of 'reading disease'.
Get over it. I'm not anti-Linux, I'm anti-(people who say that Linux portability is a work of art and NetBSD is irrelevant). Hell I have four machines powered up in this room and three of them are Linux. That doesn't mean it's a work of art; it happens to be convenient in ways NetBSD won't be until Gentoo Portage or something like it is available. We all have our reasons.
http://www.linux-mips.org/archives/linux-mips/2004 -09/msg00112.html
That's from a friend of mine off another forum.
Gentoo's documentation on running MIPS agrees that 2.6 isn't flying on it. In 2.6.10 it might be fixed, but the changelogs don't show anything like that - after all, it's old and irrelevant right? Who cares about hardware not actively in use by big corporations?
Later in that same thread: http://marc.theaimsgroup.com/?l=netbsd-tech-kern&m =110618215623555&w=2
Should be more careful about what you post. Doesn't help your credibility, Anonymous Coward.
Since you couldn't find it yourself (or were too scared to), here: http://www.wasabisystems.com/pdfs/Linux_or_BSD.pdf
I'm now using this as a reference to Linux unportability because it DOES support what I'm saying, unlike your dumb ass.
An example you'll find elsewhere in this sub-thread:
The Linux memory management system is designed around the three-level MMU available on Intel x86 processors. For these and similar processors, this works extremely well. However, systems with other MMU designs are forced to suffer the complexity and performance impact of making the underlying hardware appear to function like a three level MMU system. In many cases this requires code to perform specific low level hardware access (for example to flush TLBs) to be scattered throughout the kernel. NetBSD, by comparison, has a cleanly designed pmap abstraction that provides a well-defined interface for the high level routines to perform virtual memory related operations. Each processor's low-level pmap code can then implement the data instructions and algorithms best suited to its MMU.
Will you please just die now? Give up: Linux is not abstract among architectures. It's a hack job and it's a damn miracle it even boots. It can't sustain many ports in-tree, that's why there are mips-sources, sparc-sources, alpha-sources, and so on. Fixes and improvements are not properly shared or cross integrated, so you never know how F'd up your Linux is compared to others. NetBSD has every port in one tree and it IS abstracted, so improvements affect everything related. If you had even once run it you'd notice. I have run Linux and NetBSD and I know the difference. It's nice to have corporations who research operating system architecture back it up.
Found your i386 centric Linux core:f
http://www.wasabisystems.com/pdfs/Linux_or_BSD.pd
The Linux memory management system is designed around the three-level MMU available on Intel x86 processors. For these and similar processors, this works extremely well. However, systems with other MMU designs are forced to suffer the complexity and performance impact of making the underlying hardware appear to function like a three level MMU system. In many cases this requires code to perform specific low level hardware access (for example to flush TLBs) to be scattered throughout the kernel. NetBSD, by comparison, has a cleanly designed pmap abstraction that provides a well-defined interface for the high level routines to perform virtual memory related operations. Each processor's low-level pmap code can then implement the data instructions and algorithms best suited to its MMU.
We're done here.
It being written aeons ago does not justify it staying outdated. NetBSD replaces old code. If Linux can't do that (however far from the 'core' as you seem to love, which is completely irrelevant because hardware support - the issue being discussed - is never at the core) it's always going to have these little things holding it back. You can stick on all the wonderful clustering and file systems and whatever else you want, but it won't support hardware to its fullest, at least not without dirty hacks or redundant drivers.
If you even watched the changelogs you'd see all of the mangling needed to get some drivers working properly. I'm not even going to bother looking through it all if you won't; I've told you of something and you told me it's not true. Unless you do a full audit of Linux and prove that it does NOT use any hacks, you can only assume it does. This is logical. In software, assume the worst until you prove otherwise.
The one thing that sets apart NetBSD from other systems is the necessity for code quality, not just as a 'nice thing to have'. If it was really that shoddy, it wouldn't be here. It also wouldn't be praised by anyone who's worked with its code as the cleanest, because you just don't make that shit up.
Try to develop a port for both systems, like the developer whose comment I posted, and see for yourself.