I'm sorry to bring this up off topic, but is it true what we hear about PHK and DES being, as is said, assholes? I'm not sure if that was some lame troll or if it actually does have a factual base. Figured this was a good chance to ask since we have a dev in the house.
Okay. You're absolutely right, actually, and I'm sorry. My point really is that 5.3 is not the release everyone expects, and that it's probably best to wait at least until the 5-STABLE branch gets some of the locking and stuff resolved before unrolling it everywhere. I'm voicing it in the wrong ways I suppose. However, even as you posted, developers (DEVELOPERS) admit there are regressions in some areas, as I have already mentioned a dozen times on deaf ears/eyes. However, since they're officials and I'm a troll (well, I got modded troll once or twice), it's clear who gets listened to. Fair enough, I tried developing little insignificant (non-kernel) bits for FreeBSD but the devs usually just stopped emailing me after the first one or two, which didn't really help my case. I still used it until I finally decided it wasn't worth the regressions. Then I had a very painful time with Gentoo and now am seeing what NetBSD can offer. Depending on how 5-stable works out from here, I might take it up again.
How odd, I had regressions in disk performance (and not for his reasons), and so did everyone I asked/inspired to try FreeBSD 5 too. We must all be equally unlucky.
Okay, I give up, you're all a tough crowd. Since you would all rather meta-troll than try for yourself (which you admit you still haven't done, CryBaby) that's fine by me. Personally I couldn't care less anymore how your machines run. Anyone who doesn't bother testing something before saying it rules the planet doesn't deserve to have a well-oiled system. I thought Gentoo ricers were bad.
So the developer admits there are regressions in performance that apply to 5.3, but you insist 5.3 is not crap? Where's the logic there? The first release not to have regressions, at least not notable ones (run bonnie and see), will be the first non-crap 5.x release. Then we'll talk.
You're on my stubborn list. Even devs admit 5.3 has regressions which support what I say, and you still think you're right in saying it's just as fast as ever, even though it clearly isn't. That's pretty intense shielding from logic you have. I don't care if I get called a troll, not like Slashdot is the source of all life... but that's just remarkably daft. "See, this developer admits that the performance sucks, so why are you saying the performance sucks? Troll".
You clearly have great ideas there (this is not sarcasm). You should actually tell people this. I've seen so many Linuxisms it hurts. Seeing the valiant efforts of ports/pkgsrc maintainers in trying to work around these annoying oversights is heart-breaking. Otherwise good (well, not always, but at least irreplacable software like hpoj) software ends up being very hard to get compiled and running without a lot of Makefile and script hacking.
It's not much better that people say "The X for Linux" (e.g. MPlayer) when it works just as well, sometimes better, on many other platforms, the BSDs being the closest but not only. Tip for devs: just because you wrote it on Linux doesn't mean it's FOR Linux. Linux is not the only platform that benefits from more software being written, and this should be credited. If it'll only work on POSIX-like platforms, "The X for POSIX" may sound less hype-worthy but at least it's accurate. Even so, it's better just to have "Another X" or "Yet Another X" (yacc, anyone?), since this is even more true these days, as most things people want have already been written at least once.
Open Source should be about sharing between its different platforms, not just with Linux then porting things to other systems as an afterthought. This is disgusting. Think of the quality products other systems have brought (just in this thread, for instance!) that are made properly portable because that's the Right thing to do, not out of sympathy for "those poor X users who don't have our superior layout and system calls" as Linux devs seem to take it very often.
(When I say 'X' I don't mean X11 or anything, I mean a general wildcard for any system/software name).
Actually, you're looking at it from the wrong perspective. For one thing, it's a work in progress. For another thing, in the same way the 'pure' OpenBSD OpenSSH was as stripped and system-dependent as possible, this will be maximally secure and hardened. When you add glue to make it stick to other systems, the glue can develop holes in it. That's the harsh fact.
When this is properly out of the oven, it'll be portable (or rather will have a gluey version) and it will be great. Every project OpenBSD devs undertake is hugely successful and gets integrated into other things very quickly. OpenSSH, PF, and now this will be too. Just you watch:)
Pretty much. It's the same there too. Everyone wants their project to do better.
The truth is, Linux and BSD are meant to coexist, but not for the same purposes. BSDs are meant as code bases that serve purposes really very well, cleanly and with dedication. They won't just accept "any patch that compiles" as has happened in Linux a lot. They're mostly there for the developers' ideas and needs, and usually users end up with the same needs.
On the other hand, Linux is meant to be the kernel for everyone, and this seems to be the case. It runs on just about everything (even if not in the mainline kernel) and it runs pretty well for the most part. The code base is not clean, but it is functional, which is what matters scientifically. It gets contribution from unspeakable numbers of developers and research and this shows - it has something it does much better than every other system (but yes, every other system has at least one thing it does much better than Linux).
Right now I run NetBSD because I wanted production machines I could stake my life on (still living). I use Linux on my laptop mostly because it has an NVidia card for which NetBSD drivers don't exist (or at least aren't easily downloadable:)). I like Linux, it performs really well. But I don't like that it's pretty dirty and hackish, which is certainly enough to put me off it. I get the same technical advantages with NetBSD but cleaner and with less maintainance (Good Thing).
Matter of opinion though. These things change. Hell I dropped FreeBSD (see tag) after a long time of worshipping it, just because 5.3 has too many regressions to appeal to me.
How does that make 5.3 any less crap? I'm not saying 5.4 or 5.5 or something won't be much better. I'm not entirely hopeful given the progress lately, but that's beside the point. The fact is, compared to any given 4.x FreeBSD or especially any OTHER BSD or Linux, FreeBSD 5.3 is slower, less stable (this does depend on your hardware and what you're doing, but the statistic is more things go wrong in 5.3), has more hack solutions, less of its own features working (SCHED_ULE+PREEMPTION fscks up, which is why the 'old' scheduler is the default in 5.3), and more errata items than some of the non-STABLE 5.x releases, which is a real worry.
What about this is hard to understand? Can all of you seriously think that a release with so many shortcomings is so great and heralds the Second Coming or something? Face it: it's crap. It's easy to think it's awesome on its own, hell I though that about the 5.3 branch before release (yes, this is after a long term of FreeBSD tuning experience, believe me I milked every last drop of performance out of it, and it still stank). The moment you compare it to anything else, and I am starting to believe anything else, you notice big problems. Ones that aren't likely to go away just with refinement over time.
I still haven't heard of more than two people alive who understand the core of the fine-grained SMP. Where are they? If a system is to develop further, it needs developers that know what's going on. Right now the benefit of open source (which is that many people can suggest many solutions and fixes can be picked out of a bunch) is entirely lost on the core of FreeBSD 5, since only two people understand it and they haven't done a splendid job of making it work properly either.
Now, I'm not saying the rest of FreeBSD 5 is bad, certainly not. Their UFS2 (I don't use background fsck, since in my experience it left the problems there until it eventually fixed them, the Wrong Thing), ACPI, RCNG (okay, that was from NetBSD), new networking improvements, Project Evil, etc. are all very handy. Now if only the core itself was clean and fast it'd be the perfect x86 OS. But since it drags behind, becomes unresponsive under very simple load (why hasn't anyone tried that CD-read thing I suggested? seriously, if you people want to prove me wrong, go ahead and try it yourselves), and still has that filthy and very intolerable moused+kbdcontrol nonsense I hoped they'd clean by 5.x... no, sorry, it's not the best anymore. Unless the developers pull off amazing magic, which is possible, FreeBSD may end up serving as an example to other systems of how not to steer the development process. Right now most of the handy functionality is also present in DragonFly BSD without the regressions, and apart from Project Evil and some ACPI features it's all in NetBSD as well. This is saying nothing of Linux which has admittedly had a lot of the 'new' functionality for years, even if very hackishly (but I don't want to argue about that now).
http://lists.freebsd.org/pipermail/freebsd-current/2004-October/040474.html
That's the first I could find. I had a better one that included OpenBSD as well, which many say has lousy performance but still schooled FreeBSD... I haven't found that link again. I'll keep you posted.
But seriously, if you're so smart, why not bench it yourself and prove me (and those other users) wrong? Refuting my 'trolling' with meta-trolling is not going to help you at all. At least my point has evidence. I haven't seen one benchmark in my life that includes a GEOM-enabled FreeBSD 5.x even coming close to any other [decent] OS in disk/FS access, but I've seen AND CONDUCTED many that show it being left in the dust.
So yes. Install FreeBSD 5 and FreeBSD 4, or NetBSD, or Linux, or whatever else, give them the same partition (they can all read/write UFS well enough) and run bonnie, tar, dd, whatever you want. If you can show me empirical proof that what I and many others are saying is rubbish, I'll take you seriously.
On the other hand, you Googled for "5.3" performance, even knowing 5.3 has been out barely a couple of days now. This problem has been around since much earlier in the 5 branch (exact point escapes me since I only started tracking recently, since late 5.2-CURRENT up to 5.3-STABLE a week or two before release) and if you had Googled for, say, "freebsd 5 slow disk" or something like that, your results might be more interesting. I suggest you try it. The useful pages get mixed in among a lot of unrelated rubbish, but you might learn something while you're at it.
Won't know until you find out. I don't see why not though. As for internet sharing, FreeBSD's is probably the easiest, because ipfw+natd is very hard to get wrong. Just read the docs and you'll be on your way.
Sure thing. From what I hear, server benches are especially helpful in this (apache, SQL, well it's up to you), IO benches/tools really tell the slow disk tale too (bonnie, time+dd, and so on).
It could also be really good to try those scalability benches Felix did ages ago. I did a couple and found Linux is still on top (NetBSD is still O(1) for pthread_create) but I didn't graph it or anything.
But I still advise you to see the performance with your own eyes (if you have and don't notice the drop, you should compare to 4.10). Benchmarks show it too, but the biggest and most disturbing difference is in use.
If you don't have much experience in this, I'd be glad to at least write up guides for fair, balanced installation and refinement of the systems (okay, except OpenBSD which I haven't yet tried, but it shouldn't be that hard), so we can at least fend off the worst of the "but you favor X over Y! that's not fair!" claims.
Any way you want to communicate on the project or is it something you'd rather mostly do on your own?
If you look closely, you may notice that most of my claims are directly against FreeBSD 5.3 (or often 5.x), except those places where something affects the future and past of FreeBSD (like that kbdcontrol/moused stuff).
If it does get better, then great, but it'll still be overcomplicated because of the locking. I'm not trolling, I'm presenting what lots of developers have already said. At this moment, NetBSD 2 offers a very convincing reason to switch, even if only to get the most out of your hardware investments.
On a related note, MPSAFE doesn't mean fast. The ata driver, the GEOM layer, and file systems are all MPSAFE now. You'd think disk/file access would be fast, right?
Only one of seemingly infinite posts made on this topic: http://lists.freebsd.org/pipermail/freebsd-current/2004-October/041009.html (read it carefully, even he says he's seen it's a common problem)
As a rough idea, on this hard disk now, FreeBSD 5 would max out at about 20MBps on a good day (~14 usually). FreeBSD 4 could easily get 30+, NetBSD (1.6 and 2 alike) pull off 35 (I've seen 40 during one run, under no load). Linux isn't even on the same chart for block access. This is about the physical limit, plus the extras that caching provides. FreeBSD 5 is about half as fast. This is the consensus - every bench shows it to be so. Even OpenBSD is up with NetBSD in this regard.
How can this get better? It's already fine-grained locked everywhere.
pkgsrc is about half as large as ports, unfortunately. However, the failure rate is virtually zero, so everything that is in pkgsrc will work without hacking around like you may have had to do for ports (I sure did).
Java, I haven't tried, but have heard it works just fine with the Linux binary compatibility ('emulation' is a dirty word that doesn't describe it properly).
NetBSD shouldn't lack any features Slack has, unless you mean Linux has some driver NetBSD doesn't (which isn't very common actually, unless you are really on the bleeding edge). The same software runs and it runs just as well, and it's easier to install than in slack, at least for the software that is in pkgsrc.
No real problem. It's all very simple, easy and solid. I now have a NetBSD gateway that's forwarding the packets this NetBSD workstation is generating posting this. Took the lesser part of a day to set it all up, and that's including several re-compiles of everything, and time to sit back and listen to MP3s:)
Some tips that will make your NetBSD life easy:
cvs with -rnetbsd-2-0 for sources, this gets you the 2.0 branch. This is much more stable than the -current branch, but lacks a couple of the newer drivers/features.
Do not use CFLAGS=, use CFLAGS+=. Better still, COPTS+= then CFLAGS+=COPTS. Forcing CFLAGS can break world builds in horrible ways (as I learnt - see current-users mailing list archive for this month) and this will bring you a lot of grief.
You cannot build an ISA-free kernel at this point in time. Weird, there's a lot of ISA-independent code that still somehow (historically) got left in ISA-related sources. They'll clean that up eventually.
Do NOT use UFSv2 with softdeps, and do not use an MFS/tmp unless you're ready to make it very large. UFSv1 is the safe choice, and having hard file systems for everything. You usually don't need softdeps on / but there's not much harm from it. Typically BSD systems have a very small/, at most 256MB, and mount/usr and/var separately.
Ack, I'm sorry, I just remembered 'make world' is no longer easily done in 5.x, they became paranoid. You can set HISTORIC_MAKE_WORLD or something in make.conf or separate the rules.
-Use RELENG_5, not RELENG_5_3. The latter is just errata/security fixes, the former is the true 'stable' branch for 5.x. It is going to get a lot more attention and MFC's.
-'make world kernel' works just as well, since you don't need to be paranoid about library changes this late in the release cycle.
-You can set KERNCONF=foo in make.conf to never have to type it on the command line. Same goes for every make variable you find yourself passing - this especially applies to Ports-specific variables that you want assumed during portupgrade/portinstall and when seeking dependencies.
Some things (especially the last bit) aren't covered in the handbook because they're meant to be simple enough for many to work out, but then again most don't:P
Gah yeah. I'm using the X.Org drivers under NetBSD and they take ages to unblank the screen (if they do at all), sometimes don't start the server at all, and draw random sh*t at the start of most server loads too. XVideo extension draws a blue line on the left of everything as well.
The only download link for the nvidia netbsd kit is down now, too.
Well this is just ridiculous. I get modded "troll" for dealing out harsh facts and observations, all because some mod didn't want to admit it anyway.
Okay, one more example of why FreeBSD in general is messy even in usage, and this even applies to pre-5. moused and kbdcontrol. Every mouse device must have a moused running behind it to get blended into the unified mouse device (/dev/sysmouse). This is a hack. No other OS needs this. You have to explicitly ask for what keyboard you want to use as the 'default' with kbdcontrol - but this is the only keyboard that will work at any one time! In all other systems, all keyboard and mice work together hotpluggably and without need of daemons or user configuration.
If you seriously defend this way of doing things, I'm glad you're not designing my operating system. This is a user-level peek at deeper coding problems. Why can't more than one keyboard work at once? If you can explain this properly and convincingly I might even take you seriously. But what you just showed are low-level benchmark results from ages ago that don't actually say anything about the topic, which is that the new fine-grained locking code is tangled and slows the system down. Of course it's not going to slow fork(), bind(), etc. down. If you knew anything about the topic and issue, you wouldn't have dreamed of posting that link, which is so irrelevant it offends slashdot by being there.
You missed something. As has been said many times on NetBSD mailing lists, and been empirically proven, NetBSD's scheduler activations has shown to be far superior to other 'scheduler activations' models (Sun's, that one, etc) in performance and apparently even cleanliness. Why? NetBSD developers know their stuff.
Basing an argument against one implementation based on the failure of another implementation is horribly stupid. Example: "IE sucks. IE is a browser. Therefore, all 'browsers' suck. Conclusion: Firefox sucks"
Yes, but unfortunately, removing debugging does not save it. I was hoping it would. Debugging was removed by default on 7th September, but the continuing status of FBSD 5.3 being slow as ass survives even now. Debugging is not the problem: the SMP locking spaghetti is. This cannot be 'turned off', unless you mean shutting the machine down.
You could of course try it yourself, it's pretty easy to see the difference, especially against FreeBSD 4.10, which was lightning fast compared to 5.3. I remember running 4.10 on an old P3 700 (not a bad machine by any right, just a bit behind the times) and it was a fully servicable server, gateway and workstation all at once, with enough power left over for compiling software. I loved that rig. Now it's in a university lab controlling large experiment hardware:( The point is that FreeBSD 4.10 breathed life into PC hardware better than you could imagine, but now NetBSD seems to do much the same thing but with more technology under its belt. Haven't tried DragonFly extensively so I can't comment there, but I've heard many devs want to drop old hardware support entirely, which would make them the first free nix to do so (but not necessarily a bad thing - just moving to a different market, and a chance to clean out compatibility cruft).
They realised they couldn't implement dozens of features/fixes they wanted for 5.3, and are holding them off until 5.4, the "Easy way out". This clearly shows that 5.3 is a rush release that does not meet their own requirements. It was already delayed for many months, during which it was very unstable, and only very recently did it get to a stage where it could actually stay up for long periods of time. For some users, this still isn't possible. Look at the errata for rootsakes!
At any rate, the new functionality which is aimed at high performance, actually has much lower performance. This is what I call a failure, and if you don't, we really must not speak the same language.
FreeBSD always achieved performance through best-case-everywhere optimization and scalability of algorithms for everything. Out of nowhere NetBSD beat it in scalability after two weeks' work (everyone knows this now). NetBSD had always focused on making things simple, portable, solid and logical. This kept it slower (much slower) for a long time, but now in 2.0 it's made huge headway with Scheduler Activations (even known to be faster than NPTL!). This makes a huge difference on its own, and the refined hardware support and everything has really topped it off.
I couldn't believe it myself, but every bench and 'sitting and using' observation proved NetBSD 2.0RC4 to be many times faster than FreeBSD 5.3, and about on par with Linux (but a notch behind in some synthetic tests). Disk access especially - everyone who has bonnie'd a FreeBSD 5.x system and compared this to another OS already knows what I'm talking about.
FreeBSD's model for complicating things in the quest for universal performance has now defeated itself, entirely owing to the terrible SMP model which has tangled it all. NetBSD on the other hand has made things much higher performing without complicating it, and so it does work faster in practice and not just in theory, and it works solidly and just as well on all platforms it supports. OpenBSD still needs a good threading system but in other respects it's not far behind, especially given its amazing security and quality-of-release record.
Before anyone labels me for trolling against FreeBSD, try it yourself, in benches as well as interactive usages, and compare it to NetBSD and Linux. Won't take long to see a pattern emerge.
You're one of the lucky ones, then. I had it running pretty stable, but then I had very regular hardware (by some coincidence a lot of devs have Dells, and all of my machines are Dells too - yours as well:)). Regardless it was pretty poky and from what I read lots of other hardware was flaky.
I'm sorry, I must have omitted that I've been using FreeBSD for ages and have been a very devout advocate, up until a few weeks ago when it hit me hard that FreeBSD 5 is a trainwreck. I DO know what I'm talking about, I've been reading the mailing lists, the TODO list, the CVS logs, the anecdotes and scientific tests alike, and my own experience using it on my machines. Yes, its functionality is very good, but its huge regression in performance, cleanliness (code cleanliness - just LOOK at it!), and stability certainly wards me away from using it further.
You seem to be flaming me hard there, assuming I don't know what I'm talking about. I know it all too well. Your performance increase is from an older 5.x, which makes sense. Compare it to a 4.10 on the same box, or a Linux, or certainly NetBSD 2. Any of those will run circles around FreeBSD in UP, and on two-way SMP even the BGL system of Net/OpenBSD is reported to outperform FreeBSD's "fine grained SMPng" through sheer cleanliness more than brilliant synchronization.
I repeat: I wish it wasn't true, but FreeBSD 5 is not a good thing. If, for instance, they had kept Matt Dillon in their team and let him lead the SMP work, it wouldn't have developed the spaghetti necessary to stick with their core SMP model (which, yes, only two people alive truly understand, and I dare you to find more), and then we would have an awesome release. Unfortunately they kicked him out and did a terrible model of their own, which has ruined the system in many technical aspects. Some of the devs even admit it's a flop (PREEMPTION bugs were largely talked about, and the race conditions in the locking even on UP lasted for months on months and certainly got a lot of discussion).
If you think FreeBSD 5.3 is a great thing, do what I always found made it notably suck: block-read off a data CD constantly while in an X environment. There is so much locking tangling going on that responsiveness will reduce to barely workable levels. This sometimes even makes watching DivXs off CD impractical. It may work differently for you right now, or it might be something they worked around (in which case they should fix those network cards they gave up on - read the errata in the release announcement - call that a solid release?), but I certainly noticed it, and root knows I'm not the only one. Yes, before you start smart-assing, I had DMA on. In NetBSD and Linux there is no performance/responsiveness hit from CD access, and they don't have 'wedges' in network cards either. NetBSD especially has very solid hardware support where it exists, Linux drives are usually good too. FreeBSD can no longer claim this - the drivers are as good as any other, but the kernel facilities managing them are tangled in locking and drag the system visibly and measurably.
I'm tired of defending my claims against your blind attack. Either try some more extensive tests and conclude for yourself, or stay off/. where at least some people can admit the truth no matter how much it hurts them to (oh and believe me it hurts).
Not so amazing. They started with x86 and built a lot of x86-centric code, and just managed to hack in support for a few other major architectures on which they could expect to run. If the code was even half as clean and logical as Net or OpenBSD it'd be easy to port, but this isn't the case.
It wouldn't be useful though. FreeBSD's real strengths are on x86 (possibly amd64/ia64, not sure on the status of those) and those strengths are diminishing as the other systems catch up, without regression. On PPC it would be just like the other systems, but so much slower (try 5.3 and see what I mean) and less matured. Why, then, would anyone want it?
Slashdot Mirror
Ack. See, when you use automated package installation (ports/pkgsrc/portage,etc) you don't notice these things :)
Thanks for the tipoff, and kudos to MPlayer devs. I love the software and now I can love the politics.
I'm sorry to bring this up off topic, but is it true what we hear about PHK and DES being, as is said, assholes? I'm not sure if that was some lame troll or if it actually does have a factual base. Figured this was a good chance to ask since we have a dev in the house.
Okay. You're absolutely right, actually, and I'm sorry. My point really is that 5.3 is not the release everyone expects, and that it's probably best to wait at least until the 5-STABLE branch gets some of the locking and stuff resolved before unrolling it everywhere. I'm voicing it in the wrong ways I suppose. However, even as you posted, developers (DEVELOPERS) admit there are regressions in some areas, as I have already mentioned a dozen times on deaf ears/eyes. However, since they're officials and I'm a troll (well, I got modded troll once or twice), it's clear who gets listened to. Fair enough, I tried developing little insignificant (non-kernel) bits for FreeBSD but the devs usually just stopped emailing me after the first one or two, which didn't really help my case. I still used it until I finally decided it wasn't worth the regressions. Then I had a very painful time with Gentoo and now am seeing what NetBSD can offer. Depending on how 5-stable works out from here, I might take it up again.
How odd, I had regressions in disk performance (and not for his reasons), and so did everyone I asked/inspired to try FreeBSD 5 too. We must all be equally unlucky.
Okay, I give up, you're all a tough crowd. Since you would all rather meta-troll than try for yourself (which you admit you still haven't done, CryBaby) that's fine by me. Personally I couldn't care less anymore how your machines run. Anyone who doesn't bother testing something before saying it rules the planet doesn't deserve to have a well-oiled system. I thought Gentoo ricers were bad.
So the developer admits there are regressions in performance that apply to 5.3, but you insist 5.3 is not crap? Where's the logic there? The first release not to have regressions, at least not notable ones (run bonnie and see), will be the first non-crap 5.x release. Then we'll talk.
You're on my stubborn list. Even devs admit 5.3 has regressions which support what I say, and you still think you're right in saying it's just as fast as ever, even though it clearly isn't. That's pretty intense shielding from logic you have. I don't care if I get called a troll, not like Slashdot is the source of all life... but that's just remarkably daft. "See, this developer admits that the performance sucks, so why are you saying the performance sucks? Troll".
You clearly have great ideas there (this is not sarcasm). You should actually tell people this. I've seen so many Linuxisms it hurts. Seeing the valiant efforts of ports/pkgsrc maintainers in trying to work around these annoying oversights is heart-breaking. Otherwise good (well, not always, but at least irreplacable software like hpoj) software ends up being very hard to get compiled and running without a lot of Makefile and script hacking.
It's not much better that people say "The X for Linux" (e.g. MPlayer) when it works just as well, sometimes better, on many other platforms, the BSDs being the closest but not only. Tip for devs: just because you wrote it on Linux doesn't mean it's FOR Linux. Linux is not the only platform that benefits from more software being written, and this should be credited. If it'll only work on POSIX-like platforms, "The X for POSIX" may sound less hype-worthy but at least it's accurate. Even so, it's better just to have "Another X" or "Yet Another X" (yacc, anyone?), since this is even more true these days, as most things people want have already been written at least once.
Open Source should be about sharing between its different platforms, not just with Linux then porting things to other systems as an afterthought. This is disgusting. Think of the quality products other systems have brought (just in this thread, for instance!) that are made properly portable because that's the Right thing to do, not out of sympathy for "those poor X users who don't have our superior layout and system calls" as Linux devs seem to take it very often.
(When I say 'X' I don't mean X11 or anything, I mean a general wildcard for any system/software name).
Actually, you're looking at it from the wrong perspective. For one thing, it's a work in progress. For another thing, in the same way the 'pure' OpenBSD OpenSSH was as stripped and system-dependent as possible, this will be maximally secure and hardened. When you add glue to make it stick to other systems, the glue can develop holes in it. That's the harsh fact.
:)
When this is properly out of the oven, it'll be portable (or rather will have a gluey version) and it will be great. Every project OpenBSD devs undertake is hugely successful and gets integrated into other things very quickly. OpenSSH, PF, and now this will be too. Just you watch
Pretty much. It's the same there too. Everyone wants their project to do better.
:)). I like Linux, it performs really well. But I don't like that it's pretty dirty and hackish, which is certainly enough to put me off it. I get the same technical advantages with NetBSD but cleaner and with less maintainance (Good Thing).
The truth is, Linux and BSD are meant to coexist, but not for the same purposes. BSDs are meant as code bases that serve purposes really very well, cleanly and with dedication. They won't just accept "any patch that compiles" as has happened in Linux a lot. They're mostly there for the developers' ideas and needs, and usually users end up with the same needs.
On the other hand, Linux is meant to be the kernel for everyone, and this seems to be the case. It runs on just about everything (even if not in the mainline kernel) and it runs pretty well for the most part. The code base is not clean, but it is functional, which is what matters scientifically. It gets contribution from unspeakable numbers of developers and research and this shows - it has something it does much better than every other system (but yes, every other system has at least one thing it does much better than Linux).
Right now I run NetBSD because I wanted production machines I could stake my life on (still living). I use Linux on my laptop mostly because it has an NVidia card for which NetBSD drivers don't exist (or at least aren't easily downloadable
Matter of opinion though. These things change. Hell I dropped FreeBSD (see tag) after a long time of worshipping it, just because 5.3 has too many regressions to appeal to me.
How does that make 5.3 any less crap? I'm not saying 5.4 or 5.5 or something won't be much better. I'm not entirely hopeful given the progress lately, but that's beside the point. The fact is, compared to any given 4.x FreeBSD or especially any OTHER BSD or Linux, FreeBSD 5.3 is slower, less stable (this does depend on your hardware and what you're doing, but the statistic is more things go wrong in 5.3), has more hack solutions, less of its own features working (SCHED_ULE+PREEMPTION fscks up, which is why the 'old' scheduler is the default in 5.3), and more errata items than some of the non-STABLE 5.x releases, which is a real worry.
What about this is hard to understand? Can all of you seriously think that a release with so many shortcomings is so great and heralds the Second Coming or something? Face it: it's crap. It's easy to think it's awesome on its own, hell I though that about the 5.3 branch before release (yes, this is after a long term of FreeBSD tuning experience, believe me I milked every last drop of performance out of it, and it still stank). The moment you compare it to anything else, and I am starting to believe anything else, you notice big problems. Ones that aren't likely to go away just with refinement over time.
I still haven't heard of more than two people alive who understand the core of the fine-grained SMP. Where are they? If a system is to develop further, it needs developers that know what's going on. Right now the benefit of open source (which is that many people can suggest many solutions and fixes can be picked out of a bunch) is entirely lost on the core of FreeBSD 5, since only two people understand it and they haven't done a splendid job of making it work properly either.
Now, I'm not saying the rest of FreeBSD 5 is bad, certainly not. Their UFS2 (I don't use background fsck, since in my experience it left the problems there until it eventually fixed them, the Wrong Thing), ACPI, RCNG (okay, that was from NetBSD), new networking improvements, Project Evil, etc. are all very handy. Now if only the core itself was clean and fast it'd be the perfect x86 OS. But since it drags behind, becomes unresponsive under very simple load (why hasn't anyone tried that CD-read thing I suggested? seriously, if you people want to prove me wrong, go ahead and try it yourselves), and still has that filthy and very intolerable moused+kbdcontrol nonsense I hoped they'd clean by 5.x... no, sorry, it's not the best anymore. Unless the developers pull off amazing magic, which is possible, FreeBSD may end up serving as an example to other systems of how not to steer the development process. Right now most of the handy functionality is also present in DragonFly BSD without the regressions, and apart from Project Evil and some ACPI features it's all in NetBSD as well. This is saying nothing of Linux which has admittedly had a lot of the 'new' functionality for years, even if very hackishly (but I don't want to argue about that now).
http://lists.freebsd.org/pipermail/freebsd-current /2004-October/040474.html
That's the first I could find. I had a better one that included OpenBSD as well, which many say has lousy performance but still schooled FreeBSD... I haven't found that link again. I'll keep you posted.
But seriously, if you're so smart, why not bench it yourself and prove me (and those other users) wrong? Refuting my 'trolling' with meta-trolling is not going to help you at all. At least my point has evidence. I haven't seen one benchmark in my life that includes a GEOM-enabled FreeBSD 5.x even coming close to any other [decent] OS in disk/FS access, but I've seen AND CONDUCTED many that show it being left in the dust.
So yes. Install FreeBSD 5 and FreeBSD 4, or NetBSD, or Linux, or whatever else, give them the same partition (they can all read/write UFS well enough) and run bonnie, tar, dd, whatever you want. If you can show me empirical proof that what I and many others are saying is rubbish, I'll take you seriously.
On the other hand, you Googled for "5.3" performance, even knowing 5.3 has been out barely a couple of days now. This problem has been around since much earlier in the 5 branch (exact point escapes me since I only started tracking recently, since late 5.2-CURRENT up to 5.3-STABLE a week or two before release) and if you had Googled for, say, "freebsd 5 slow disk" or something like that, your results might be more interesting. I suggest you try it. The useful pages get mixed in among a lot of unrelated rubbish, but you might learn something while you're at it.
Won't know until you find out. I don't see why not though. As for internet sharing, FreeBSD's is probably the easiest, because ipfw+natd is very hard to get wrong. Just read the docs and you'll be on your way.
Sure thing. From what I hear, server benches are especially helpful in this (apache, SQL, well it's up to you), IO benches/tools really tell the slow disk tale too (bonnie, time+dd, and so on).
It could also be really good to try those scalability benches Felix did ages ago. I did a couple and found Linux is still on top (NetBSD is still O(1) for pthread_create) but I didn't graph it or anything.
But I still advise you to see the performance with your own eyes (if you have and don't notice the drop, you should compare to 4.10). Benchmarks show it too, but the biggest and most disturbing difference is in use.
If you don't have much experience in this, I'd be glad to at least write up guides for fair, balanced installation and refinement of the systems (okay, except OpenBSD which I haven't yet tried, but it shouldn't be that hard), so we can at least fend off the worst of the "but you favor X over Y! that's not fair!" claims.
Any way you want to communicate on the project or is it something you'd rather mostly do on your own?
If you look closely, you may notice that most of my claims are directly against FreeBSD 5.3 (or often 5.x), except those places where something affects the future and past of FreeBSD (like that kbdcontrol/moused stuff).
t /2004-October/041009.html (read it carefully, even he says he's seen it's a common problem)
If it does get better, then great, but it'll still be overcomplicated because of the locking. I'm not trolling, I'm presenting what lots of developers have already said. At this moment, NetBSD 2 offers a very convincing reason to switch, even if only to get the most out of your hardware investments.
On a related note, MPSAFE doesn't mean fast. The ata driver, the GEOM layer, and file systems are all MPSAFE now. You'd think disk/file access would be fast, right?
Only one of seemingly infinite posts made on this topic: http://lists.freebsd.org/pipermail/freebsd-curren
As a rough idea, on this hard disk now, FreeBSD 5 would max out at about 20MBps on a good day (~14 usually). FreeBSD 4 could easily get 30+, NetBSD (1.6 and 2 alike) pull off 35 (I've seen 40 during one run, under no load). Linux isn't even on the same chart for block access. This is about the physical limit, plus the extras that caching provides. FreeBSD 5 is about half as fast. This is the consensus - every bench shows it to be so. Even OpenBSD is up with NetBSD in this regard.
How can this get better? It's already fine-grained locked everywhere.
pkgsrc is about half as large as ports, unfortunately. However, the failure rate is virtually zero, so everything that is in pkgsrc will work without hacking around like you may have had to do for ports (I sure did).
:)
/tmp unless you're ready to make it very large. UFSv1 is the safe choice, and having hard file systems for everything. You usually don't need softdeps on / but there's not much harm from it. Typically BSD systems have a very small /, at most 256MB, and mount /usr and /var separately.
Java, I haven't tried, but have heard it works just fine with the Linux binary compatibility ('emulation' is a dirty word that doesn't describe it properly).
NetBSD shouldn't lack any features Slack has, unless you mean Linux has some driver NetBSD doesn't (which isn't very common actually, unless you are really on the bleeding edge). The same software runs and it runs just as well, and it's easier to install than in slack, at least for the software that is in pkgsrc.
No real problem. It's all very simple, easy and solid. I now have a NetBSD gateway that's forwarding the packets this NetBSD workstation is generating posting this. Took the lesser part of a day to set it all up, and that's including several re-compiles of everything, and time to sit back and listen to MP3s
Some tips that will make your NetBSD life easy:
cvs with -rnetbsd-2-0 for sources, this gets you the 2.0 branch. This is much more stable than the -current branch, but lacks a couple of the newer drivers/features.
Do not use CFLAGS=, use CFLAGS+=. Better still, COPTS+= then CFLAGS+=COPTS. Forcing CFLAGS can break world builds in horrible ways (as I learnt - see current-users mailing list archive for this month) and this will bring you a lot of grief.
You cannot build an ISA-free kernel at this point in time. Weird, there's a lot of ISA-independent code that still somehow (historically) got left in ISA-related sources. They'll clean that up eventually.
Do NOT use UFSv2 with softdeps, and do not use an MFS
Good luck!
Ack, I'm sorry, I just remembered 'make world' is no longer easily done in 5.x, they became paranoid. You can set HISTORIC_MAKE_WORLD or something in make.conf or separate the rules.
A few things that might simplify life:
:P
-Use RELENG_5, not RELENG_5_3. The latter is just errata/security fixes, the former is the true 'stable' branch for 5.x. It is going to get a lot more attention and MFC's.
-'make world kernel' works just as well, since you don't need to be paranoid about library changes this late in the release cycle.
-You can set KERNCONF=foo in make.conf to never have to type it on the command line. Same goes for every make variable you find yourself passing - this especially applies to Ports-specific variables that you want assumed during portupgrade/portinstall and when seeking dependencies.
Some things (especially the last bit) aren't covered in the handbook because they're meant to be simple enough for many to work out, but then again most don't
Happy BSD use! And try the others, too.
Gah yeah. I'm using the X.Org drivers under NetBSD and they take ages to unblank the screen (if they do at all), sometimes don't start the server at all, and draw random sh*t at the start of most server loads too. XVideo extension draws a blue line on the left of everything as well.
The only download link for the nvidia netbsd kit is down now, too.
Well this is just ridiculous. I get modded "troll" for dealing out harsh facts and observations, all because some mod didn't want to admit it anyway.
Okay, one more example of why FreeBSD in general is messy even in usage, and this even applies to pre-5. moused and kbdcontrol. Every mouse device must have a moused running behind it to get blended into the unified mouse device (/dev/sysmouse). This is a hack. No other OS needs this. You have to explicitly ask for what keyboard you want to use as the 'default' with kbdcontrol - but this is the only keyboard that will work at any one time! In all other systems, all keyboard and mice work together hotpluggably and without need of daemons or user configuration.
If you seriously defend this way of doing things, I'm glad you're not designing my operating system. This is a user-level peek at deeper coding problems. Why can't more than one keyboard work at once? If you can explain this properly and convincingly I might even take you seriously. But what you just showed are low-level benchmark results from ages ago that don't actually say anything about the topic, which is that the new fine-grained locking code is tangled and slows the system down. Of course it's not going to slow fork(), bind(), etc. down. If you knew anything about the topic and issue, you wouldn't have dreamed of posting that link, which is so irrelevant it offends slashdot by being there.
You missed something. As has been said many times on NetBSD mailing lists, and been empirically proven, NetBSD's scheduler activations has shown to be far superior to other 'scheduler activations' models (Sun's, that one, etc) in performance and apparently even cleanliness. Why? NetBSD developers know their stuff.
Basing an argument against one implementation based on the failure of another implementation is horribly stupid. Example: "IE sucks. IE is a browser. Therefore, all 'browsers' suck. Conclusion: Firefox sucks"
Suddenly your point doesn't seem so valid.
Yes, but unfortunately, removing debugging does not save it. I was hoping it would. Debugging was removed by default on 7th September, but the continuing status of FBSD 5.3 being slow as ass survives even now. Debugging is not the problem: the SMP locking spaghetti is. This cannot be 'turned off', unless you mean shutting the machine down.
:( The point is that FreeBSD 4.10 breathed life into PC hardware better than you could imagine, but now NetBSD seems to do much the same thing but with more technology under its belt. Haven't tried DragonFly extensively so I can't comment there, but I've heard many devs want to drop old hardware support entirely, which would make them the first free nix to do so (but not necessarily a bad thing - just moving to a different market, and a chance to clean out compatibility cruft).
:)
You could of course try it yourself, it's pretty easy to see the difference, especially against FreeBSD 4.10, which was lightning fast compared to 5.3. I remember running 4.10 on an old P3 700 (not a bad machine by any right, just a bit behind the times) and it was a fully servicable server, gateway and workstation all at once, with enough power left over for compiling software. I loved that rig. Now it's in a university lab controlling large experiment hardware
Hoo boy I went off on a tangent there
They realised they couldn't implement dozens of features/fixes they wanted for 5.3, and are holding them off until 5.4, the "Easy way out". This clearly shows that 5.3 is a rush release that does not meet their own requirements. It was already delayed for many months, during which it was very unstable, and only very recently did it get to a stage where it could actually stay up for long periods of time. For some users, this still isn't possible. Look at the errata for rootsakes!
At any rate, the new functionality which is aimed at high performance, actually has much lower performance. This is what I call a failure, and if you don't, we really must not speak the same language.
Repeat for effect: Yes.
FreeBSD always achieved performance through best-case-everywhere optimization and scalability of algorithms for everything. Out of nowhere NetBSD beat it in scalability after two weeks' work (everyone knows this now). NetBSD had always focused on making things simple, portable, solid and logical. This kept it slower (much slower) for a long time, but now in 2.0 it's made huge headway with Scheduler Activations (even known to be faster than NPTL!). This makes a huge difference on its own, and the refined hardware support and everything has really topped it off.
I couldn't believe it myself, but every bench and 'sitting and using' observation proved NetBSD 2.0RC4 to be many times faster than FreeBSD 5.3, and about on par with Linux (but a notch behind in some synthetic tests). Disk access especially - everyone who has bonnie'd a FreeBSD 5.x system and compared this to another OS already knows what I'm talking about.
FreeBSD's model for complicating things in the quest for universal performance has now defeated itself, entirely owing to the terrible SMP model which has tangled it all. NetBSD on the other hand has made things much higher performing without complicating it, and so it does work faster in practice and not just in theory, and it works solidly and just as well on all platforms it supports. OpenBSD still needs a good threading system but in other respects it's not far behind, especially given its amazing security and quality-of-release record.
Before anyone labels me for trolling against FreeBSD, try it yourself, in benches as well as interactive usages, and compare it to NetBSD and Linux. Won't take long to see a pattern emerge.
You're one of the lucky ones, then. I had it running pretty stable, but then I had very regular hardware (by some coincidence a lot of devs have Dells, and all of my machines are Dells too - yours as well :)). Regardless it was pretty poky and from what I read lots of other hardware was flaky.
a ses/5.3R/todo.sgml (for history on problems and how they 'solved' them)
For all of those who still don't believe me when I say FreeBSD 5.3 is a lousy release, see these links and decide for yourself:
http://www.freebsd.org/releases/5.3R/errata.html
http://www.freebsd.org/cgi/cvsweb.cgi/www/en/rele
...and the mailing lists. It's scary.
I'm sorry, I must have omitted that I've been using FreeBSD for ages and have been a very devout advocate, up until a few weeks ago when it hit me hard that FreeBSD 5 is a trainwreck. I DO know what I'm talking about, I've been reading the mailing lists, the TODO list, the CVS logs, the anecdotes and scientific tests alike, and my own experience using it on my machines. Yes, its functionality is very good, but its huge regression in performance, cleanliness (code cleanliness - just LOOK at it!), and stability certainly wards me away from using it further.
/. where at least some people can admit the truth no matter how much it hurts them to (oh and believe me it hurts).
You seem to be flaming me hard there, assuming I don't know what I'm talking about. I know it all too well. Your performance increase is from an older 5.x, which makes sense. Compare it to a 4.10 on the same box, or a Linux, or certainly NetBSD 2. Any of those will run circles around FreeBSD in UP, and on two-way SMP even the BGL system of Net/OpenBSD is reported to outperform FreeBSD's "fine grained SMPng" through sheer cleanliness more than brilliant synchronization.
I repeat: I wish it wasn't true, but FreeBSD 5 is not a good thing. If, for instance, they had kept Matt Dillon in their team and let him lead the SMP work, it wouldn't have developed the spaghetti necessary to stick with their core SMP model (which, yes, only two people alive truly understand, and I dare you to find more), and then we would have an awesome release. Unfortunately they kicked him out and did a terrible model of their own, which has ruined the system in many technical aspects. Some of the devs even admit it's a flop (PREEMPTION bugs were largely talked about, and the race conditions in the locking even on UP lasted for months on months and certainly got a lot of discussion).
If you think FreeBSD 5.3 is a great thing, do what I always found made it notably suck: block-read off a data CD constantly while in an X environment. There is so much locking tangling going on that responsiveness will reduce to barely workable levels. This sometimes even makes watching DivXs off CD impractical. It may work differently for you right now, or it might be something they worked around (in which case they should fix those network cards they gave up on - read the errata in the release announcement - call that a solid release?), but I certainly noticed it, and root knows I'm not the only one. Yes, before you start smart-assing, I had DMA on. In NetBSD and Linux there is no performance/responsiveness hit from CD access, and they don't have 'wedges' in network cards either. NetBSD especially has very solid hardware support where it exists, Linux drives are usually good too. FreeBSD can no longer claim this - the drivers are as good as any other, but the kernel facilities managing them are tangled in locking and drag the system visibly and measurably.
I'm tired of defending my claims against your blind attack. Either try some more extensive tests and conclude for yourself, or stay off
Not so amazing. They started with x86 and built a lot of x86-centric code, and just managed to hack in support for a few other major architectures on which they could expect to run. If the code was even half as clean and logical as Net or OpenBSD it'd be easy to port, but this isn't the case.
It wouldn't be useful though. FreeBSD's real strengths are on x86 (possibly amd64/ia64, not sure on the status of those) and those strengths are diminishing as the other systems catch up, without regression. On PPC it would be just like the other systems, but so much slower (try 5.3 and see what I mean) and less matured. Why, then, would anyone want it?