It's fatally exaggerated. Even without KDE's tools the worst you have to do in a sufficiently convenient distribution (Gentoo, for instance) is copy the fonts to the right directory and 'ttmkfdir', then xset fp rehash or restart the server. If the directory is specified in xorg.conf it's done.
Unified smoothing is another story (but GTK2/Xft just do it for you by default) but not much harder. Still something I never bothered with because us old-fashioned developer types find that extended sessions of smoothed fonts messes with the mind. At the very least, my aMSN, aterm and nedit should never have any smoothing at all. Does KDE's option force all things to smooth or what?
Why GPL fonts? GPL is a very encumbering license. You could stick them just in free domain, or if the author wants to maintain credit, BSD.
Ensuring all derivatives of the fonts and such are also GPL is just really, really silly. In fact talking about them with software licenses is already bad enough.
What's so strange about that? In capitalism you need money to get anything useful done. But open source is an attempt at communist ideals emulated within a capitalist reality. It doesn't work out without money.
Don't complain about open source, go complain about governments making it so hard to MAKE anything for free.
It depends on your definition of 'AI'. If people call the small algorithms defining how some characters should behave in basic games 'AI', this certainly is, even if it doesn't learn on its own.
TAI (think about it) and stop flaming. Thanks.
PS: If you think the syntax of most languages is very similar, you haven't ever once spoken fluent Russian. SystranSoft's translator, for instance, in spite of its occasional success in translating English/French, can't get a single thing right in Russian. It's too flexible and undertermined to easily parse. If you throw in slang it's virtually impossible without knowing the context and culture itself. Watch a movie translated by a certain 'Goblin' and you'll know what I mean. 'breaking sentences down into pieces' my ass.
If the changelog was right, 2.6.9 would have had a lot of "this patch breaks X" and 2.6.10 would have "fixes X again". I know a lot of people having flake-outs with 2.6.9 that are indulging in 2.6.10's very good stability. Realistically Linux 2.6 rarely gets worse from one version to the next, barring some 'oops'es that often come up very quickly so any users can downgrade again without much uptime.
You can easily dual-boot between an old and new kernel and simply fall back on the old one if you have problems with a new one. If you're running even a redundant cluster of servers this should be painless, the only problem occurs if you rely on a single server (in which case you're just asking for these problems).
That's pretty impressive. It takes quite a clever AI to read between lines and connect concepts, but I have to wonder how much of its 'understanding' was hard-coded rather than purely abstract. Would it be trivial to just stick in another language database and have it read translations of the article the same way?
Nevertheless it makes me feel like all the programming and design I've ever done is pathetic and I will never amount to anything. That's how it is in the software industry - always someone out there who makes you look bad.
So what you're saying is, I'm still entirely right because they lack CVS, but they just happen to provide something the desperate can use? Thanks, good to see you agree with me.
A branch cannot be stable and development at once, that's stupid. The closest that comes to this is DragonFly which has a careful engineering cycle which includes a tagging of 'stable' in the tree every time the whole system seems to work fine, usually/after/ a period of system instability brought on by a new subsystem. It works for them because typically only a few disruptive things happen at a time, and the developers are worryingly skilled. Neverthless these are NOT two branches, these are like point 'releases' in CVS instead of tarballs.
Hey, a unified GNU + linux utilities base package, with CVS access and a trimmed glibc (nobody needs 90% of that code), would really get it to a BSD status.
Imagine instead of copying out your.config, removing the old tree, unpacking/emerging a new one, then copying in the.config, make menuconfig to fill in the blanks, and have to build basically from scratch... you just cvs -zX up -dP from a 'linux' directory that isn't even a symlink, and carry on building. It probably is like this with the BK interface (but then I don't know), but the software/license itself is dubious. Tip: Don't talk to me about patching every time, that involves opening a browser or predicting a URL. If you have to do either of these to keep a base system component up to date, the system is flawed.
If you couldn't with 2.6.9, 2.6.9 won't be any better... logic, boy, logic.
ACPI should work anywhere that conforms (BIOSes earlier than 2000 usually have problems though), what kind of problems do you have? nForce2 has been supported for almost as long as it's existed. Throttle depends on processor, but I saw an nForce-specific driver there too. Temperature if it's available.
Just try it. It's a good release, rare in 2.6 so far, and should support all you've described... except MAYBE DRI (not just 3D acceleration) for the Radeon. Unless it's backwards compatible with the 9200, which I hear is the latest of the supported-in-tree cards. Google it.
Even that has quite a few changes... but yes, why call it a 'release candidate' if it has no chance of being the release? It's like having presidential candidates just advertise guys who could become the president.
I think Linux should use a CVS system like the BSDs, so you can keep a real-time track of the source tree and do away with the need for point releases every few weeks or so. Notice that the BSDs release a couple of times a year, but with CVS[up] they stay updated. And in the -stable branches they actually [gasp] make sure things work before committing them!
I find this to be one of the bigger leaps in 2.6, at least in that a new direction is coming out (let's excuse 2.6.6->.8 which had some disruptive/big changes we all know about). They're cleaning out deprecated driver code and making things more abstract, and also finally PCMCIA is split into its relevant sub-drivers (you'll know if you configure it; but note that your old config will NOT include PCMCIA when you just copy it over). I think this is a good step forward.
Another big change is that -march=pentium[234] is no longer used, but -march=i686 with -mtune (however I did NOT see mtune in action while building, so there might be an oops). This is because of gcc's bugs actually, but I like it more this way for other reasons.
I have now taken to building one kernel for two machines as I used to, in my BSD way, so as to save maintainance and re-emering sources all the time. Build once, install everywhere.
This is a good release, I like seeing that Linux 2.6 is finally going somewhere good. Now let's see some attempts at security and supporting all the ports, not just the fun ones.
Okay, I got modded Troll for explaining the release cycle and the current problems in 5.x. You have got to be kidding me. Are the mods here that short-sighted?
I can't really say much for/against the rest of it, without quoting lots of sources even on Slash itself... poke around.
A clean design doesn't have to lag behind. How long has Linux 2.6 been out? Over a year. They still haven't made respectable progress in bringing these 'lagging ports' up to date, even though the source itself can be worked over in one sitting by someone who knows what to do. Either they don't care or, as I suggested, their hack designs aren't possible any more, and it would require actually thinking about a design before writing it down.
My favorite example of Linux designs sucking is epoll compared to kqueue. I could go on for hours, but just read their manual pages and try to implement a server using both (have it respond to write, read and disconnection events for each client socket). You'll work it out very quickly.
See, that's the kind of thinking that leads to cruft and redundancy. NetBSD is so clean BECAUSE it cares about every port; when you run a new design or algorithm on a machine that takes a few days to start vi, you notice if there's a big real-world performance difference. If there is a bug on a driver that only surfaces when run on a certain architecture or bus, you notice and fix it. Linux has lots of redundant drivers and hacks, its portability is limited to pretending everything is x86. There are too many hacks and exceptions to keep it clean.
In 2.6, there was an effort to clean things up, and this meant the hacks were broken. But they were not replaced with solutions. NetBSD is about solutions. It's portable in the true sense of the word, not just in that it runs on 'relevant' architectures. Porting to ppc64, and so on, would be done quickly if the hardware was available; and rumor has it this will soon be the case. Just watch.
The one thing that worries me about NetBSD is that 3.0 is planned to have Solaris-like SMP, which is what killed FreeBSD 5. Now, NetBSD 2 got Scheduler Activations right where Solaris failed, and it might somehow fluke and get the SMP right too; but in all seriousness an LWKT implementation would be much simpler and, if DFly is any example, much better. All we can do is sit back and watch.
5.3-STABLE [sic] still has the interface death problem, at least it did for me. I would have kept it if not for that, despite the sluggishness it still had the composure and usability of a FreeBSD system. The other BSDs could learn from it, but then it might interfere with their designs of pure simplicity. Probably DragonFly will win there.
BIND and Sendmail definitely, but not CVS, at least not for NetBSD; it's simply the most sensible (and indeed only truly supported) way of fetching the system sources. Its footprint is small enough to make this worth it. Okay, so a binary package would be trivial to fetch, but this is still too much work to be worth it.
By the same token we could strip anything that less than 50% of the population uses, since the majority benefits. It's not that simple: the minority might just be more important - developers, for instance. The majority might not even notice. How many people cry themselves to sleep every night because gdb is in the base system, but even many DEVELOPERS don't use it? I'd rather take that out than cvs - it's easily 10x larger and.1x as used/useful.
All true, but a showstopper for any sufficiently frequent hardware configuration (in the case of Linux 2.6 on any Indy/Indigo/etc, EVERY instance of a certain machine class) is still a showstopper. Even so, the chances made to 2.6 should NOT have been so hackish as to break existing simple functionality so severely; NetBSD 2 had changes just as large made to its kernel, but runs on all the same machines it did before, in fact more. FreeBSD seems to be breaking its ports if they weren't already broken, so besides x86 it's essentially useless - and its use is mostly on x86 anyway where its NDIS wrapper and nvidia drivers are useful (AFAIK there is no x86_64 nvidia driver for FreeBSD, but I haven't actually looked either). For any other arch, NetBSD and Linux (and often OpenBSD) beat it hands down in every aspect that really matters.
You either need a special license or a legal copy of MSVC++ to use it. In this sense it is even more restrictive than MFC, though admittedly more useful.
GTK is GPL (or LGPL? anyway..) and hence can be used safely for most things, provided you don't use the code itself in a way that would conflict with the GPL. That's okay though.
It is now official. setagllib confirms: You're a tool
One more crippling foot kicked your dumb ass because you never learned to shut up around people stronger than you. Coming on the heels of a recent peer survey which plainly states that you are going blind from beating off to your mother too much, this news serves to reinforce what we've known along.
You don't have to be the Amazing Kreskin to predict your middle mouse button's future. The printoff is on the wall: Your button is worn out from too much damn copying and pasting. As many of us are already aware, you're an assbandit without even as many testicles as required to post with a name or with any original content.
Fact: Slash needs a regexp-based troll filter with automated banning
It just looks like one because it's big, copied-and-pasted, and has some 'buts' in it.
It's mostly true. Some things are a bit pessimal (I personally HAVE booted a non-SMP kernel on a hyperthreading machine) but everything about AMD64, network cards, and dubious quality is true. If FreeBSD 5 manages to clean up and escape from the tangled web of crap it's in, it will be great, but so far 5.3-STABLE hasn't made as much progress as you would expect from the long time it's been out. A similar thing is STILL happening in Linux 2.6 on 'less popular' architectures (SGI MIPS...) where it won't even boot, but this is normal for a system with its ideals - for a BSD it's virtually inexcusable to ship a release with many known showstoppers.
As OpenBSD devs said, sendmail has had a lot more testing and those security holes have been ironed out, so technically it's more 'reliable' than postfix which is much newer. But I agree to just take out MTAs entirely.
File systems, I wouldn't say FFS is so bad. It's very balanced; its performance is good enough in the real world, it takes very little processor and memory overhead (compared to the journalling file systems...), it survives even during sectors being mangled (ReiserFS dies because it has no superblock backups, and some others too). I wouldn't mind seeing a journalling FS in a BSD (well, there's LFS in NetBSD, which is log-structured and hence even more complete journalling), and in fact dillon has laid the foundations for such a system in DragonFly.
I think the perfect operating system in the world would be the cleanliness of NetBSD, the security of OpenBSD, the support of Linux, the extensive functionality of FreeBSD 5 (including its devfs, hot damn), the package management system of Gentoo Portage but with less kitschy colouring, and some really cool name nobody has yet thought of. The shortcomings of any given system are small (FreeBSD lacks portability and, in 5, cleanliness; NetBSD lacks corporate support and a responsive scheduler; Linux lacks cleanliness and security and a good network stack; DragonFly lacks support and portability) and would be easy enough to fix just by convincing enough people it's worth doing. Perfect systems are within our reach, but the universe won't let it happen.
It's pretty heavy given its lack of functionality. For most uses, Fluxbox with a pager and use of ~/.gtkrc[-2.0] is enough, but at less than a tenth the size. A large part of its size is its image-based themes though.
I tried GNOME 2.8 before and was heftily disappointed. It has about a third of the functionality of KDE but with about ~30MiB extra compressed source to download. If it wasn't for its less-evil-than-Qt license it would have no merit at all.
There's a mind set that 'dead' systems, however well working, will be left behind in performance and other improvements - which is true for FreeBSD 4, at least in a couple of scalability points. FreeBSD 5's network stack is a work of art, but some would argue that it doesn't make up for the system's own lack of performance.
I'd probably still be running it if it didn't find some way to make my Realtek 8139 unstable... everything else was 'good enough' to run as a gateway, because FreeBSD has brilliant security and a hardcore network stack.
FreeBSD 4.x is dead. If you read the schedule, it's being handed over to the security officer, meaning it will ONLY get security fixes from now on. That's it. And given the dubious quality of FreeBSD 5 it means there will be a slice of time where FreeBSD servers won't know what to do - stay with the dead but solid system, or move to the living but flaky one?
It's a real shame they decided to use that SMP model for 5.x, else it would be the best x86 OS in the world. It falls short because the locking slows things down and not many drivers are being rewritten yet (but this situation will of course improve), and there are many bugs introduced into existing [especially network] drivers.
I'd still rather run FreeBSD 5 than Linux for a must-have-reliability server, but not for anything that needed performance. Of course I'd rather still run NetBSD 2 on such a server, but that's tangent.
/me waits to be called Troll for mentioning 'dead' in a post
Re:Printed documentation (diff NET/FREE BSD)
on
NetBSD 2.0 Released
·
· Score: 1
I read some Linux wireless info on tldp.org that said wireless devices had to be in line of sight of each other. I'd like to show that guy my wireless network which traverses two solid (albeit plaster) walls.
BSD documentation avoids making that kind of silly 'assumption' in favor of hard technical facts. There are many real-world help guides as well (tuning(7), security(7), etc.) with FreeBSD, haven't found on-disk equivalents for NetBSD.
Damnit, we need to get some corporate support happening for the BSDs, especially the lesser known Net and Open. (DragonFly can piggyback off FreeBSD until things become too different). I'm okay with Linux, but I dislike the unclean designs (especially epoll, holy crap) and would rather see Linux' advantages (which to me are just NVidia drivers and a responsive thread scheduler, okay and Gentoo Portage) be ported to, say, NetBSD. Or a huge cleanup and code audit done of Linux and the usual base system software. Porting kqueue to Linux should be done as soon as possible, it's a few orders of magnitude better designed than epoll.
That's good, could also try httpd flood from Apache, which is more of a server loader attempt than a bandwidth hog... but of course it'd work too. The meta-Slashdot-effect, where everyone on Slashdot simulates an isolated Slashdot effect...
Slashdot Mirror
It's fatally exaggerated. Even without KDE's tools the worst you have to do in a sufficiently convenient distribution (Gentoo, for instance) is copy the fonts to the right directory and 'ttmkfdir', then xset fp rehash or restart the server. If the directory is specified in xorg.conf it's done.
Unified smoothing is another story (but GTK2/Xft just do it for you by default) but not much harder. Still something I never bothered with because us old-fashioned developer types find that extended sessions of smoothed fonts messes with the mind. At the very least, my aMSN, aterm and nedit should never have any smoothing at all. Does KDE's option force all things to smooth or what?
Why GPL fonts? GPL is a very encumbering license. You could stick them just in free domain, or if the author wants to maintain credit, BSD.
:)
Ensuring all derivatives of the fonts and such are also GPL is just really, really silly. In fact talking about them with software licenses is already bad enough.
You're a GPL zealot aren't you?
What's so strange about that? In capitalism you need money to get anything useful done. But open source is an attempt at communist ideals emulated within a capitalist reality. It doesn't work out without money.
Don't complain about open source, go complain about governments making it so hard to MAKE anything for free.
It depends on your definition of 'AI'. If people call the small algorithms defining how some characters should behave in basic games 'AI', this certainly is, even if it doesn't learn on its own.
TAI (think about it) and stop flaming. Thanks.
PS: If you think the syntax of most languages is very similar, you haven't ever once spoken fluent Russian. SystranSoft's translator, for instance, in spite of its occasional success in translating English/French, can't get a single thing right in Russian. It's too flexible and undertermined to easily parse. If you throw in slang it's virtually impossible without knowing the context and culture itself. Watch a movie translated by a certain 'Goblin' and you'll know what I mean. 'breaking sentences down into pieces' my ass.
If the changelog was right, 2.6.9 would have had a lot of "this patch breaks X" and 2.6.10 would have "fixes X again". I know a lot of people having flake-outs with 2.6.9 that are indulging in 2.6.10's very good stability. Realistically Linux 2.6 rarely gets worse from one version to the next, barring some 'oops'es that often come up very quickly so any users can downgrade again without much uptime.
You can easily dual-boot between an old and new kernel and simply fall back on the old one if you have problems with a new one. If you're running even a redundant cluster of servers this should be painless, the only problem occurs if you rely on a single server (in which case you're just asking for these problems).
That's pretty impressive. It takes quite a clever AI to read between lines and connect concepts, but I have to wonder how much of its 'understanding' was hard-coded rather than purely abstract. Would it be trivial to just stick in another language database and have it read translations of the article the same way?
Nevertheless it makes me feel like all the programming and design I've ever done is pathetic and I will never amount to anything. That's how it is in the software industry - always someone out there who makes you look bad.
So what you're saying is, I'm still entirely right because they lack CVS, but they just happen to provide something the desperate can use? Thanks, good to see you agree with me.
/after/ a period of system instability brought on by a new subsystem. It works for them because typically only a few disruptive things happen at a time, and the developers are worryingly skilled. Neverthless these are NOT two branches, these are like point 'releases' in CVS instead of tarballs.
.config, removing the old tree, unpacking/emerging a new one, then copying in the .config, make menuconfig to fill in the blanks, and have to build basically from scratch... you just cvs -zX up -dP from a 'linux' directory that isn't even a symlink, and carry on building. It probably is like this with the BK interface (but then I don't know), but the software/license itself is dubious. Tip: Don't talk to me about patching every time, that involves opening a browser or predicting a URL. If you have to do either of these to keep a base system component up to date, the system is flawed.
A branch cannot be stable and development at once, that's stupid. The closest that comes to this is DragonFly which has a careful engineering cycle which includes a tagging of 'stable' in the tree every time the whole system seems to work fine, usually
Hey, a unified GNU + linux utilities base package, with CVS access and a trimmed glibc (nobody needs 90% of that code), would really get it to a BSD status.
Imagine instead of copying out your
If you couldn't with 2.6.9, 2.6.9 won't be any better... logic, boy, logic.
ACPI should work anywhere that conforms (BIOSes earlier than 2000 usually have problems though), what kind of problems do you have? nForce2 has been supported for almost as long as it's existed. Throttle depends on processor, but I saw an nForce-specific driver there too. Temperature if it's available.
Just try it. It's a good release, rare in 2.6 so far, and should support all you've described... except MAYBE DRI (not just 3D acceleration) for the Radeon. Unless it's backwards compatible with the 9200, which I hear is the latest of the supported-in-tree cards. Google it.
Even that has quite a few changes... but yes, why call it a 'release candidate' if it has no chance of being the release? It's like having presidential candidates just advertise guys who could become the president.
I think Linux should use a CVS system like the BSDs, so you can keep a real-time track of the source tree and do away with the need for point releases every few weeks or so. Notice that the BSDs release a couple of times a year, but with CVS[up] they stay updated. And in the -stable branches they actually [gasp] make sure things work before committing them!
Yeah, why did the post say "minimal changes?"
I find this to be one of the bigger leaps in 2.6, at least in that a new direction is coming out (let's excuse 2.6.6->.8 which had some disruptive/big changes we all know about). They're cleaning out deprecated driver code and making things more abstract, and also finally PCMCIA is split into its relevant sub-drivers (you'll know if you configure it; but note that your old config will NOT include PCMCIA when you just copy it over). I think this is a good step forward.
Another big change is that -march=pentium[234] is no longer used, but -march=i686 with -mtune (however I did NOT see mtune in action while building, so there might be an oops). This is because of gcc's bugs actually, but I like it more this way for other reasons.
I have now taken to building one kernel for two machines as I used to, in my BSD way, so as to save maintainance and re-emering sources all the time. Build once, install everywhere.
This is a good release, I like seeing that Linux 2.6 is finally going somewhere good. Now let's see some attempts at security and supporting all the ports, not just the fun ones.
Okay, I got modded Troll for explaining the release cycle and the current problems in 5.x. You have got to be kidding me. Are the mods here that short-sighted?
Fsck it, SLASHDOT IS DEAD.
http://www.feyrer.de/NetBSD/portability/portabilit y.html
I can't really say much for/against the rest of it, without quoting lots of sources even on Slash itself... poke around.
A clean design doesn't have to lag behind. How long has Linux 2.6 been out? Over a year. They still haven't made respectable progress in bringing these 'lagging ports' up to date, even though the source itself can be worked over in one sitting by someone who knows what to do. Either they don't care or, as I suggested, their hack designs aren't possible any more, and it would require actually thinking about a design before writing it down.
My favorite example of Linux designs sucking is epoll compared to kqueue. I could go on for hours, but just read their manual pages and try to implement a server using both (have it respond to write, read and disconnection events for each client socket). You'll work it out very quickly.
See, that's the kind of thinking that leads to cruft and redundancy. NetBSD is so clean BECAUSE it cares about every port; when you run a new design or algorithm on a machine that takes a few days to start vi, you notice if there's a big real-world performance difference. If there is a bug on a driver that only surfaces when run on a certain architecture or bus, you notice and fix it. Linux has lots of redundant drivers and hacks, its portability is limited to pretending everything is x86. There are too many hacks and exceptions to keep it clean.
In 2.6, there was an effort to clean things up, and this meant the hacks were broken. But they were not replaced with solutions. NetBSD is about solutions. It's portable in the true sense of the word, not just in that it runs on 'relevant' architectures. Porting to ppc64, and so on, would be done quickly if the hardware was available; and rumor has it this will soon be the case. Just watch.
The one thing that worries me about NetBSD is that 3.0 is planned to have Solaris-like SMP, which is what killed FreeBSD 5. Now, NetBSD 2 got Scheduler Activations right where Solaris failed, and it might somehow fluke and get the SMP right too; but in all seriousness an LWKT implementation would be much simpler and, if DFly is any example, much better. All we can do is sit back and watch.
5.3-STABLE [sic] still has the interface death problem, at least it did for me. I would have kept it if not for that, despite the sluggishness it still had the composure and usability of a FreeBSD system. The other BSDs could learn from it, but then it might interfere with their designs of pure simplicity. Probably DragonFly will win there.
BIND and Sendmail definitely, but not CVS, at least not for NetBSD; it's simply the most sensible (and indeed only truly supported) way of fetching the system sources. Its footprint is small enough to make this worth it. Okay, so a binary package would be trivial to fetch, but this is still too much work to be worth it.
.1x as used/useful.
By the same token we could strip anything that less than 50% of the population uses, since the majority benefits. It's not that simple: the minority might just be more important - developers, for instance. The majority might not even notice. How many people cry themselves to sleep every night because gdb is in the base system, but even many DEVELOPERS don't use it? I'd rather take that out than cvs - it's easily 10x larger and
All true, but a showstopper for any sufficiently frequent hardware configuration (in the case of Linux 2.6 on any Indy/Indigo/etc, EVERY instance of a certain machine class) is still a showstopper. Even so, the chances made to 2.6 should NOT have been so hackish as to break existing simple functionality so severely; NetBSD 2 had changes just as large made to its kernel, but runs on all the same machines it did before, in fact more. FreeBSD seems to be breaking its ports if they weren't already broken, so besides x86 it's essentially useless - and its use is mostly on x86 anyway where its NDIS wrapper and nvidia drivers are useful (AFAIK there is no x86_64 nvidia driver for FreeBSD, but I haven't actually looked either). For any other arch, NetBSD and Linux (and often OpenBSD) beat it hands down in every aspect that really matters.
You either need a special license or a legal copy of MSVC++ to use it. In this sense it is even more restrictive than MFC, though admittedly more useful.
GTK is GPL (or LGPL? anyway..) and hence can be used safely for most things, provided you don't use the code itself in a way that would conflict with the GPL. That's okay though.
It is now official. setagllib confirms: You're a tool
One more crippling foot kicked your dumb ass because you never learned to shut up around people stronger than you. Coming on the heels of a recent peer survey which plainly states that you are going blind from beating off to your mother too much, this news serves to reinforce what we've known along.
You don't have to be the Amazing Kreskin to predict your middle mouse button's future. The printoff is on the wall: Your button is worn out from too much damn copying and pasting. As many of us are already aware, you're an assbandit without even as many testicles as required to post with a name or with any original content.
Fact: Slash needs a regexp-based troll filter with automated banning
It just looks like one because it's big, copied-and-pasted, and has some 'buts' in it.
It's mostly true. Some things are a bit pessimal (I personally HAVE booted a non-SMP kernel on a hyperthreading machine) but everything about AMD64, network cards, and dubious quality is true. If FreeBSD 5 manages to clean up and escape from the tangled web of crap it's in, it will be great, but so far 5.3-STABLE hasn't made as much progress as you would expect from the long time it's been out. A similar thing is STILL happening in Linux 2.6 on 'less popular' architectures (SGI MIPS...) where it won't even boot, but this is normal for a system with its ideals - for a BSD it's virtually inexcusable to ship a release with many known showstoppers.
As OpenBSD devs said, sendmail has had a lot more testing and those security holes have been ironed out, so technically it's more 'reliable' than postfix which is much newer. But I agree to just take out MTAs entirely.
File systems, I wouldn't say FFS is so bad. It's very balanced; its performance is good enough in the real world, it takes very little processor and memory overhead (compared to the journalling file systems...), it survives even during sectors being mangled (ReiserFS dies because it has no superblock backups, and some others too). I wouldn't mind seeing a journalling FS in a BSD (well, there's LFS in NetBSD, which is log-structured and hence even more complete journalling), and in fact dillon has laid the foundations for such a system in DragonFly.
I think the perfect operating system in the world would be the cleanliness of NetBSD, the security of OpenBSD, the support of Linux, the extensive functionality of FreeBSD 5 (including its devfs, hot damn), the package management system of Gentoo Portage but with less kitschy colouring, and some really cool name nobody has yet thought of. The shortcomings of any given system are small (FreeBSD lacks portability and, in 5, cleanliness; NetBSD lacks corporate support and a responsive scheduler; Linux lacks cleanliness and security and a good network stack; DragonFly lacks support and portability) and would be easy enough to fix just by convincing enough people it's worth doing. Perfect systems are within our reach, but the universe won't let it happen.
It's pretty heavy given its lack of functionality. For most uses, Fluxbox with a pager and use of ~/.gtkrc[-2.0] is enough, but at less than a tenth the size. A large part of its size is its image-based themes though.
I tried GNOME 2.8 before and was heftily disappointed. It has about a third of the functionality of KDE but with about ~30MiB extra compressed source to download. If it wasn't for its less-evil-than-Qt license it would have no merit at all.
There's a mind set that 'dead' systems, however well working, will be left behind in performance and other improvements - which is true for FreeBSD 4, at least in a couple of scalability points. FreeBSD 5's network stack is a work of art, but some would argue that it doesn't make up for the system's own lack of performance.
I'd probably still be running it if it didn't find some way to make my Realtek 8139 unstable... everything else was 'good enough' to run as a gateway, because FreeBSD has brilliant security and a hardcore network stack.
FreeBSD 4.x is dead. If you read the schedule, it's being handed over to the security officer, meaning it will ONLY get security fixes from now on. That's it. And given the dubious quality of FreeBSD 5 it means there will be a slice of time where FreeBSD servers won't know what to do - stay with the dead but solid system, or move to the living but flaky one?
/me waits to be called Troll for mentioning 'dead' in a post
It's a real shame they decided to use that SMP model for 5.x, else it would be the best x86 OS in the world. It falls short because the locking slows things down and not many drivers are being rewritten yet (but this situation will of course improve), and there are many bugs introduced into existing [especially network] drivers.
I'd still rather run FreeBSD 5 than Linux for a must-have-reliability server, but not for anything that needed performance. Of course I'd rather still run NetBSD 2 on such a server, but that's tangent.
I read some Linux wireless info on tldp.org that said wireless devices had to be in line of sight of each other. I'd like to show that guy my wireless network which traverses two solid (albeit plaster) walls.
BSD documentation avoids making that kind of silly 'assumption' in favor of hard technical facts. There are many real-world help guides as well (tuning(7), security(7), etc.) with FreeBSD, haven't found on-disk equivalents for NetBSD.
Damnit, we need to get some corporate support happening for the BSDs, especially the lesser known Net and Open. (DragonFly can piggyback off FreeBSD until things become too different). I'm okay with Linux, but I dislike the unclean designs (especially epoll, holy crap) and would rather see Linux' advantages (which to me are just NVidia drivers and a responsive thread scheduler, okay and Gentoo Portage) be ported to, say, NetBSD. Or a huge cleanup and code audit done of Linux and the usual base system software. Porting kqueue to Linux should be done as soon as possible, it's a few orders of magnitude better designed than epoll.
That's good, could also try httpd flood from Apache, which is more of a server loader attempt than a bandwidth hog... but of course it'd work too. The meta-Slashdot-effect, where everyone on Slashdot simulates an isolated Slashdot effect...