Not my point actually. My point is that you insist everything in Linux MUST be perfect, because it's Linux, and everything in BSD MUST be 'SUBSTANDARD', becuase it's in BSD.
I am well aware of all the failures in FreeBSD 5. But it's SMP design is not sub-standard. There is no standard. Let's say there are 5 major free OS players that just about everyone can name: Linux, FreeBSD, DragonFly BSD, NetBSD and OpenBSD. Linux and FreeBSD have (different but conceptually familiar) mutex SMP models, and while Linux' one clearly owns the FreeBSD one hard, the design of FreeBSD's one is not too terrible... if they coded it right. They didn't. It has sub-standard code, not sub-standard SMP design. DragonFly has a much better approach with much better code, so while it beats FreeBSD 5, it's not made the 'standard' just by that. Net and Open have the giant lock so they are the worst players, but in practice they still beat FreeBSD 5 so design isn't everything.
And why do you defend a driver being unpopular/irrelevant (not true if you realise not all machines in the world have GigE cards, or even the capacity to use them) as an excuse for it sucking? Why not just break support for all notamd64 architectures because they're not mainstream and modern enough? All those sparc, alpha, etc. guys should move up to amd64! Isn't that right? Same thing with firewire networking versus gige. Sure it's not even half the theoretical bandwidth, but that's no reason to ignore the possibilities and necessities it can have.
I'm tired of this, I've been swatting away you trolls (who call me a troll, by the way) since morning. If you think Linux is the final solution to every software problem, you are now commanded to touch a computer again.
Where's ulib? He can help here. Much more experience in troll squashing than I have.
Ack, it's sys-libs/glibc, not dev-libs. I wildcarded my way in.
While I'm here, I may as well point out something I excused before: you can't spell 'incompetent'. That's pretty pathetic for someone implying themself to be an insider in Linux development who can definitively prove everything I say is trolling bullshit - but already failed. Go back to installing Mandrake three times a day and reading kerneltrap + Slashdot to get the 'inside' development stories.
Bzzzt try again, troll. NPTL has been in Linux since the middle of the 2.5 development cycle.
/usr/portage/dev-libs/glibc/glibc-2.3.4.20040619-r 2.ebuild
# Minimum kernel version we support
# (Recent snapshots fails with 2.6.5 and earlier)
MIN_KERNEL_VERSION="2.6.5"
Headshot. If it hadn't changed, there'd be no reason that newer user-land nptl libraries wouldn't work with older kernels. Read up before you think you're fighting 'trolls'.
And there was no "new SCSI subsystem" in 2.5 or 2.6 period.
No, I actually did check everything, and have been configuring and compiling Linux kernels with mostly success (except weird shit like this) for years. There's no magic to it, don't pretend to be a technical expect because you've never found a bug. Same goes for that "absolutely no idea when it comes to kernel coding" assumption: I am a coder and I do know when a warning is an error in disguise. By the looks of it the calling parameters of something internal changed (since this did not happen in 2.6.9) but not all drivers were updated, and nobody cared. If this is not the case, they should fix compile warnings: the BSDs do, because warnings left over in 'stable' branches signify lazy/careless developers (i.e. Linux contributors).
Nice AC posting by the way, if you're going to make insulting claims against someone, do it with your own name or risk not being taken seriously. If I wanted to troll, which I don't, I wouldn't do it under my own name. From this perspective we gather that you're the troll and I'm making honest observations. Have a really bad day, you deserve it.
The first time I booted 2.6.3 (mainline, under Slackware, previously 2.6.2 with less problems) every file opened for writing would be truncated and never written to. My entire home dir was mangled and it took a very long painful sitting of deleting and re-configuring before things worked again, and even then there were flake outs. I never booted 2.6.3 again.
2.6 then had some large changes (nptl, new SCSI subsystem without warning, etc.) and now at 2.6.10 seems to be at least sort-of stable, but there are compile warnings in wireless drivers I think are actual mistakes and am glad I don't have that hardware. On the other hand, and this is a big thing in favor of the BSD style kernel configuration, with 2.6.10 a certain magical combination of kernel options left me without a console outside of X (and no, I did not ask it to use serial console), and reconfiguring from scratch was the only thing that fixed it. I still have not been able to reproduce this (but remember it happening with an earlier kernel, might have been a 2.4) or even figure out what option/combination caused it. I mean, that's pretty f#ed up.
OpenBSD basically needs a bigger contributing (at least PRing) user base. So does NetBSD of course. The number of developers is fine in both because they are talented and can work together (oppose thousands of Linux devs who still can't engineer for stability), but the user bases are too small to really test everything at once.
Shame isn't it? With Linux stealing the spotlight all the other more deserving projects are left lacking users.
And no, Linux has never had a full package tree, because LINUX IS NOT AN OPERATING SYSTEM. It's a kernel. DISTRIBUTIONS have package trees, but they don't release at the same time new kernel versions do, so being able to install a distro from the latest kernel isn't always possible until the next release; this becomes important when your installation requires new drivers only found in the latest kernel.
FreeBSD's SMP is not substandard, by all rights it's one of the better free ones, its entire code base just needs a LOT more work before it's 'there'. And I doubt you'll find a definitive SMP 'standard' there too. What, Linux is the standard for everything? Looks like all the BSDs have super-standard security, quality assurance, release engineering, consistency, documentation and developer support. I'll also remind people that eth1394 (Linux ip-over-firewire driver) is less than half as fast as FreeBSD's fwe and fwip, and has not improved in this regard since 2.4 days. Hardly anyone even notices; but benchmark it on your home machines and just TRY to get netperf to report more than 116Mb/s throughput.
And I was already aware of those 'problems', but if every time something like that came up the whole project was abandoned, do you think any of the projects would be where they are?
And it's not trolling to say FreeBSD is losing its lustre. That's actually entirely true. It's not dead yet, and it might recover, but in the mean time, there are much better alternatives to running FreeBSD 5. NetBSD 2 is one, DragonFly is another, hell even Linux has been more stable lately. I also said all of these things MUCH earlier than that benchmark was released, it just happens to support the argument.
Why do you have to call any observation which puts one project ahead of another a troll? It doesn't even look like you read what I said.
Why not run NetBSD/xen? In -current it even has initial support for Xen 2.
And if you follow the development you'll note it's a much better contender for making use of the platform anyway. NetBSD's simpler algorithms and amazingly good code work well where you have to minimize the raw overhead, which is useful for virtualization like Xen. FreeBSD's advantages are thinning out fast.
What RAID cards are you having trouble supporting? As far as I've seen the gap between Linux supporting a device and Free/NetBSD (I don't track Open) supporting the same device is down to at most a month, and not necessarily with the BSDs behind (especially since they have full-featured releases and snapshots, whereas Linux/distributions/ have to catch up to support the new hardware out of the box).
Linux drivers: "it compiles and works well-enough on the architecture I tried it in, it's going in the stable tree"
FreeBSD drivers: "it works stably on the architectures it's possible to use in, and not too many PRs are filed about it; it's going in the stable tree"
NetBSD drivers: "it is abstracted to work properly regardless of architecture or topology, PRs aren't being filed, and it's had time to stew; it's going in the stable tree"
Me, I'm still waiting for the cdce driver to be MFC'd in netbsd-2 so I can consider using it in place of a Linux install working as a make-shift but must-work-well gateway I manage for a friend. I'm avoiding running -current because a lot of work is going to go in that might cause instability. None of this helps you but it's worth talking about.
The frequency of releases seems to be in inverse proportion to quality. Linux releases half-arsed 'stable' releases which may not even work very frequently. The three 'definitive' BSDs typically release twice a year (this is a hard-coded tradition for Open*) and, excusing the developmental nature of FreeBSD 5.x, these are very solid and already have a full package tree and ready documentation, etc. which Linux never has had.
DragonFly has made one major release and another is on the horizon (if you read the lists or talk in #dragonflybsd on efnet). The first had an installer bug, they fixed it and released a new one immediately. The next should be in much better shape as the system is getting much more contribution and testing now (heck, even I submitted a trivial patch in response to joerg's request for GMP->OpenSSL arbitrary precision math translation).
It's the difference between the intelligent man who sits quietly and the idiot who never shuts up. "Those who release the worst, release it the most often".
You might get away with a faster processor but using software floating point instructions. This way you can stick with a clean architecture and still get the floating, just with less efficiency.
But if it was up to me I'd look for a MIPS R5000. They have good floating point (powered the multimedia machines of the last generation, mostly SGI boxes) and maintain the advantages of low-power low-heat processors. They can also run in 64 bit mode but not many free OSs support this properly.
Try this out: Find yourself an SGI Indy with an R5000, stick NetBSD 2 on it (or Linux, but you're stuck with 2.4, and nothing is maintained any more), and use that. Indy machines have very good sound cards you can use to play the OGGs too... and the only fan part is the PSU. It SHOULD be powerful enough (at 150Mhz, the R5000 has integer ops *roughly*equivalent* to a P1 166, but floating ops are much better and without the bugs).
Yeah, there's that, but you also advertised its 2.6-ness and toolchain to build a new kernel. So it's not like the software on it didn't interest you:)
You'll have a hard time convincing anyone in-the-know to run Linux on anything that isn't x86. Its strategy towards porting is "convince the rest of the kernel it's an i386 and work like that", which fails on a lot of systems which are fundamentally different from i386, even if they have some things in common (ISA isn't the same everywhere, for instance).
NetBSD is portable in the Right Way. It actually abstracts architectures, busses, etc. completely, with nothing i386-specific leaving the i386 world (to combat confusion: ports that are LIKE i386 but wouldn't involve the same kernel and installation are exempt - e.g. Xen which doesn't need any hardware drivers but is still based on i386).
The same clean code and clean design that allow this kind of abstraction lead to a generally clean and stable system. NetBSD's worst stability problems occur only in device quirks which haven't yet been fully understood (you'll notice Linux has the same quirks but the hacks around them are usually done earlier, since Linux contributors don't care if something is a hack or not). Where the hardware is non-quirky, the system simply does not encounter problems. Simple as that. You could say the same for Linux to some extent, but for Linux, achieving stability is all about quirks for everything, even where it's not needed [see the first mention of i386 'emulation' above]. That's why the Linux kernel is an order of magnitude larger than NetBSD's but does not have the functionality to justify it.
I ended up typing a lot in response to very little, but the point is: Linux is marketable, so it gets around, NetBSD is proper, so it gets installed over Linux by anyone in their right mind.
This is a desperate attempt to minimize fragmentation between distributions. Anyone in their right mind would run a BSD anyway, which are internally consistent.
Honestly, this is yet another example of how the GNU/Linux world fucks things up and then requires a 'victory for open source' [e.g. this standard being accepted] to be anywhere near as sensible as a BSD.
Windows: Where do you want to go today?
Linux: Where do you want to go tomorrow?
BSD: Well now that we're here...
Neither does NetBSD actually. And if you look at his post another time you'll notice he acknowledges their functionality. The hard fact is NetBSD is a speed daemon.
NetBSD not supporting an architecture means one of two things: (1) the architecture has no processors with an MMU, or (2) no developer has the hardware
This explains no NetBSD on iPaq/etc for (1) and no NetBSD on ppc64/ia64 for (2).
As we can see by these examples (especially that nice post by the developer who supported this board under NetBSD), when it does support the hardware, it supports it properly, not just as x86 compatibility. That's the key difference between Linux and NetBSD; NetBSD is an operating system for every architecture, Linux is a kernel that can pretend to understand any architecture. I'll stick to NetBSD, thanks (even on i386 where possible).
I have mixed feelings about this. On the one hand, nothing in the post is particularly troll-like, since the claims about the politics and rotting code is entirely true and visible just by reading the lists and, well, code. On the other hand, anything that gets repeated in a troll-like manner but has negative perspective on a project, does in some way deserve to be called a troll. If it's worth saying, it's worth finding more than one way to say. If it's not worth saying, it's a troll.
It doesn't deserve +4 since it's just a copy, but I wouldn't mark it Troll either, personally.
The hard fact is, the developers politics is the reason DragonFly is out there today and admittedly doing a better job of being fast and stable than FreeBSD 5. While, yes, this has the potential to change in the future, the remaining number and skill of the developers means it will take a long time and be a bumpy ride.. before the system is anywhere near as fast as 4.x was for most of the same tasks. With everything MPSAFE and micro-optimised (at least another year of work) it will be good, but for most users it's not worth it right now. And, yes, this all happened because of politics.
Never thought I'd see it happen in FreeBSD but it did. Let's hope the other major OS projects keep their goals straight. Everyone aware that NetBSD 3 is going to have Solaris-like SMP locking, which is at least 90% of the reason FreeBSD 5 is the way it is?
I had a familiar problem (and not just me) of HTT not being SMP-like enough for 4.x to boot on it (trap on boot), this on a Dell Inspiron 5150 with a P4 3.06 w/ HTT. I ended up turning HTT off and keeping it that way (its advantages are wasted under the UNIXy OSs which have sufficiently responsive schedulers, but a lot more overhead and potentially buggy behavior appears when you turn use it).
Others did not have this problem (as the mailing lists spoke), so it's probably just a bit of confusion with APICs.
Apologies, I guess I misunderstood your post as saying the benchmarks were run on the wrong kind of system, rather than the benchmarks being used for sweeping assumptions.
So 5-STABLE is actually becoming worth using, you say? I'd like to try that, in fact I will when I can afford to (currently only two machines under my control and both are life-critical, for my life anyway). I've really wanted to get back into FreeBSD, it's highly usable and all, but my negative experience with 5.3 (yes, even tracking -STABLE for a month or so) put me off.
Has anything been said on the topic of the new, stupid disk sync style? Unlike all other systems which sync their dirty buffers quickly and know about it, FreeBSD 5 now can generate MORE dirty buffers during syncing and has to wait for 3 consecutive "no really, it's all clear this time" checks before being satisfied; and each check is spaced about a second. This results in possibly 5-10 seconds spent just waiting for disk syncing, which is digusting compared to near-instant syncs in other systems.
Anyway, does anyone want to run an Apache or other bench on a 64-bit SMP system with NetBSD 2_stable and FreeBSD 5.3-STABLE? Be worth a look I'd say. I wouldn't run a server based on small performance merit myself, it'd all come down to administration, cleanliness, security and stability... but then I don't pay for my hardware myself.
Actually, I just re-read your post, and noticed you have no clue at all. Let me explain: an algorithm is an algorithm. It doesn't matter if it's running on a machine with one or two procs, one instance of the algorithm will still only run on one processor at a time. It doesn't matter if it's 64 bit or 32 bit, since NetBSD is 64-bit-clean and hence doesn't have nasty side effects; let's assume FreeBSD is up to scratch on this as well. The algorithms will still scale the same and, if the instruction horse power is equivalent, take the same time.
What you said was "this is a great display of how a person can run, but it doesn't say anything about how he would run with a friend or on a Thursday!"
FreeBSD is already known to have made a lousy AMD64 implementation, a lousy SMP implementation (which, on 2-way and probably 4-way SMP machines, is actually SLOWER than NetBSD 2's giant lock model), and haven't even finished supporting their new kernel facilities on Sparc64 and Alpha.
So if this test was even possible on a 64 bit CPU in SMP mode, it wouldn't save FreeBSD. The source is out there though, so why not run it yourself? Of course it won't help because all of those are UP-centric micro benchmarks, and you'll just have to run, say, an Apache or MySQL bench.
Which is way overcomplicated to parse and often write. Have you completely missed the discussion in this thread about the ideal way of storing configurations? Your way is arguably even worse than XML which at least has libraries for it already.
Slashdot Mirror
Not my point actually. My point is that you insist everything in Linux MUST be perfect, because it's Linux, and everything in BSD MUST be 'SUBSTANDARD', becuase it's in BSD.
I am well aware of all the failures in FreeBSD 5. But it's SMP design is not sub-standard. There is no standard. Let's say there are 5 major free OS players that just about everyone can name: Linux, FreeBSD, DragonFly BSD, NetBSD and OpenBSD. Linux and FreeBSD have (different but conceptually familiar) mutex SMP models, and while Linux' one clearly owns the FreeBSD one hard, the design of FreeBSD's one is not too terrible... if they coded it right. They didn't. It has sub-standard code, not sub-standard SMP design. DragonFly has a much better approach with much better code, so while it beats FreeBSD 5, it's not made the 'standard' just by that. Net and Open have the giant lock so they are the worst players, but in practice they still beat FreeBSD 5 so design isn't everything.
And why do you defend a driver being unpopular/irrelevant (not true if you realise not all machines in the world have GigE cards, or even the capacity to use them) as an excuse for it sucking? Why not just break support for all notamd64 architectures because they're not mainstream and modern enough? All those sparc, alpha, etc. guys should move up to amd64! Isn't that right? Same thing with firewire networking versus gige. Sure it's not even half the theoretical bandwidth, but that's no reason to ignore the possibilities and necessities it can have.
I'm tired of this, I've been swatting away you trolls (who call me a troll, by the way) since morning. If you think Linux is the final solution to every software problem, you are now commanded to touch a computer again.
Where's ulib? He can help here. Much more experience in troll squashing than I have.
Ack, it's sys-libs/glibc, not dev-libs. I wildcarded my way in.
While I'm here, I may as well point out something I excused before: you can't spell 'incompetent'. That's pretty pathetic for someone implying themself to be an insider in Linux development who can definitively prove everything I say is trolling bullshit - but already failed. Go back to installing Mandrake three times a day and reading kerneltrap + Slashdot to get the 'inside' development stories.
Bzzzt try again, troll. NPTL has been in Linux since the middle of the 2.5 development cycle.
/usr/portage/dev-libs/glibc/glibc-2.3.4.20040619-r 2.ebuild
# Minimum kernel version we support
# (Recent snapshots fails with 2.6.5 and earlier)
MIN_KERNEL_VERSION="2.6.5"
Headshot. If it hadn't changed, there'd be no reason that newer user-land nptl libraries wouldn't work with older kernels. Read up before you think you're fighting 'trolls'.
And there was no "new SCSI subsystem" in 2.5 or 2.6 period.
http://www.webservertalk.com/message841936.html
Sorry, really bad wording on my part, based on some confusing Slash comments I read before. Hardly trolling, you'll notice.
Linux does not cater for incompetant people
No, I actually did check everything, and have been configuring and compiling Linux kernels with mostly success (except weird shit like this) for years. There's no magic to it, don't pretend to be a technical expect because you've never found a bug. Same goes for that "absolutely no idea when it comes to kernel coding" assumption: I am a coder and I do know when a warning is an error in disguise. By the looks of it the calling parameters of something internal changed (since this did not happen in 2.6.9) but not all drivers were updated, and nobody cared. If this is not the case, they should fix compile warnings: the BSDs do, because warnings left over in 'stable' branches signify lazy/careless developers (i.e. Linux contributors).
Nice AC posting by the way, if you're going to make insulting claims against someone, do it with your own name or risk not being taken seriously. If I wanted to troll, which I don't, I wouldn't do it under my own name. From this perspective we gather that you're the troll and I'm making honest observations. Have a really bad day, you deserve it.
The first time I booted 2.6.3 (mainline, under Slackware, previously 2.6.2 with less problems) every file opened for writing would be truncated and never written to. My entire home dir was mangled and it took a very long painful sitting of deleting and re-configuring before things worked again, and even then there were flake outs. I never booted 2.6.3 again.
2.6 then had some large changes (nptl, new SCSI subsystem without warning, etc.) and now at 2.6.10 seems to be at least sort-of stable, but there are compile warnings in wireless drivers I think are actual mistakes and am glad I don't have that hardware. On the other hand, and this is a big thing in favor of the BSD style kernel configuration, with 2.6.10 a certain magical combination of kernel options left me without a console outside of X (and no, I did not ask it to use serial console), and reconfiguring from scratch was the only thing that fixed it. I still have not been able to reproduce this (but remember it happening with an earlier kernel, might have been a 2.4) or even figure out what option/combination caused it. I mean, that's pretty f#ed up.
OpenBSD basically needs a bigger contributing (at least PRing) user base. So does NetBSD of course. The number of developers is fine in both because they are talented and can work together (oppose thousands of Linux devs who still can't engineer for stability), but the user bases are too small to really test everything at once.
Shame isn't it? With Linux stealing the spotlight all the other more deserving projects are left lacking users.
What's wrong with the grammar? Try re-reading.
And no, Linux has never had a full package tree, because LINUX IS NOT AN OPERATING SYSTEM. It's a kernel. DISTRIBUTIONS have package trees, but they don't release at the same time new kernel versions do, so being able to install a distro from the latest kernel isn't always possible until the next release; this becomes important when your installation requires new drivers only found in the latest kernel.
FreeBSD's SMP is not substandard, by all rights it's one of the better free ones, its entire code base just needs a LOT more work before it's 'there'. And I doubt you'll find a definitive SMP 'standard' there too. What, Linux is the standard for everything? Looks like all the BSDs have super-standard security, quality assurance, release engineering, consistency, documentation and developer support. I'll also remind people that eth1394 (Linux ip-over-firewire driver) is less than half as fast as FreeBSD's fwe and fwip, and has not improved in this regard since 2.4 days. Hardly anyone even notices; but benchmark it on your home machines and just TRY to get netperf to report more than 116Mb/s throughput.
http://bsd.slashdot.org/comments.pl?sid=135621&cid =11322387
Enough said.
What's your problem? I said initial support, which is true: http://www.feyrer.de/NetBSD/blog.html#20050121_142 7
And I was already aware of those 'problems', but if every time something like that came up the whole project was abandoned, do you think any of the projects would be where they are?
And it's not trolling to say FreeBSD is losing its lustre. That's actually entirely true. It's not dead yet, and it might recover, but in the mean time, there are much better alternatives to running FreeBSD 5. NetBSD 2 is one, DragonFly is another, hell even Linux has been more stable lately. I also said all of these things MUCH earlier than that benchmark was released, it just happens to support the argument.
Why do you have to call any observation which puts one project ahead of another a troll? It doesn't even look like you read what I said.
Why not run NetBSD/xen? In -current it even has initial support for Xen 2.
And if you follow the development you'll note it's a much better contender for making use of the platform anyway. NetBSD's simpler algorithms and amazingly good code work well where you have to minimize the raw overhead, which is useful for virtualization like Xen. FreeBSD's advantages are thinning out fast.
What RAID cards are you having trouble supporting? As far as I've seen the gap between Linux supporting a device and Free/NetBSD (I don't track Open) supporting the same device is down to at most a month, and not necessarily with the BSDs behind (especially since they have full-featured releases and snapshots, whereas Linux /distributions/ have to catch up to support the new hardware out of the box).
Linux drivers: "it compiles and works well-enough on the architecture I tried it in, it's going in the stable tree"
FreeBSD drivers: "it works stably on the architectures it's possible to use in, and not too many PRs are filed about it; it's going in the stable tree"
NetBSD drivers: "it is abstracted to work properly regardless of architecture or topology, PRs aren't being filed, and it's had time to stew; it's going in the stable tree"
Me, I'm still waiting for the cdce driver to be MFC'd in netbsd-2 so I can consider using it in place of a Linux install working as a make-shift but must-work-well gateway I manage for a friend. I'm avoiding running -current because a lot of work is going to go in that might cause instability. None of this helps you but it's worth talking about.
The frequency of releases seems to be in inverse proportion to quality. Linux releases half-arsed 'stable' releases which may not even work very frequently. The three 'definitive' BSDs typically release twice a year (this is a hard-coded tradition for Open*) and, excusing the developmental nature of FreeBSD 5.x, these are very solid and already have a full package tree and ready documentation, etc. which Linux never has had.
DragonFly has made one major release and another is on the horizon (if you read the lists or talk in #dragonflybsd on efnet). The first had an installer bug, they fixed it and released a new one immediately. The next should be in much better shape as the system is getting much more contribution and testing now (heck, even I submitted a trivial patch in response to joerg's request for GMP->OpenSSL arbitrary precision math translation).
It's the difference between the intelligent man who sits quietly and the idiot who never shuts up. "Those who release the worst, release it the most often".
You might get away with a faster processor but using software floating point instructions. This way you can stick with a clean architecture and still get the floating, just with less efficiency.
But if it was up to me I'd look for a MIPS R5000. They have good floating point (powered the multimedia machines of the last generation, mostly SGI boxes) and maintain the advantages of low-power low-heat processors. They can also run in 64 bit mode but not many free OSs support this properly.
Try this out: Find yourself an SGI Indy with an R5000, stick NetBSD 2 on it (or Linux, but you're stuck with 2.4, and nothing is maintained any more), and use that. Indy machines have very good sound cards you can use to play the OGGs too... and the only fan part is the PSU. It SHOULD be powerful enough (at 150Mhz, the R5000 has integer ops *roughly*equivalent* to a P1 166, but floating ops are much better and without the bugs).
Yeah, there's that, but you also advertised its 2.6-ness and toolchain to build a new kernel. So it's not like the software on it didn't interest you :)
You'll have a hard time convincing anyone in-the-know to run Linux on anything that isn't x86. Its strategy towards porting is "convince the rest of the kernel it's an i386 and work like that", which fails on a lot of systems which are fundamentally different from i386, even if they have some things in common (ISA isn't the same everywhere, for instance).
NetBSD is portable in the Right Way. It actually abstracts architectures, busses, etc. completely, with nothing i386-specific leaving the i386 world (to combat confusion: ports that are LIKE i386 but wouldn't involve the same kernel and installation are exempt - e.g. Xen which doesn't need any hardware drivers but is still based on i386).
The same clean code and clean design that allow this kind of abstraction lead to a generally clean and stable system. NetBSD's worst stability problems occur only in device quirks which haven't yet been fully understood (you'll notice Linux has the same quirks but the hacks around them are usually done earlier, since Linux contributors don't care if something is a hack or not). Where the hardware is non-quirky, the system simply does not encounter problems. Simple as that. You could say the same for Linux to some extent, but for Linux, achieving stability is all about quirks for everything, even where it's not needed [see the first mention of i386 'emulation' above]. That's why the Linux kernel is an order of magnitude larger than NetBSD's but does not have the functionality to justify it.
I ended up typing a lot in response to very little, but the point is: Linux is marketable, so it gets around, NetBSD is proper, so it gets installed over Linux by anyone in their right mind.
Least Sensical Bullshit.
This is a desperate attempt to minimize fragmentation between distributions. Anyone in their right mind would run a BSD anyway, which are internally consistent.
Honestly, this is yet another example of how the GNU/Linux world fucks things up and then requires a 'victory for open source' [e.g. this standard being accepted] to be anywhere near as sensible as a BSD.
Windows: Where do you want to go today?
Linux: Where do you want to go tomorrow?
BSD: Well now that we're here...
Neither does NetBSD actually. And if you look at his post another time you'll notice he acknowledges their functionality. The hard fact is NetBSD is a speed daemon.
This is a single board, not really an arch...
NetBSD not supporting an architecture means one of two things: (1) the architecture has no processors with an MMU, or (2) no developer has the hardware
This explains no NetBSD on iPaq/etc for (1) and no NetBSD on ppc64/ia64 for (2).
As we can see by these examples (especially that nice post by the developer who supported this board under NetBSD), when it does support the hardware, it supports it properly, not just as x86 compatibility. That's the key difference between Linux and NetBSD; NetBSD is an operating system for every architecture, Linux is a kernel that can pretend to understand any architecture. I'll stick to NetBSD, thanks (even on i386 where possible).
I have mixed feelings about this. On the one hand, nothing in the post is particularly troll-like, since the claims about the politics and rotting code is entirely true and visible just by reading the lists and, well, code. On the other hand, anything that gets repeated in a troll-like manner but has negative perspective on a project, does in some way deserve to be called a troll. If it's worth saying, it's worth finding more than one way to say. If it's not worth saying, it's a troll.
It doesn't deserve +4 since it's just a copy, but I wouldn't mark it Troll either, personally.
The hard fact is, the developers politics is the reason DragonFly is out there today and admittedly doing a better job of being fast and stable than FreeBSD 5. While, yes, this has the potential to change in the future, the remaining number and skill of the developers means it will take a long time and be a bumpy ride.. before the system is anywhere near as fast as 4.x was for most of the same tasks. With everything MPSAFE and micro-optimised (at least another year of work) it will be good, but for most users it's not worth it right now. And, yes, this all happened because of politics.
Never thought I'd see it happen in FreeBSD but it did. Let's hope the other major OS projects keep their goals straight. Everyone aware that NetBSD 3 is going to have Solaris-like SMP locking, which is at least 90% of the reason FreeBSD 5 is the way it is?
I had a familiar problem (and not just me) of HTT not being SMP-like enough for 4.x to boot on it (trap on boot), this on a Dell Inspiron 5150 with a P4 3.06 w/ HTT. I ended up turning HTT off and keeping it that way (its advantages are wasted under the UNIXy OSs which have sufficiently responsive schedulers, but a lot more overhead and potentially buggy behavior appears when you turn use it).
Others did not have this problem (as the mailing lists spoke), so it's probably just a bit of confusion with APICs.
Apologies, I guess I misunderstood your post as saying the benchmarks were run on the wrong kind of system, rather than the benchmarks being used for sweeping assumptions.
So 5-STABLE is actually becoming worth using, you say? I'd like to try that, in fact I will when I can afford to (currently only two machines under my control and both are life-critical, for my life anyway). I've really wanted to get back into FreeBSD, it's highly usable and all, but my negative experience with 5.3 (yes, even tracking -STABLE for a month or so) put me off.
Has anything been said on the topic of the new, stupid disk sync style? Unlike all other systems which sync their dirty buffers quickly and know about it, FreeBSD 5 now can generate MORE dirty buffers during syncing and has to wait for 3 consecutive "no really, it's all clear this time" checks before being satisfied; and each check is spaced about a second. This results in possibly 5-10 seconds spent just waiting for disk syncing, which is digusting compared to near-instant syncs in other systems.
Anyway, does anyone want to run an Apache or other bench on a 64-bit SMP system with NetBSD 2_stable and FreeBSD 5.3-STABLE? Be worth a look I'd say. I wouldn't run a server based on small performance merit myself, it'd all come down to administration, cleanliness, security and stability... but then I don't pay for my hardware myself.
Actually, I just re-read your post, and noticed you have no clue at all. Let me explain: an algorithm is an algorithm. It doesn't matter if it's running on a machine with one or two procs, one instance of the algorithm will still only run on one processor at a time. It doesn't matter if it's 64 bit or 32 bit, since NetBSD is 64-bit-clean and hence doesn't have nasty side effects; let's assume FreeBSD is up to scratch on this as well. The algorithms will still scale the same and, if the instruction horse power is equivalent, take the same time.
What you said was "this is a great display of how a person can run, but it doesn't say anything about how he would run with a friend or on a Thursday!"
FreeBSD is already known to have made a lousy AMD64 implementation, a lousy SMP implementation (which, on 2-way and probably 4-way SMP machines, is actually SLOWER than NetBSD 2's giant lock model), and haven't even finished supporting their new kernel facilities on Sparc64 and Alpha.
So if this test was even possible on a 64 bit CPU in SMP mode, it wouldn't save FreeBSD. The source is out there though, so why not run it yourself? Of course it won't help because all of those are UP-centric micro benchmarks, and you'll just have to run, say, an Apache or MySQL bench.
We're waiting for your report eagerly.
Actually, it doesn't have a journalling file system YET, but the foundations are mostly in place. Read the mailing lists or at LEAST justin's blog.
At this rate give them a month or two to get something usable in, at the most. Brilliant developers.
Which is way overcomplicated to parse and often write. Have you completely missed the discussion in this thread about the ideal way of storing configurations? Your way is arguably even worse than XML which at least has libraries for it already.
I could argue Linux isn't even >=20% perfect, since its most optimal code is just in scheduling. Read the driver sources and try that post again.