Re:openbsd is so slow
on
OpenBSD 3.6 Live
·
· Score: 2, Interesting
That wasn't actually a reply to what I said at all, but I agree with you anyway, NetBSD is the one for miling performance out of machines and software. I find it usually leaves Linux in the dust too, but I haven't tried SMP.
Don't all the BSDs offer binary snapshots anyway? NetBSD churns them out every 3 days for people/machines that can't build from source easily enough.
Binary updates would be handy, or better still, a mechanism that fetches security patches automatically, merges them into the source tree, recompiles only the bits that are needed, and installs them, then prompts you (/var/log/security would be fine even) to restart the server (or optionally does it on its own, if it's no showstopper to lose the server for a second).
It's never bothered me though. The very very few security patches the BSDs come up with get merged into the source tree, and I'm a "build from source once enough things change" kind of guy.
Sorry to be off-topic for a moment, but this has been killing me, has anyone compiled a netbsd-2-0 world without having it break on groff? I've tried everything but it seems that flex/whatever doesn't churn out.h's like it should.
iptables modelled after ipfilter? I had always been under the impression it was moddled out of clay.
No user->kernel facility interface should ever be that dirty, much less a packet filter. Sure, the way it handles NAT and everything in one relatively uniform way is kinda handy, but the syntax and rigidness is disgusting. You can have a range of ports, or a list of ports, but not a list of ranges of ports. Don't even think about logging and acting on a packet in the same rule. Just pathetic.
ipfw, pf, ipfilter, they're all so much cleaner and so much more useful. With OpenBSD's new rule optimizer this is even more awesome. I still think natd/ipnat/ would be better off merging their functionality into the filter itself, even if only to make dynamic NAT rules by shell script easier.
The other BSDs have security levels. OpenBSD has a lot of things they don't, still, a large part of which is that it randomizes practically everything, making it very difficult for even a local attacker to know what the kernel is going to do next. They also yank out any external software that isn't getting properly treated against exploits, so their base package is still as firm as possible, and even ports are treated with great care.
In practice, FreeBSD and NetBSD are about as hard to exploit remotely, but they don't take care of every possible exploit, so in theory there are still some holes. NetBSD is still a lot faster than OpenBSD (unless some miracle happened and I missed it) so a 'real world' server might benefit more, but for a stronghold of impenetrable security that doesn't need every last drop of performance, OpenBSD is the choice.
Linux is nowhere near any of this. The code is sloppy and dirty (no, nobody can argue this, don't even try, just go read some yourself) and few distributions actually take security seriously. It does happen to perform better in many synthetic tests, and definitely on SMP, but the difference for most cases is so minimal that it's hard to understand why anyone would run Linux on a server and not a BSD.
I put it down to hype. Business love to advertise their adoption of Linux and their entrance into open-source, because that's what customers want to hear, especially Linux zealots. The businesses (hell, even governments now) certainly aren't scientific about it, using an "operating system" (I still call Linux a kernel, up to you) mashed together from seemingly infinite and inconsistent projects and parents'-basement-developed hacks. The source shows this, hell even configuration shows this, but they seem to be okay with this so long as it sounds good. Or, and I wouldn't be surprised, they've never heard of BSD.
Slackware: No decent package management. No easy way to recompile entire system, let alone update it. rc script structure that's been deprecated for decades. Installer has a 1/3 chance of breaking installation. Releases happen very rarely and no way to keep track of progress 'in between' releases.
Any BSD (include Gentoo): Source-based package management, with binary packages on the BSDs (no central packages in Gentoo though). Updating and rebuilding is always a one-line command. Entire operating system can be kept track of within the same hour as developers commit changes (BSD) or as things get released/re-masked (Gentoo). Security gets announced and resolved in-tree (BSD) or at least patched when somebody gets around to it (Gentoo, but their excuse being they don't maintain the code, just patch it). Apart from FreeBSD and DragonFly BSD, the systems can run on unspeakable amounts of different machines, archs and configurations, some better than others, but still possible.
Granted, Bob and the Church of the SubGenius are way cooler cultural icons than daemons and penguins, but that doesn't justify it. I started my Linux life with Slackware and if it hadn't been for my investigation into FreeBSD a while later I would have left it at that, never to return.
Provided, of course, the tree is thawed and includes the new WindowMaker:P
Gentoo Portage has caught up, I'm trying it now, but it seems to suck. Kernel granularity bug not fixed (and I sent them patches a year ago) and too many file paths have changed to make keeping your old configs safe. Font smoothing seems to apply only to title bars and sufficiently large fonts in themes, but not good yet (oppose Fluxbox which has had font smoothing for years and used it for everything cleanly).
Slashdot confirms: WindowMaker is dying And this is my favorite WM, too:(
Because Linux is not an operating system any more than an engine is a car. We're talking about Linux, which, on its own, is pretty useless.
That is, in fact, a heavy argument many use in favor of BSD (less important thanks to Linux distributions, many of which suck though), that you get a whole operating system, not just a kernel. You don't have to choose and integrate every component by hand.
And I wasn't saying great things about FreeBSD's core now, if you read other posts I've made I do in fact slander it as a hurtful trainwreck, but still the releases manage to be more stable and more tested (I have no idea where you pulled those 4.10 issues from... URL?) and certainly more likely to be adopted by serious users, than any given Linux 2.6 release (accepting that 2.4 is as stable as it will ever be).
If they get so much testing, how come all these huge bugs slip through to release? 2.6.8...
In something as huge and complicated as Linux has become, it's hard to test everything, but at the very least they could make things clean enough that changing something in one place doesn't break a completely unrelated system, which has happened in the past. Sure it's still better than some systems but if Linux really is going to lead the open-source 'operating system' [sic] market it'll have to do better than that.
It was forked from 4.x so large portions of userland are still 4.x's, but have had imports that bring many components up to 5.x and beyond (e.g. RCNG from NetBSD/FBSD5.x, gcc 3.4 snapshot [not default nor exclusive since some kernel/boot bits aren't compatible]).
DragonFly BSD is a "too good to be true" project, I would have to say. Its developers are highly talented and very quick in their work, and the stability has been very high given the massive changes made to vital kernel facilities. Sure there have been bumps but that always happens.
I have to say on the other hand, though, that DragonFly BSD's development appears to be like Linux (innovative code instead of sticking to tried-and-true [but assumed outdated] designs) but with higher quality and less contribution from randoms. It's progressing amazingly quickly and with minimal regressions, compared to FreeBSD 5.x which took years to get even near stable and has suffered enormous regressions in performance (except on SMP, the only thing it does much better than 4.x).
For DragonFly to really break the FBSD 4.x mold, it'll take a lot more surprising work. The keyboard system is just silly (one keyboard at a time?), and requiring a user-land daemon to support even mice is unheard of in modern systems. These are problems persisting without any resolve in FreeBSD, and would need to be addressed in DragonFly BSD if it's to share the stage with NetBSD 2.0 and Linux (which both have much cleaner device behavior).
Lucky - if I have EHCI in kernel, USB hubs don't work (the hubs are found but no devices beyond them).
FreeBSD's hotplugging architecture is pretty backward though, especially for USB (and you can only use one keyboard at a time). You have to have a user-space daemon spawn moused for mice and kbdcontrol (not even in default usbd.conf) to set the newly inserted keyboard as the default.
I don't know about OpenBSD (assuming it's more like NetBSD), but NetBSD and Linux do this all kernel-level, including transparently mixing multiple keyboard and mouse inputs, and don't need anything in user-space (assuming drivers are already in kernel or modules are loaded). This is clearly the better way to approach USB.
I have not tried EHCI in NetBSD but don't see any reason for it to be broken. As per the features list: "NetBSD was the first free OS to provide USB support, and was using USB on Apple Power Macintosh machines before Apple had MacOS X even booting."
If they can get it that Right first time, getting it Right in the next generation should come naturally.
Personally I noticed and was particularly worried by 5.x disk performance, where 4.x got almost the theoretical limit for any drive I used (but NetBSD seems to beat it by 10MB/s on average, sometimes even a couple of meg above theoretical limit - implies good VM and cache system really).
There are lots of things wrong with FreeBSD 5.x that have pushed FreeBSD from being (a couple of years ago) "fastest open-source operating system for x86" to one of the slowest. The SMP locking may have made SMP machines a bit better (so long as you don't have a keyboard or mouse... they're still Giant-locked, among many other drivers everyone uses) but UP has suffered tremendously, even if it is more 'responsive' (arguably so: has anyone tried reading off a CD and doing anything else?).
Linux seems to be going in a different direction, with 2.6's problems (over 2.4) being identified, investigated, resolved, tested, and replaced with new problems (see kerneltrap, half the forum threads are about recent Linux breakage). This is very unlikely to end, especially with the new development model ("testing, what testing? let vendors fix it").
NetBSD and OpenBSD: The only solutions now. Who wants to start a petition (or is there one?) to have NVidia and other drivers ported to these platforms? The FreeBSD ones work well, but are largely useless in light of the aforesaid regressions in quality and performance.
Here here. Haven't tried OpenBSD at all (might someday:)), but FreeBSD 5.x is measurably and visibly slower than 4.x and especially NetBSD (which I still find a notch faster than Linux, but I can't prove it). I'd been awe-struck by FreeBSD 4.9 and further, and had been really excited about 5.3's release, but the (admittedly pretty stable now) 5-STABLE tree isn't showing much promise.
NetBSD on the other hand is catching up in functionality (just needs a more complete userland and higher rate-of-success for world builds) while still remaining frighteningly portable and stable. I ran NetBSD 2.0RC4 on a puny SGI Indy R4600 with 540MB HDD (used
I'd been a FreeBSD advocate for a long time then faced a bleak truth with 5.3 (since it has become stable enough to use for a long time running, definitely enough time to notice huge deficiencies - EHCI is completely broken, for instance), and am now considering the NetBSD and Linux alternatives (the only saving throw for Linux being that the NVidia driver for NetBSD isn't 'done', and I definitely need it for one card [FX5200 Go] which the xfree/xorg driver can't handle)
Except that NetBSD is slower in basic operations than Linux, like network packet tx/rx overhead, syscall overhead, context switching, fork, page fault, page allocation, etc.
Really? Show us. No, I'm not saying you're wrong (I saw an *old* bench showing that Scheduler Activations had pretty slow context switching compared to Linux, and a note saying it would be worked on), but I just haven't heard of this, let alone seen conclusive and objective figures to back it up.
On a related note, I don't think anyone is arguing that Linux has a very fine grained and high performing core, it's everything around it. In much the same way, FreeBSD 5.x now has a very tight core, but the locking design and the number of things still Giant-Locked make the system run fiendishly slow anyway. You only notice these things in practice, and I have in fact noticed similar behavior with Linux (compiling two things at the same time - no, not using -j - can be a real exercise in patience)
On a related note, http://news.gw.com/netbsd.ports.i386/%3C2004072610 2903.GA21256@antioche.lip6.fr%3E
Linux gets slower using SMP on HTT (2.6.6, as I recall, the first mainline kernel to gain hyperthreading - please correct me), NetBSD gets faster. I think that, considering this, NetBSD'S SMP/SMT support is quite alright, and would be even better when hyperthreading scheduling policies are developed. Unless anyone shows figures that disprove this, of course... (invitation)
Oh, right, missed that 'core' in your post. It was lost in the waves of arrogance and ignorance.
Well what's your point? Code is code. Core or fringe doesn't matter, it all still compiles into one binary. One very dirty binary. How often routines get called doesn't justify not cleaning an infrequent algorithm.
I think your point was that you knew (or thought) that core code would be the focus of maximal effort, and so I wouldn't have a point there. But I said just code. And I showed you kernel code - not necessarily core, who really cares? - that justified my claims.
Go back to not knowing about arguments.
(This is getting boring)
Actually, while I'm here, may as well remind all Linux cleanliness evangelists: DEVFS
Core devs agree it's a crap sandwich and needs to be pulled out if not too many users base their lives on it. It clutters every driver with a device node, it is flaky and undermaintained, and flawed by design. Read the mailing lists.
FreeBSD 5.x has a devfs that is not overbearing, that is clean (including/dev itself, which is as clean as 'pure udev') and stable, entirely in kernel-land (unlike udev), and doesn't need any configuration anywhere to work, and on top of that has no adverse side effects. It is not functionally equivalent to devfs (which had the whole long name tree, to cover up for silly naming ideas early in Linux' life), nor udev, but as is UNIX philosophy, it is clean, solid, and does exactly what it was designed to do.
I can say the same things about ACPI integration (events just Work, no need to configure or write shell scripts just to automate power management), and NFS (Linux needs a local portmap daemon in userspace to mount NFS, else the mount process idles for particularly long times! How the hell is that clean behavior?).
What about reeBSD's pcm(4) vs ALSA?
Provides much the same functionality for most users, but it provides it more maturely, with kernel-level mixing (since many chipsets don't do hardware, and ALSA does not compensate), OSS compatibility as a feature - not as an extra layer - and a clean/dev/dsp* and/dev/mixer* naming structure that only gets cleaner with devfs, but still conforms to OSS standards. Multiple sound card support, very high quality sound itself, transparent and fast kernel-level channel mixing, and support for most of the same cards without the bugs... yes. That's why FreeBSD's sound is great. ALSA has more functionality in the end, which few people actually need anyway. It requires extra modules (at least for 2.4) and libraries (which are nothing resembling tight), had memory leak bugs up until about 1.0.4, requires yet more libraries to be compatible with OSS, and requires its own toolchain to control it (alsactl, alsamixer...), else your volumes are muted by default. Clever (cough).
Clean code not enough for many, clean design is where BSDs rule the scene. You cannot possibly refute that.
A colossal 4kb larger. And a lot of the code within is dirty, but you asked for file names only, right? The Linux one even uses spinlocks where they are completely unnecessary. It has many more functions than the NetBSD one, implying a heavily complicated driver handling concept, or possibly just a sloppy design. Real coders know how many primitive objects to split a design into, and it's clear who's the real coder:
Granted the NetBSD source (like the other non-DragonFly BSDs) is mostly in K&R C, which many consider 'dirty' (even if technically more interoperable, which pays dividends in NetBSD's ability to be compiled on virtually any system). That's splitting hairs though. It still manages to be smaller and tighter than the Linux code in spite of the 'redundant' argument naming of K&R.
Anything else you wanted? You seem owned to me. Go back to not knowing about code.
I won't bother replying at length to this one. It can only be a troll.
Fact: All of the BSDs were working decades before Linux was bootable, written [b]only[/b] by the best and brightest comp sci and soft. eng students (and above), and the UNIX before that by companies and some university contribution. Linux was, with all due respect to Linus Torvalds, a hack to have a non-BSD UNIX-like that worked on i386.
If you'll note, FreeBSD was much more scalable than Linux up until 2.6 arrived, and since no other open source system had this level of scalability (let alone performance and stability) it could only be from-scratch. Where were your PhD.s then? Coding for FreeBSD, obviously. They had the "proper design principles" and "algorithms" going very strongly, while Linux was applying dirty hacks to support new things (you should have seen the early USB support), having never bothered measuring scalability.
"Lifting" isn't too far off - the ULE scheduler was based at least in part on the O(1) scheduler, but without the problems (there were exceptional cases where the O(1) scheduler in Linux performed erratically, but ULE had much cleaner behavior). It had its own problems later, we know, but it doesn't really matter now.
What's your point though? Who cares if a BSD takes something from Linux? The number of things that Linux has taken from the BSDs is mind boggling. Early code bases didn't have network support until they ripped the BSD network stack ("lifted" definitely). They didn't do that right either - the new open BSDs continue to have infinitely better networking capabilities ("NetBSD 2.0 beats land speed record" twice, and there was that post regarding FreeBSD 5.x routing hundreds/thousands of times as much data over the network as Linux).
The only reason Linux rose to such glamor at all is media hype, certainly not technical merit. There was some geek romance in the notion of a kernel written for users who hate windows, more than for those who love UNIX. The BSDs couldn't care less about fighting off Windows, that's why their features are carefully planned and engineered (even at the cost of convenience for users), not just hacked on to make a cool headline and support pro-Linux evangelists.
Finally, I do not envy Linux. I have run it frequently with varying successes, and there was a time I used it exclusively with quite a bit of success. That's not the point - the point is I didn't know any better. At that stage I was happy mashing together tarballs and compilations into a sorta-working system, with no idea that there were systems out there that were Whole Operating Systems that fit together and did everything with attention to integration and cleanliness. Imagine my surprise.
Don't get me wrong, Linux has a lot of things that are persuasive towards its adoption. Just the options of file systems and curious drivers is enough for many users. But managability, reliability and good documentation? Go elsewhere. It's the equivalent of a group of casual engineers building a house while also putting in pieces (often entire rooms) that kids in their back yard built with Lego and mud, then having some entirely different party figure out how to live in the house and document it - often months out of date. Sometimes the lego and mud will be replaced by an engineer, maybe even well documented, but this will never apply to the whole thing.
I can't speak for every port out there (having only tried i386 myself, due to my own hardware limits), but I'd have thought that page at the end with the in-action shots of NetBSD on unbelievable hardware would have served as enough evidence. Of course you can't have every bit of software work everywhere - X on graphics calculator? - but enough does to get something interesting done. Look, there's one shot there of a guy running NetBSD on his StrongArm-based MP3 jukebox, capable of using the audio adapter and optical drives and input. What more do you want?
One thing that surprised me was that NetBSD doesn't have an XBox port. This could be because of the usual "why would any serious developer want that? It's a Linux geek thing", but then again the whole low-cost-okay-power side leaves room for questioning.
Nonsense. If that were true then trees would be the cleanest and most pure things around because they are passed by every day by dozens of gardeners. Didn't make sense, did it?
Seriously, your comment is stupid. BSDs have lots of developers, and moreso, the elitist attitude displayed by many is exactly what makes the code bases pure and clean.
I said it before and I'll say it again: Linux development is a hack orgy. They care about what they can say about things ("more interactivity to rule the desktop, cleaner this and that, runs on X and Y") and less what code issues could result. Con Kolivas himself pointed out that Linux 2.6's interactivity hacks were to cover up sloppy coding of drivers and kernel procedures that should have been low-latency by design, not because you interrupt them when it's convenient. The Linux code base has been gradually mangled together to suit the needs and wants (often just to brag) of developers and their sponsors/employers. Can something grown in this fashion, with lousy maintenance afterwards (read the mailing lists regarding devfs' problems, Mr. "more programmers must make it cleaner" clueless troll), possibly be cleaner than systems which are actually engineered to be clean and sensible, not just tacking on new hacks just because they'll sound good in changelogs?
Simple. NetBSD has infinitely higher quality and cleanliness. While it is reputed that Linux is now "more portable", not all of the ports are in the main source tree, not all are actively maintained and support all the features (let alone a userland, which NetBSD has for every arch). NetBSD's ports are, with few exceptions where things are just impractical on a device (e.g. Playstation 2 wouldn't really go far), all equally functional and stable, and all are in the main source tree, without needing to apply hacks and do unheardof installation procedures.
NetBSD's stability and cleanliness even put it ahead of FreeBSD, and leave Linux in the dust. Performance that stems from this same cleanliness and the developers' understanding of hardware and good software is pretty hardcore, especially in 2.0. SMP is supported but I haven't heard much about it.
Seriously, try it, you'd be amazed. NetBSD is not just for portability, that happens to be its edge against other BSDs (with OpenBSD close behind, for obvious historical reasons). It is the leader of cleanliness and code perfectionism, and hardware support is right up there (especially the way it handles USB devices is much better than FreeBSD and on par with Linux, albeit with less devices).
I got trolled, I have lost, I'm having a nice day, but at least I got that out there.
Quite a clueless thing to say. As the sharp knife above me pointed out, it's a BSD fork, specifically of FreeBSD 4.x some time ago. It imports fixes from FreeBSD, and FreeBSD imports fixes from it. Apparently the core kernel was replaced by Mach instead, but the userland is all still there, and they make no attempt to hide it. They couldn't have sprung for GPL'd software (would they want to, anyway? The FreeBSD base is much more solid, already a Complete Operating System, no more hacking-together needed) because of the restrictive licensing it imposes, wheras the BSD license only retains author recognition.
Why would it be based on Debian? Not only is its kernel not Linux (so no, MacOSX is not Linux either, again), and not only does the GPL make it impractical, but it wouldn't really make sense anyway, since Debian's real unique functionality is apt*, something completely useless in this case since no Linux binaries would run under MacOSX.
They could also have sprung from NetBSD (or OpenBSD?), which would probably have been easier since it already supported their architecture pretty well, but I'm sure they had their reasons.
Well then maybe it does deserve a try. What happened with 2004.1, though? I mean, the kernel versions themselves were fine on their own, but the ones patched and built for the CDs barely worked at all. 2004.0's smp kernel couldn't read from the second half of a hard disk in one of my machines, but that's the only problem I found with either of the 2004.0 kernels.
ftp://ftp.planetmirror.com.au/pub/gentoo/releases/ x86/
Ack, well, it looks like PlanetMirror still hasn't updated properly, the directory is there but it still denies permission. Good thing all my machines already run up-to-date Gentoo installs and so I have no pressing need for a new LiveCD:)
On a related note, can anyone testify to performance differences between framebuffered and vanilla? I noticed that framebuffered took ages to print every line, and since print calls are blocking, this meant the programs actually had to wait for this to be done before moving on, wasting a lot more time than relatively straight processing. Of course I should time this before basing a religion or major cult on it.
Slashdot Mirror
That wasn't actually a reply to what I said at all, but I agree with you anyway, NetBSD is the one for miling performance out of machines and software. I find it usually leaves Linux in the dust too, but I haven't tried SMP.
Don't all the BSDs offer binary snapshots anyway? NetBSD churns them out every 3 days for people/machines that can't build from source easily enough.
.h's like it should.
Binary updates would be handy, or better still, a mechanism that fetches security patches automatically, merges them into the source tree, recompiles only the bits that are needed, and installs them, then prompts you (/var/log/security would be fine even) to restart the server (or optionally does it on its own, if it's no showstopper to lose the server for a second).
It's never bothered me though. The very very few security patches the BSDs come up with get merged into the source tree, and I'm a "build from source once enough things change" kind of guy.
Sorry to be off-topic for a moment, but this has been killing me, has anyone compiled a netbsd-2-0 world without having it break on groff? I've tried everything but it seems that flex/whatever doesn't churn out
iptables modelled after ipfilter? I had always been under the impression it was moddled out of clay.
No user->kernel facility interface should ever be that dirty, much less a packet filter. Sure, the way it handles NAT and everything in one relatively uniform way is kinda handy, but the syntax and rigidness is disgusting. You can have a range of ports, or a list of ports, but not a list of ranges of ports. Don't even think about logging and acting on a packet in the same rule. Just pathetic.
ipfw, pf, ipfilter, they're all so much cleaner and so much more useful. With OpenBSD's new rule optimizer this is even more awesome. I still think natd/ipnat/ would be better off merging their functionality into the filter itself, even if only to make dynamic NAT rules by shell script easier.
The other BSDs have security levels. OpenBSD has a lot of things they don't, still, a large part of which is that it randomizes practically everything, making it very difficult for even a local attacker to know what the kernel is going to do next. They also yank out any external software that isn't getting properly treated against exploits, so their base package is still as firm as possible, and even ports are treated with great care.
In practice, FreeBSD and NetBSD are about as hard to exploit remotely, but they don't take care of every possible exploit, so in theory there are still some holes. NetBSD is still a lot faster than OpenBSD (unless some miracle happened and I missed it) so a 'real world' server might benefit more, but for a stronghold of impenetrable security that doesn't need every last drop of performance, OpenBSD is the choice.
Linux is nowhere near any of this. The code is sloppy and dirty (no, nobody can argue this, don't even try, just go read some yourself) and few distributions actually take security seriously. It does happen to perform better in many synthetic tests, and definitely on SMP, but the difference for most cases is so minimal that it's hard to understand why anyone would run Linux on a server and not a BSD.
I put it down to hype. Business love to advertise their adoption of Linux and their entrance into open-source, because that's what customers want to hear, especially Linux zealots. The businesses (hell, even governments now) certainly aren't scientific about it, using an "operating system" (I still call Linux a kernel, up to you) mashed together from seemingly infinite and inconsistent projects and parents'-basement-developed hacks. The source shows this, hell even configuration shows this, but they seem to be okay with this so long as it sounds good. Or, and I wouldn't be surprised, they've never heard of BSD.
Slackware: No decent package management. No easy way to recompile entire system, let alone update it. rc script structure that's been deprecated for decades. Installer has a 1/3 chance of breaking installation. Releases happen very rarely and no way to keep track of progress 'in between' releases.
Any BSD (include Gentoo): Source-based package management, with binary packages on the BSDs (no central packages in Gentoo though). Updating and rebuilding is always a one-line command. Entire operating system can be kept track of within the same hour as developers commit changes (BSD) or as things get released/re-masked (Gentoo). Security gets announced and resolved in-tree (BSD) or at least patched when somebody gets around to it (Gentoo, but their excuse being they don't maintain the code, just patch it). Apart from FreeBSD and DragonFly BSD, the systems can run on unspeakable amounts of different machines, archs and configurations, some better than others, but still possible.
Granted, Bob and the Church of the SubGenius are way cooler cultural icons than daemons and penguins, but that doesn't justify it. I started my Linux life with Slackware and if it hadn't been for my investigation into FreeBSD a while later I would have left it at that, never to return.
CVSup ports tree, portupgrade -a
:P
:(
Provided, of course, the tree is thawed and includes the new WindowMaker
Gentoo Portage has caught up, I'm trying it now, but it seems to suck. Kernel granularity bug not fixed (and I sent them patches a year ago) and too many file paths have changed to make keeping your old configs safe. Font smoothing seems to apply only to title bars and sufficiently large fonts in themes, but not good yet (oppose Fluxbox which has had font smoothing for years and used it for everything cleanly).
Slashdot confirms: WindowMaker is dying
And this is my favorite WM, too
Because Linux is not an operating system any more than an engine is a car. We're talking about Linux, which, on its own, is pretty useless.
That is, in fact, a heavy argument many use in favor of BSD (less important thanks to Linux distributions, many of which suck though), that you get a whole operating system, not just a kernel. You don't have to choose and integrate every component by hand.
And I wasn't saying great things about FreeBSD's core now, if you read other posts I've made I do in fact slander it as a hurtful trainwreck, but still the releases manage to be more stable and more tested (I have no idea where you pulled those 4.10 issues from... URL?) and certainly more likely to be adopted by serious users, than any given Linux 2.6 release (accepting that 2.4 is as stable as it will ever be).
If they get so much testing, how come all these huge bugs slip through to release? 2.6.8...
In something as huge and complicated as Linux has become, it's hard to test everything, but at the very least they could make things clean enough that changing something in one place doesn't break a completely unrelated system, which has happened in the past. Sure it's still better than some systems but if Linux really is going to lead the open-source 'operating system' [sic] market it'll have to do better than that.
It was forked from 4.x so large portions of userland are still 4.x's, but have had imports that bring many components up to 5.x and beyond (e.g. RCNG from NetBSD/FBSD5.x, gcc 3.4 snapshot [not default nor exclusive since some kernel/boot bits aren't compatible]).
DragonFly BSD is a "too good to be true" project, I would have to say. Its developers are highly talented and very quick in their work, and the stability has been very high given the massive changes made to vital kernel facilities. Sure there have been bumps but that always happens.
I have to say on the other hand, though, that DragonFly BSD's development appears to be like Linux (innovative code instead of sticking to tried-and-true [but assumed outdated] designs) but with higher quality and less contribution from randoms. It's progressing amazingly quickly and with minimal regressions, compared to FreeBSD 5.x which took years to get even near stable and has suffered enormous regressions in performance (except on SMP, the only thing it does much better than 4.x).
For DragonFly to really break the FBSD 4.x mold, it'll take a lot more surprising work. The keyboard system is just silly (one keyboard at a time?), and requiring a user-land daemon to support even mice is unheard of in modern systems. These are problems persisting without any resolve in FreeBSD, and would need to be addressed in DragonFly BSD if it's to share the stage with NetBSD 2.0 and Linux (which both have much cleaner device behavior).
Lucky - if I have EHCI in kernel, USB hubs don't work (the hubs are found but no devices beyond them).
:P
FreeBSD's hotplugging architecture is pretty backward though, especially for USB (and you can only use one keyboard at a time). You have to have a user-space daemon spawn moused for mice and kbdcontrol (not even in default usbd.conf) to set the newly inserted keyboard as the default.
I don't know about OpenBSD (assuming it's more like NetBSD), but NetBSD and Linux do this all kernel-level, including transparently mixing multiple keyboard and mouse inputs, and don't need anything in user-space (assuming drivers are already in kernel or modules are loaded). This is clearly the better way to approach USB.
I have not tried EHCI in NetBSD but don't see any reason for it to be broken. As per the features list: "NetBSD was the first free OS to provide USB support, and was using USB on Apple Power Macintosh machines before Apple had MacOS X even booting."
If they can get it that Right first time, getting it Right in the next generation should come naturally.
Unless somebody has evidence to the contrary
Personally I noticed and was particularly worried by 5.x disk performance, where 4.x got almost the theoretical limit for any drive I used (but NetBSD seems to beat it by 10MB/s on average, sometimes even a couple of meg above theoretical limit - implies good VM and cache system really).
There are lots of things wrong with FreeBSD 5.x that have pushed FreeBSD from being (a couple of years ago) "fastest open-source operating system for x86" to one of the slowest. The SMP locking may have made SMP machines a bit better (so long as you don't have a keyboard or mouse... they're still Giant-locked, among many other drivers everyone uses) but UP has suffered tremendously, even if it is more 'responsive' (arguably so: has anyone tried reading off a CD and doing anything else?).
Linux seems to be going in a different direction, with 2.6's problems (over 2.4) being identified, investigated, resolved, tested, and replaced with new problems (see kerneltrap, half the forum threads are about recent Linux breakage). This is very unlikely to end, especially with the new development model ("testing, what testing? let vendors fix it").
NetBSD and OpenBSD: The only solutions now. Who wants to start a petition (or is there one?) to have NVidia and other drivers ported to these platforms? The FreeBSD ones work well, but are largely useless in light of the aforesaid regressions in quality and performance.
Here here. Haven't tried OpenBSD at all (might someday :)), but FreeBSD 5.x is measurably and visibly slower than 4.x and especially NetBSD (which I still find a notch faster than Linux, but I can't prove it). I'd been awe-struck by FreeBSD 4.9 and further, and had been really excited about 5.3's release, but the (admittedly pretty stable now) 5-STABLE tree isn't showing much promise.
NetBSD on the other hand is catching up in functionality (just needs a more complete userland and higher rate-of-success for world builds) while still remaining frighteningly portable and stable. I ran NetBSD 2.0RC4 on a puny SGI Indy R4600 with 540MB HDD (used
I'd been a FreeBSD advocate for a long time then faced a bleak truth with 5.3 (since it has become stable enough to use for a long time running, definitely enough time to notice huge deficiencies - EHCI is completely broken, for instance), and am now considering the NetBSD and Linux alternatives (the only saving throw for Linux being that the NVidia driver for NetBSD isn't 'done', and I definitely need it for one card [FX5200 Go] which the xfree/xorg driver can't handle)
Except that NetBSD is slower in basic operations than Linux, like network packet tx/rx overhead, syscall overhead, context switching, fork, page fault, page allocation, etc.
0 2903.GA21256@antioche.lip6.fr%3E
Really? Show us. No, I'm not saying you're wrong (I saw an *old* bench showing that Scheduler Activations had pretty slow context switching compared to Linux, and a note saying it would be worked on), but I just haven't heard of this, let alone seen conclusive and objective figures to back it up.
On a related note, I don't think anyone is arguing that Linux has a very fine grained and high performing core, it's everything around it. In much the same way, FreeBSD 5.x now has a very tight core, but the locking design and the number of things still Giant-Locked make the system run fiendishly slow anyway. You only notice these things in practice, and I have in fact noticed similar behavior with Linux (compiling two things at the same time - no, not using -j - can be a real exercise in patience)
On a related note, http://news.gw.com/netbsd.ports.i386/%3C200407261
Linux gets slower using SMP on HTT (2.6.6, as I recall, the first mainline kernel to gain hyperthreading - please correct me), NetBSD gets faster. I think that, considering this, NetBSD'S SMP/SMT support is quite alright, and would be even better when hyperthreading scheduling policies are developed. Unless anyone shows figures that disprove this, of course... (invitation)
Oh, right, missed that 'core' in your post. It was lost in the waves of arrogance and ignorance.
Well what's your point? Code is code. Core or fringe doesn't matter, it all still compiles into one binary. One very dirty binary. How often routines get called doesn't justify not cleaning an infrequent algorithm.
I think your point was that you knew (or thought) that core code would be the focus of maximal effort, and so I wouldn't have a point there. But I said just code. And I showed you kernel code - not necessarily core, who really cares? - that justified my claims.
Go back to not knowing about arguments.
(This is getting boring)
Actually, while I'm here, may as well remind all Linux cleanliness evangelists: DEVFS
/dev itself, which is as clean as 'pure udev') and stable, entirely in kernel-land (unlike udev), and doesn't need any configuration anywhere to work, and on top of that has no adverse side effects. It is not functionally equivalent to devfs (which had the whole long name tree, to cover up for silly naming ideas early in Linux' life), nor udev, but as is UNIX philosophy, it is clean, solid, and does exactly what it was designed to do.
/dev/dsp* and /dev/mixer* naming structure that only gets cleaner with devfs, but still conforms to OSS standards. Multiple sound card support, very high quality sound itself, transparent and fast kernel-level channel mixing, and support for most of the same cards without the bugs... yes. That's why FreeBSD's sound is great. ALSA has more functionality in the end, which few people actually need anyway. It requires extra modules (at least for 2.4) and libraries (which are nothing resembling tight), had memory leak bugs up until about 1.0.4, requires yet more libraries to be compatible with OSS, and requires its own toolchain to control it (alsactl, alsamixer...), else your volumes are muted by default. Clever (cough).
Core devs agree it's a crap sandwich and needs to be pulled out if not too many users base their lives on it. It clutters every driver with a device node, it is flaky and undermaintained, and flawed by design. Read the mailing lists.
FreeBSD 5.x has a devfs that is not overbearing, that is clean (including
I can say the same things about ACPI integration (events just Work, no need to configure or write shell scripts just to automate power management), and NFS (Linux needs a local portmap daemon in userspace to mount NFS, else the mount process idles for particularly long times! How the hell is that clean behavior?).
What about reeBSD's pcm(4) vs ALSA?
Provides much the same functionality for most users, but it provides it more maturely, with kernel-level mixing (since many chipsets don't do hardware, and ALSA does not compensate), OSS compatibility as a feature - not as an extra layer - and a clean
Clean code not enough for many, clean design is where BSDs rule the scene. You cannot possibly refute that.
I didn't have to look far. Driver for Broadcom 440x network cards (like the one in the laptop I'm talking from)
/home/nbsd/src/sys/dev/pci/if_bce.c
/usr/src/linux/drivers/net/b44.c
/home/nbsd/src/sys/dev/pci/if_bce.c | grep func | wc -l /usr/src/linux/drivers/net/b44.c | grep func | wc -l
Linux 2.6.9-rc4-mm1: drivers/net/b44.c
NetBSD 2.0: src/sys/dev/pci/if_bce.c
Come on. The Linux one can even pass as bloated:
44K
48K
A colossal 4kb larger. And a lot of the code within is dirty, but you asked for file names only, right? The Linux one even uses spinlocks where they are completely unnecessary. It has many more functions than the NetBSD one, implying a heavily complicated driver handling concept, or possibly just a sloppy design. Real coders know how many primitive objects to split a design into, and it's clear who's the real coder:
dirk root # exuberant-ctags -x
22
dirk root # exuberant-ctags -x
69
Granted the NetBSD source (like the other non-DragonFly BSDs) is mostly in K&R C, which many consider 'dirty' (even if technically more interoperable, which pays dividends in NetBSD's ability to be compiled on virtually any system). That's splitting hairs though. It still manages to be smaller and tighter than the Linux code in spite of the 'redundant' argument naming of K&R.
Anything else you wanted? You seem owned to me. Go back to not knowing about code.
I won't bother replying at length to this one. It can only be a troll.
Fact: All of the BSDs were working decades before Linux was bootable, written [b]only[/b] by the best and brightest comp sci and soft. eng students (and above), and the UNIX before that by companies and some university contribution. Linux was, with all due respect to Linus Torvalds, a hack to have a non-BSD UNIX-like that worked on i386.
If you'll note, FreeBSD was much more scalable than Linux up until 2.6 arrived, and since no other open source system had this level of scalability (let alone performance and stability) it could only be from-scratch. Where were your PhD.s then? Coding for FreeBSD, obviously. They had the "proper design principles" and "algorithms" going very strongly, while Linux was applying dirty hacks to support new things (you should have seen the early USB support), having never bothered measuring scalability.
"Lifting" isn't too far off - the ULE scheduler was based at least in part on the O(1) scheduler, but without the problems (there were exceptional cases where the O(1) scheduler in Linux performed erratically, but ULE had much cleaner behavior). It had its own problems later, we know, but it doesn't really matter now.
What's your point though? Who cares if a BSD takes something from Linux? The number of things that Linux has taken from the BSDs is mind boggling. Early code bases didn't have network support until they ripped the BSD network stack ("lifted" definitely). They didn't do that right either - the new open BSDs continue to have infinitely better networking capabilities ("NetBSD 2.0 beats land speed record" twice, and there was that post regarding FreeBSD 5.x routing hundreds/thousands of times as much data over the network as Linux).
The only reason Linux rose to such glamor at all is media hype, certainly not technical merit. There was some geek romance in the notion of a kernel written for users who hate windows, more than for those who love UNIX. The BSDs couldn't care less about fighting off Windows, that's why their features are carefully planned and engineered (even at the cost of convenience for users), not just hacked on to make a cool headline and support pro-Linux evangelists.
Finally, I do not envy Linux. I have run it frequently with varying successes, and there was a time I used it exclusively with quite a bit of success. That's not the point - the point is I didn't know any better. At that stage I was happy mashing together tarballs and compilations into a sorta-working system, with no idea that there were systems out there that were Whole Operating Systems that fit together and did everything with attention to integration and cleanliness. Imagine my surprise.
Don't get me wrong, Linux has a lot of things that are persuasive towards its adoption. Just the options of file systems and curious drivers is enough for many users. But managability, reliability and good documentation? Go elsewhere. It's the equivalent of a group of casual engineers building a house while also putting in pieces (often entire rooms) that kids in their back yard built with Lego and mud, then having some entirely different party figure out how to live in the house and document it - often months out of date. Sometimes the lego and mud will be replaced by an engineer, maybe even well documented, but this will never apply to the whole thing.
I can't speak for every port out there (having only tried i386 myself, due to my own hardware limits), but I'd have thought that page at the end with the in-action shots of NetBSD on unbelievable hardware would have served as enough evidence. Of course you can't have every bit of software work everywhere - X on graphics calculator? - but enough does to get something interesting done. Look, there's one shot there of a guy running NetBSD on his StrongArm-based MP3 jukebox, capable of using the audio adapter and optical drives and input. What more do you want?
One thing that surprised me was that NetBSD doesn't have an XBox port. This could be because of the usual "why would any serious developer want that? It's a Linux geek thing", but then again the whole low-cost-okay-power side leaves room for questioning.
Nonsense. If that were true then trees would be the cleanest and most pure things around because they are passed by every day by dozens of gardeners. Didn't make sense, did it?
Seriously, your comment is stupid. BSDs have lots of developers, and moreso, the elitist attitude displayed by many is exactly what makes the code bases pure and clean.
I said it before and I'll say it again: Linux development is a hack orgy. They care about what they can say about things ("more interactivity to rule the desktop, cleaner this and that, runs on X and Y") and less what code issues could result. Con Kolivas himself pointed out that Linux 2.6's interactivity hacks were to cover up sloppy coding of drivers and kernel procedures that should have been low-latency by design, not because you interrupt them when it's convenient. The Linux code base has been gradually mangled together to suit the needs and wants (often just to brag) of developers and their sponsors/employers. Can something grown in this fashion, with lousy maintenance afterwards (read the mailing lists regarding devfs' problems, Mr. "more programmers must make it cleaner" clueless troll), possibly be cleaner than systems which are actually engineered to be clean and sensible, not just tacking on new hacks just because they'll sound good in changelogs?
Your parents must be so proud.
Simple. NetBSD has infinitely higher quality and cleanliness. While it is reputed that Linux is now "more portable", not all of the ports are in the main source tree, not all are actively maintained and support all the features (let alone a userland, which NetBSD has for every arch). NetBSD's ports are, with few exceptions where things are just impractical on a device (e.g. Playstation 2 wouldn't really go far), all equally functional and stable, and all are in the main source tree, without needing to apply hacks and do unheardof installation procedures.
NetBSD's stability and cleanliness even put it ahead of FreeBSD, and leave Linux in the dust. Performance that stems from this same cleanliness and the developers' understanding of hardware and good software is pretty hardcore, especially in 2.0. SMP is supported but I haven't heard much about it.
Seriously, try it, you'd be amazed. NetBSD is not just for portability, that happens to be its edge against other BSDs (with OpenBSD close behind, for obvious historical reasons). It is the leader of cleanliness and code perfectionism, and hardware support is right up there (especially the way it handles USB devices is much better than FreeBSD and on par with Linux, albeit with less devices).
I got trolled, I have lost, I'm having a nice day, but at least I got that out there.
Fear this: http://netbsd.org/gallery/in-Action/ - and those were much older releases.
Quite a clueless thing to say. As the sharp knife above me pointed out, it's a BSD fork, specifically of FreeBSD 4.x some time ago. It imports fixes from FreeBSD, and FreeBSD imports fixes from it. Apparently the core kernel was replaced by Mach instead, but the userland is all still there, and they make no attempt to hide it. They couldn't have sprung for GPL'd software (would they want to, anyway? The FreeBSD base is much more solid, already a Complete Operating System, no more hacking-together needed) because of the restrictive licensing it imposes, wheras the BSD license only retains author recognition.
Why would it be based on Debian? Not only is its kernel not Linux (so no, MacOSX is not Linux either, again), and not only does the GPL make it impractical, but it wouldn't really make sense anyway, since Debian's real unique functionality is apt*, something completely useless in this case since no Linux binaries would run under MacOSX.
They could also have sprung from NetBSD (or OpenBSD?), which would probably have been easier since it already supported their architecture pretty well, but I'm sure they had their reasons.
Mel: http://www.catb.org/jargon/html/story-of-mel.html
No debugging tools there, if any tools at all.
Not that it needs one ;)
But more proof that BSD is not dead. It gets support from the companies that know what they're doing.
Just you wait for 5.3-RELEASE!
Well then maybe it does deserve a try. What happened with 2004.1, though? I mean, the kernel versions themselves were fine on their own, but the ones patched and built for the CDs barely worked at all. 2004.0's smp kernel couldn't read from the second half of a hard disk in one of my machines, but that's the only problem I found with either of the 2004.0 kernels.
/ x86/ :)
ftp://ftp.planetmirror.com.au/pub/gentoo/releases
Ack, well, it looks like PlanetMirror still hasn't updated properly, the directory is there but it still denies permission. Good thing all my machines already run up-to-date Gentoo installs and so I have no pressing need for a new LiveCD
On a related note, can anyone testify to performance differences between framebuffered and vanilla? I noticed that framebuffered took ages to print every line, and since print calls are blocking, this meant the programs actually had to wait for this to be done before moving on, wasting a lot more time than relatively straight processing. Of course I should time this before basing a religion or major cult on it.