Desktop is okay. The same software runs (I'm posting from Firefox 1.0 RC1 on a NetBSD 2.0RC4 machine I set up a couple of days ago) and it runs just as well. Responsiveness is very good in all but the highest of high load, in which case your audio might skip for a second or two (but this happens with any OS under enough disk load, and can be prevented by buffering the whole MP3 or whatever into RAM:P).
But as for hardware support, what most consider the defining point of desktop use, it's great. All hardware it does support, it supports basically to full capacity, and the range is good. Right now you'll want standard hardware though, because the NVidia driver is not officially ported (there's an unofficial port I'll have to try) and the xorg one is flaky (but I'm using it now), and there is no NDIS wrapper so standard network cards are your best choice (i.e. nForce networking might not be an option). Fetch a good Realtek and you're set for life. Sound is good, doesn't do software mixing like FreeBSD nor hardware mixing (for most at lesat) like ALSA, but quality is good.
It has good server applications too, not only because it can run on server-centric architectures really well, but more because it is very solid, secure and good at handling load (haven't tried under ultra-high load, but it survived a thrasing from stress(1)). This doesn't affect you since you since you're after desktop, but it's nice to know that it can scale up.
Worth a try, installs quickly, easy to manage and all... not like it'll take a long time or a lot of effort:)
Yeah, pkgsrc is very solid, I haven't had one failed compile yet, where ports would fail 1/5 or so. The few things that weren't in pkgsrc I compiled/installed by hand.
What irks me about pkgsrc is the lack of configurability. In Ports there were values you could set that would often be used to define functionality, like WITH_VORBIS and so on. pkgsrc has these but there are very few of them and they aren't always consistent between packages. Try compiling xmms without esd, for instance... is it possible without mangling everything by hand? (I'm actually asking, because I haven't found a way)
That's exactly right. The BSDs' "release infrequently but release it well" has let them make consistently solid releases which really do well for their introduction into production environments. FreeBSD 5.3 is not such a release, it was rushed through expectation and because they weren't making any real progress on the existing problems. Maybe 5.4 will be better, maybe 6-STABLE will be better, but by that time nobody will care.
Easy there, it might not be that solid. They haven't done much testing outside of x86 and even that is flaky and/or slow for a lot of hardware (including hardware every machine has).
Unless FreeBSD offers something for Alpha that NetBSD and Linux don't and you absolutely must have it, you know where to turn.
'Completely automated' does not include such vital information as your real name (notice how no serious UNIX-like asks for your name? It's a relic from the old single-user Windows), your serial key (about a third of which are real:)), your sperm count, etc.
ACPI has done all that seemingly all year. You must have misread the docs or something. It does in fact have much better and more logical ACPI support than Linux, in that it does every event automatically without needing any user-land daemons or configuration (Linux does, and it's not simple or reliable).
Then again, DragonFly BSD and NetBSD both have ACPI functionality in much the same way, without the instability and performance degradation of FreeBSD 5. Investigate those options instead, you won't regret it.
Well, as far as everyone who knows is concerned, no even hardened Linux has ever competed against any BSD in security. It's just impossible with Linux' development model, and the services in userland (as opposed to the mature services that the BSDs have kept for decades and hardened) are often dirty hacks that haven't had proper auditing, if indeed any.
But if you want security, go OpenBSD, it's the world leader. A close second is NetBSD, which right now is much faster and more stable than FreeBSD 5 (even in many SMP cases, too). FreeBSD is okay for many users but it has slowed down tremendously, lost a lot of cleanliness too. It's a shame to see such a great system degenerate, but it happened.
In my opinion, NetBSD is a good half-way between Linux and OpenBSD. It has a lot of Linux-like performance (sometimes better, sometimes worse) and design, but security isn't far behind OpenBSD in practice. It doesn't have anywhere near as many randomization-of-kernel-data features though, which you might find handy. You can still use cgd for any storage including swap, if you're really paranoid:)
Well, you saw the crap that happened to FreeBSD 5 when they tried to get 'good' SMP support. The SMP is fine-grained for the most part, but it isn't worth it, since the performance on SMP and UP is still (as demonstrated above) miles behind other systems, even Net and OpenBSD which don't claim to have fine-grained or even far matured SMP.
SMP itself is not a killer, but when a design for SMP is overcomplicated, the rest of the system suffers.
I'm not a dev, but I've been scouring the mailing lists to answer my own version of that question, and it seems that there are a couple of outstanding 'misfeatures' that many feel are necessary for release but others think can be slipped in for 3.0 or, if not too disruptive, 2.1.
It's like FreeBSD 5 (but much better, thankfully), where issues crop up even after scheduled release, but they have the dignity to prioritize release quality over expectation. Remember, releasing a few months late may put a couple of (non-dedicated) users off it, but releasing a crap sandwich could put everyone off, even die-hard zealots. I don't want the grace and glory of NetBSD to fall under the same depressing afflictions as FreeBSD 5, especially since now is its introduction into more modern systems. If this means waiting a few months more for a much better release, so be it.
We can all just CVS ourselves a 'close enough to release' tree anyway, and you can install the RCs off floppies just as easily as off CDs (okay, that's assuming you have the tarballs over NFS or FTP somewhere)
Probably should read their interview/notes. They held off SMP support until their primary priorities were met, which in OpenBSD always starts wiht security. Since they could implement (thanks to NetBSD 2) SMP quickly, without vulnerabilities and repercussions, it seemed silly not to do so at that stage.
They even admit that the SMP is 'better than nothing' but is giant-locked (like FBSD 4.x) and generally won't perform that well, but will give that extra CPU something to do.
Remember, OpenBSD is about bleeding edge in security (how many of OBSD's security features does Linux support? close to none, actually), not in performance or hardware support or file systems or whatever else you might find more important. If these things are what you want in a system, you know where to find them.
FreeBSD is a great place to start learning BSDs, since it is by far the simplest and offers the most functionality on x86 machines. The downside is that its future is bleak (lost best devs, politics too messy, CODE too messy... this isn't trolling, hell I love FreeBSD, but judging by 5.x progress it's not going to get any better).
So use FreeBSD as a learning platform then move to the deeper end of Net and/or OpenBSD. When DragonFly has cleaned out more of the 4.x cruft and become production-class stable, that'll be a great thing to investigate too. Net and Open, however, have had so-clean-you-can-eat-off-it code for years now, and the result is a pair of portable (especially NetBSD), secure (especially OpenBSD), high performing (at least, OpenBSD say they've made it so) and generally very good systems. They certainly pose very good alternatives to Linux, and I would much rather run either on a server/gateway machine (iptables is a joke).
I'm assuming you're talking about Alpha Centauri (at least, I haven't played enough Civ3 to know if it has GAs:P), in which case a turn is a year. 20 years of breakthroughs is not so bad. Nothing stopping them from breaking out a new golden age directly after, either.
Not the first - in another thread, a chap was modded troll for what anyone else would clearly find Funny +4 or so. These things happen.
Grandparent (your parent) had misconceptions regarding BSD because he reads too many troll posts, but was surprised to find that they're still pushing the OS [1] industry forward, even with the big companies (the Linux approach has often been to either make the companies your slaves (IBM, SGI, etc) or defeat them outright (Microsoft) - pretty successful strategy I'll admit, but not very good for real-life karma).
[1] Open source, Operating system, whichever you think fits more
Amen. Personally I haven't had that many huge problems, but on some machines (but not others with the same installed packages - yes it's that random) alsa-driver is considered a dependency of alsa-libs, which is not right. Since I am using 2.6 kernels only, and alsa-driver is only really useful for 2.4, I injected the ebuild as if it was done already, then carried on normally.
Almost a month later, a new alsa-driver comes out, and it wants to upgrade. For this, it must also fetch and install kernel sources (boy did this have me stumped - I didn't realise the alsa-driver connection at the time) for 2.4, which isn't useful to me at all. In the end I had to add the packages.provided entry by hand to convince the system alsa-driver was taken care of, but I know things will crop up again
More than half of portage's functionality is to work around its shortcomings. Not to mention the same 'untested' software that is in Portage and breaks instantly but works perfectly in FreeBSD Ports, NetBSD pkgsrc, OpenBSD Ports, etc... and certainly all binary distributions... how do they explain that?
He said it stayed up longer, not faster... this made his post completely irrelevant to the topic (that compiling everything from source yourself is not much faster, if at all, than distros compiling everything from source for you) and is stupid.
Explain to me, please, how a distribution can keep a kernel up longer than another? Same kernel = same uptime. If he mains bits of the userland went 'down', that's another story, also one that is meaningless because distributions don't write their own server/whatever software, at the most they'll patch it with someone's hacks. If he measured different kernels/configs across the distributions and used them to judge the distribution itself, he is a tool and should be fired.
I'd really love to see a real comparison between Debian and Gentoo, fairly. Same kernel, same file system, same daemons running. Yes, Gentoo will come out 1-2% faster, if they got it right - but which will have less problems, which will be brought up faster, and whether or not a casual user sitting in KDE/GNOME/whatever will actually be able to tell which install is which, performance/responsiveness-wise.
You're right, 3.4 has an extra flag (but the bench shows it slowing it down, doesn't it? unless you show a bench where it speeds things up), I was thinking of gcc 3.3 because that's what almost everyone in their right minds would be using for production machines.
It's simple: Women can't dress as penguins, and if they try to, it's really not that hot. BSD has a sufficiently humanoid yet abstract (since horns, fork, etc. can all be relevant without the rest of the daemon) mascot that, besides being cool by appearance alone, is very successful as something for women to wear
/me grins like someone who's never had a girlfriend but just found an awesome stash of porn
Pfft. It's not the same. Linux configs were meant to be simple to parse by software, not by humans. The menuconfig/xconfig/etc hacks were just to make it easier to bridge the gap between human and configuration. If they were consistent in layout, naming and help for the options, it might even be a good idea. But since the BSDs have kernel configs with inline comments and tips, a syntax that makes sense and is perfectly readable, and detailed manpage/Handbook/etc documentation for every option (oppose Linux, which still has 1/5 or so of its options undocumented or close enough, and some rubbish like saying everyone should enable IPSec even though 90% of users won't have any idea what to do with it on their home network), they're clearly in the right here. I never liked menuconfig more than writing and keeping a config for a BSD kernel.
Honestly though, who could like 'CONFIG_8139TOO' more than 'device rtk' (NetBSD) or 'device rl' (FreeBSD)? The devices are at least consistently and shortly named, so you don't have to scavenge through references to know what module to load or option to request. Plus, on systems without a working ncurses or X (I'm sure there are such systems...), menuconfig and x/gconfig are out the door, and you're stuck using the per-question-and-restart-if-you-change-your-mind design of make config.
BSD is about getting it right and making it sensible, even if it means being a year behind in the technology. Linux could learn a lot from this. No wonder NetBSD is breaking internet land speed records in 'betas' while Linux is cropping up with huge bugs in 'releases'.
Hardly. FreeBSD is the only BSD, now, that has stuck to its original logos, at least in content.
"Corporate" was the first word that hit me when I saw the new NetBSD logo, and judging by this thread I'm not the only one that thinks this way. I hated it for the first few minutes (unfamiliarity more than anything - I'd more hate some glossy kitsch like Gentoo's logo, which, to anyone who didn't know Gentoo, could just as well be a breakfast cereal logo) but now I've grown a liking to it. It constitutes my MSN 'display pic' (Microsoft = long names for simple things, just so people don't have to remember new words like 'avatar') and still is getting appreciated.
Simple is good, but I still think they dropped too much of their proud BSD culture when they 'distilled' the original (I say 'they' because it is now 'their' intellectual property, at least in as much as they chose it over other images which were probably better anyway).
I mean, OpenBSD dropped the BSD Daemon in favor of an icon largely relevant to their cause (for those that don't know, blowfish is a symmetric encryption algorithm, a darn good one at that), and that's fair enough - it's flexible and 'fun'. NetBSD's is dry now, completely unlike the dated but awesome old logo, which had relevance to their cause and the old BSD culture. The new one has some very loose relevance, at least if people recognize the flag, but where's the BSD in it? (not counting the NetBSD text)
We'll note that BSD is still generalised on Slashdot with the classic daemon, even though it now only applies to FreeBSD and (if they keep the older icons, at least) NetBSD.
DragonFly has a good icon, IMHO. It is colourful, which reduces its use on monochrome media and all, and I can't for the life of me remember the whole thing all at once - but it is instantly recognizable as 'dragonfly' even if you've never heard of the project, it's simple and professional enough to appeal to business, while still being interesting enough to appeal to geeks. 'Course I don't run DragonFly since it still has too much of FreeBSD's brokeness (remove kbdcontrol and moused necessity, then I'll go back) to be made up for by the amazing technical merit, most of which NetBSD offers anyway without any of the brokeness - plus it runs as well on my x86s as my Indy:)
The article you're naming your post after did not have plural 'details', since it isn't really necessary. 'So much detail' is so close in meaning to 'so many details' to most people that it doesn't seem Right to print an extra letter on every newspaper (and in my case, photocopy for persuasion analysis - damn english).
Simple: It doesn't. You're a user, good. Hell I use Gentoo too. I don't, however, claim that compiling from source makes it magically much faster ("hella faster", as the bright lad above pointed out) - sure, sometimes a bit faster, not enough to brag about though, certainly not enough to see with own eyes.
People seem to think I generalised by seeing all Gentoo users are ricers. This is not true. The grand majority appear to be, though, even many of the highly-respected users on forums, and developers aren't exceptions. These people give detailed tutorials on how to tweak a box without actually improving performance, but wasting a lot of time in the process. That's rice. Since they represent the user group which sets Gentoo apart from other communities, it can be said they are ambassadors for the system. Ergo, they are ricers, and their product is rice. Take it how you will, that's how it appears to be.
And I don't think anybody's arguing Gentoo makes a hardcore desktop. I'm not flaming the system, the users are what piss me off, and they're very vocal.
Yes, read the explanation, 'cycles' as in how many times the function was repeated. Not as in CPU cycles.
And I have tried this on many codes, big and small, real-world and synthetic, mine and popular. I don't know what 'big boost' you're talking about - you realise -O3 only adds two relatively minor flags over -O2, right? Read the manpage, and failing that, the source. I have.
Yeah, I noticed the shit he said ("[only gentoo gives] compiled binaries" = gold) but didn't want to double-post:)
By the way, the gcc used for those tests was 3.4.2, so no, this has not gotten much better through gcc revision. It still doesn't make much difference.
I've gone to great lengths and benchmarks to establish whether or not gcc per-processor optimizations are actually as good as ricers (you) say they are, and concluded that the difference is so small only a select few synthetic benches will really benefit. The biggest and only consistent improvement to performance is use of -O1 instead of -O0. Everything else is such a small difference that it's hardly worth reading the manpage for, let alone typing in every time you set up a box.
Here, example of a code and Makefile I wrote to test gcc's optimization, results:
dave@thor inst $ make
-O: 612 cycles
-O2: 615 cycles
-O3: 609 cycles
-O3 -march=pentium4 -mfpmath=sse -fomit-frame-pointer -ffast-math: 626 cycles
(Cycles is how many times it repeated a certain function in a fine-grained time frame)
There you are. -O3 is slower than -O2, -O2 is only very very slightly faster than -O (and if you re-run, half the time it will be slower), and a "k-l33t cFlaGz omghax" is only a notch faster than those. This is one of the sources I developed which benefits the [b]most[/b] from this tweaking! In a real-world application it makes so little difference it's not worth recompiling anyway. "hella faster" my ass. You're better off overclocking or something.
Gentoo Is Rice. You are a ricer. You got owned by someone who bothers measuring things. HAND.
(Besides, USE is the real advantage of Gentoo, the sooner you take that more seriously the better your life will be)
Re:What an Interview! Wireless firmware storm brew
on
OpenBSD 3.6 Live
·
· Score: 1
Yeah. Unfortunately a lot of vendors are replacing wonderful Prism* chips with Ti chips that are less reliable (two such chips in the house, both flake out once every few hours, if indeed they work at all), almost completely unsupported in nixes, and just generally aren't as cool. Ti should stick to making calculators, or at the very least document the PC hardware they do taint the world with, so we nixers can make use of them.
Slashdot Mirror
Desktop is okay. The same software runs (I'm posting from Firefox 1.0 RC1 on a NetBSD 2.0RC4 machine I set up a couple of days ago) and it runs just as well. Responsiveness is very good in all but the highest of high load, in which case your audio might skip for a second or two (but this happens with any OS under enough disk load, and can be prevented by buffering the whole MP3 or whatever into RAM :P).
:)
But as for hardware support, what most consider the defining point of desktop use, it's great. All hardware it does support, it supports basically to full capacity, and the range is good. Right now you'll want standard hardware though, because the NVidia driver is not officially ported (there's an unofficial port I'll have to try) and the xorg one is flaky (but I'm using it now), and there is no NDIS wrapper so standard network cards are your best choice (i.e. nForce networking might not be an option). Fetch a good Realtek and you're set for life. Sound is good, doesn't do software mixing like FreeBSD nor hardware mixing (for most at lesat) like ALSA, but quality is good.
It has good server applications too, not only because it can run on server-centric architectures really well, but more because it is very solid, secure and good at handling load (haven't tried under ultra-high load, but it survived a thrasing from stress(1)). This doesn't affect you since you since you're after desktop, but it's nice to know that it can scale up.
Worth a try, installs quickly, easy to manage and all... not like it'll take a long time or a lot of effort
Yeah, pkgsrc is very solid, I haven't had one failed compile yet, where ports would fail 1/5 or so. The few things that weren't in pkgsrc I compiled/installed by hand.
What irks me about pkgsrc is the lack of configurability. In Ports there were values you could set that would often be used to define functionality, like WITH_VORBIS and so on. pkgsrc has these but there are very few of them and they aren't always consistent between packages. Try compiling xmms without esd, for instance... is it possible without mangling everything by hand? (I'm actually asking, because I haven't found a way)
That's exactly right. The BSDs' "release infrequently but release it well" has let them make consistently solid releases which really do well for their introduction into production environments. FreeBSD 5.3 is not such a release, it was rushed through expectation and because they weren't making any real progress on the existing problems. Maybe 5.4 will be better, maybe 6-STABLE will be better, but by that time nobody will care.
See sig.
Easy there, it might not be that solid. They haven't done much testing outside of x86 and even that is flaky and/or slow for a lot of hardware (including hardware every machine has).
Unless FreeBSD offers something for Alpha that NetBSD and Linux don't and you absolutely must have it, you know where to turn.
'Completely automated' does not include such vital information as your real name (notice how no serious UNIX-like asks for your name? It's a relic from the old single-user Windows), your serial key (about a third of which are real :)), your sperm count, etc.
ACPI has done all that seemingly all year. You must have misread the docs or something. It does in fact have much better and more logical ACPI support than Linux, in that it does every event automatically without needing any user-land daemons or configuration (Linux does, and it's not simple or reliable).
Then again, DragonFly BSD and NetBSD both have ACPI functionality in much the same way, without the instability and performance degradation of FreeBSD 5. Investigate those options instead, you won't regret it.
Well, as far as everyone who knows is concerned, no even hardened Linux has ever competed against any BSD in security. It's just impossible with Linux' development model, and the services in userland (as opposed to the mature services that the BSDs have kept for decades and hardened) are often dirty hacks that haven't had proper auditing, if indeed any.
:)
But if you want security, go OpenBSD, it's the world leader. A close second is NetBSD, which right now is much faster and more stable than FreeBSD 5 (even in many SMP cases, too). FreeBSD is okay for many users but it has slowed down tremendously, lost a lot of cleanliness too. It's a shame to see such a great system degenerate, but it happened.
In my opinion, NetBSD is a good half-way between Linux and OpenBSD. It has a lot of Linux-like performance (sometimes better, sometimes worse) and design, but security isn't far behind OpenBSD in practice. It doesn't have anywhere near as many randomization-of-kernel-data features though, which you might find handy. You can still use cgd for any storage including swap, if you're really paranoid
Well, you saw the crap that happened to FreeBSD 5 when they tried to get 'good' SMP support. The SMP is fine-grained for the most part, but it isn't worth it, since the performance on SMP and UP is still (as demonstrated above) miles behind other systems, even Net and OpenBSD which don't claim to have fine-grained or even far matured SMP.
SMP itself is not a killer, but when a design for SMP is overcomplicated, the rest of the system suffers.
I'm not a dev, but I've been scouring the mailing lists to answer my own version of that question, and it seems that there are a couple of outstanding 'misfeatures' that many feel are necessary for release but others think can be slipped in for 3.0 or, if not too disruptive, 2.1.
It's like FreeBSD 5 (but much better, thankfully), where issues crop up even after scheduled release, but they have the dignity to prioritize release quality over expectation. Remember, releasing a few months late may put a couple of (non-dedicated) users off it, but releasing a crap sandwich could put everyone off, even die-hard zealots. I don't want the grace and glory of NetBSD to fall under the same depressing afflictions as FreeBSD 5, especially since now is its introduction into more modern systems. If this means waiting a few months more for a much better release, so be it.
We can all just CVS ourselves a 'close enough to release' tree anyway, and you can install the RCs off floppies just as easily as off CDs (okay, that's assuming you have the tarballs over NFS or FTP somewhere)
Probably should read their interview/notes. They held off SMP support until their primary priorities were met, which in OpenBSD always starts wiht security. Since they could implement (thanks to NetBSD 2) SMP quickly, without vulnerabilities and repercussions, it seemed silly not to do so at that stage. They even admit that the SMP is 'better than nothing' but is giant-locked (like FBSD 4.x) and generally won't perform that well, but will give that extra CPU something to do. Remember, OpenBSD is about bleeding edge in security (how many of OBSD's security features does Linux support? close to none, actually), not in performance or hardware support or file systems or whatever else you might find more important. If these things are what you want in a system, you know where to find them.
FreeBSD is a great place to start learning BSDs, since it is by far the simplest and offers the most functionality on x86 machines. The downside is that its future is bleak (lost best devs, politics too messy, CODE too messy... this isn't trolling, hell I love FreeBSD, but judging by 5.x progress it's not going to get any better).
So use FreeBSD as a learning platform then move to the deeper end of Net and/or OpenBSD. When DragonFly has cleaned out more of the 4.x cruft and become production-class stable, that'll be a great thing to investigate too. Net and Open, however, have had so-clean-you-can-eat-off-it code for years now, and the result is a pair of portable (especially NetBSD), secure (especially OpenBSD), high performing (at least, OpenBSD say they've made it so) and generally very good systems. They certainly pose very good alternatives to Linux, and I would much rather run either on a server/gateway machine (iptables is a joke).
I'm assuming you're talking about Alpha Centauri (at least, I haven't played enough Civ3 to know if it has GAs :P), in which case a turn is a year. 20 years of breakthroughs is not so bad. Nothing stopping them from breaking out a new golden age directly after, either.
Not the first - in another thread, a chap was modded troll for what anyone else would clearly find Funny +4 or so. These things happen.
Grandparent (your parent) had misconceptions regarding BSD because he reads too many troll posts, but was surprised to find that they're still pushing the OS [1] industry forward, even with the big companies (the Linux approach has often been to either make the companies your slaves (IBM, SGI, etc) or defeat them outright (Microsoft) - pretty successful strategy I'll admit, but not very good for real-life karma). [1] Open source, Operating system, whichever you think fits more
Amen. Personally I haven't had that many huge problems, but on some machines (but not others with the same installed packages - yes it's that random) alsa-driver is considered a dependency of alsa-libs, which is not right. Since I am using 2.6 kernels only, and alsa-driver is only really useful for 2.4, I injected the ebuild as if it was done already, then carried on normally.
Almost a month later, a new alsa-driver comes out, and it wants to upgrade. For this, it must also fetch and install kernel sources (boy did this have me stumped - I didn't realise the alsa-driver connection at the time) for 2.4, which isn't useful to me at all. In the end I had to add the packages.provided entry by hand to convince the system alsa-driver was taken care of, but I know things will crop up again
More than half of portage's functionality is to work around its shortcomings. Not to mention the same 'untested' software that is in Portage and breaks instantly but works perfectly in FreeBSD Ports, NetBSD pkgsrc, OpenBSD Ports, etc... and certainly all binary distributions... how do they explain that?
He said it stayed up longer, not faster... this made his post completely irrelevant to the topic (that compiling everything from source yourself is not much faster, if at all, than distros compiling everything from source for you) and is stupid.
Explain to me, please, how a distribution can keep a kernel up longer than another? Same kernel = same uptime. If he mains bits of the userland went 'down', that's another story, also one that is meaningless because distributions don't write their own server/whatever software, at the most they'll patch it with someone's hacks. If he measured different kernels/configs across the distributions and used them to judge the distribution itself, he is a tool and should be fired.
I'd really love to see a real comparison between Debian and Gentoo, fairly. Same kernel, same file system, same daemons running. Yes, Gentoo will come out 1-2% faster, if they got it right - but which will have less problems, which will be brought up faster, and whether or not a casual user sitting in KDE/GNOME/whatever will actually be able to tell which install is which, performance/responsiveness-wise.
You're right, 3.4 has an extra flag (but the bench shows it slowing it down, doesn't it? unless you show a bench where it speeds things up), I was thinking of gcc 3.3 because that's what almost everyone in their right minds would be using for production machines.
Yeah... I can see how a fattened and daft-looking penguin is 'cool'. You must have gotten beat up as a kid :)
/ freebsd.jpg
/me grins like someone who's never had a girlfriend but just found an awesome stash of porn
Daemons always own penguins, especially with the daemonettes. They're... really hot.
http://people.freebsd.org/~wpaul/daemonette/
http://www.uberg33k.com/bsdgirl/
http://community.borland.com/article/images/20108
It's simple: Women can't dress as penguins, and if they try to, it's really not that hot. BSD has a sufficiently humanoid yet abstract (since horns, fork, etc. can all be relevant without the rest of the daemon) mascot that, besides being cool by appearance alone, is very successful as something for women to wear
Pfft. It's not the same. Linux configs were meant to be simple to parse by software, not by humans. The menuconfig/xconfig/etc hacks were just to make it easier to bridge the gap between human and configuration. If they were consistent in layout, naming and help for the options, it might even be a good idea. But since the BSDs have kernel configs with inline comments and tips, a syntax that makes sense and is perfectly readable, and detailed manpage/Handbook/etc documentation for every option (oppose Linux, which still has 1/5 or so of its options undocumented or close enough, and some rubbish like saying everyone should enable IPSec even though 90% of users won't have any idea what to do with it on their home network), they're clearly in the right here. I never liked menuconfig more than writing and keeping a config for a BSD kernel.
Honestly though, who could like 'CONFIG_8139TOO' more than 'device rtk' (NetBSD) or 'device rl' (FreeBSD)? The devices are at least consistently and shortly named, so you don't have to scavenge through references to know what module to load or option to request. Plus, on systems without a working ncurses or X (I'm sure there are such systems...), menuconfig and x/gconfig are out the door, and you're stuck using the per-question-and-restart-if-you-change-your-mind design of make config.
BSD is about getting it right and making it sensible, even if it means being a year behind in the technology. Linux could learn a lot from this. No wonder NetBSD is breaking internet land speed records in 'betas' while Linux is cropping up with huge bugs in 'releases'.
Hardly. FreeBSD is the only BSD, now, that has stuck to its original logos, at least in content.
:)
"Corporate" was the first word that hit me when I saw the new NetBSD logo, and judging by this thread I'm not the only one that thinks this way. I hated it for the first few minutes (unfamiliarity more than anything - I'd more hate some glossy kitsch like Gentoo's logo, which, to anyone who didn't know Gentoo, could just as well be a breakfast cereal logo) but now I've grown a liking to it. It constitutes my MSN 'display pic' (Microsoft = long names for simple things, just so people don't have to remember new words like 'avatar') and still is getting appreciated.
Simple is good, but I still think they dropped too much of their proud BSD culture when they 'distilled' the original (I say 'they' because it is now 'their' intellectual property, at least in as much as they chose it over other images which were probably better anyway).
I mean, OpenBSD dropped the BSD Daemon in favor of an icon largely relevant to their cause (for those that don't know, blowfish is a symmetric encryption algorithm, a darn good one at that), and that's fair enough - it's flexible and 'fun'. NetBSD's is dry now, completely unlike the dated but awesome old logo, which had relevance to their cause and the old BSD culture. The new one has some very loose relevance, at least if people recognize the flag, but where's the BSD in it? (not counting the NetBSD text)
We'll note that BSD is still generalised on Slashdot with the classic daemon, even though it now only applies to FreeBSD and (if they keep the older icons, at least) NetBSD.
DragonFly has a good icon, IMHO. It is colourful, which reduces its use on monochrome media and all, and I can't for the life of me remember the whole thing all at once - but it is instantly recognizable as 'dragonfly' even if you've never heard of the project, it's simple and professional enough to appeal to business, while still being interesting enough to appeal to geeks. 'Course I don't run DragonFly since it still has too much of FreeBSD's brokeness (remove kbdcontrol and moused necessity, then I'll go back) to be made up for by the amazing technical merit, most of which NetBSD offers anyway without any of the brokeness - plus it runs as well on my x86s as my Indy
The article you're naming your post after did not have plural 'details', since it isn't really necessary. 'So much detail' is so close in meaning to 'so many details' to most people that it doesn't seem Right to print an extra letter on every newspaper (and in my case, photocopy for persuasion analysis - damn english).
Simple: It doesn't. You're a user, good. Hell I use Gentoo too. I don't, however, claim that compiling from source makes it magically much faster ("hella faster", as the bright lad above pointed out) - sure, sometimes a bit faster, not enough to brag about though, certainly not enough to see with own eyes.
People seem to think I generalised by seeing all Gentoo users are ricers. This is not true. The grand majority appear to be, though, even many of the highly-respected users on forums, and developers aren't exceptions. These people give detailed tutorials on how to tweak a box without actually improving performance, but wasting a lot of time in the process. That's rice. Since they represent the user group which sets Gentoo apart from other communities, it can be said they are ambassadors for the system. Ergo, they are ricers, and their product is rice. Take it how you will, that's how it appears to be.
And I don't think anybody's arguing Gentoo makes a hardcore desktop. I'm not flaming the system, the users are what piss me off, and they're very vocal.
Yes, read the explanation, 'cycles' as in how many times the function was repeated. Not as in CPU cycles.
And I have tried this on many codes, big and small, real-world and synthetic, mine and popular. I don't know what 'big boost' you're talking about - you realise -O3 only adds two relatively minor flags over -O2, right? Read the manpage, and failing that, the source. I have.
And where are your figures?
Yeah, I noticed the shit he said ("[only gentoo gives] compiled binaries" = gold) but didn't want to double-post :)
By the way, the gcc used for those tests was 3.4.2, so no, this has not gotten much better through gcc revision. It still doesn't make much difference.
If so... time it.
I've gone to great lengths and benchmarks to establish whether or not gcc per-processor optimizations are actually as good as ricers (you) say they are, and concluded that the difference is so small only a select few synthetic benches will really benefit. The biggest and only consistent improvement to performance is use of -O1 instead of -O0. Everything else is such a small difference that it's hardly worth reading the manpage for, let alone typing in every time you set up a box.
Here, example of a code and Makefile I wrote to test gcc's optimization, results:
dave@thor inst $ make
-O: 612 cycles
-O2: 615 cycles
-O3: 609 cycles
-O3 -march=pentium4 -mfpmath=sse -fomit-frame-pointer -ffast-math: 626 cycles
(Cycles is how many times it repeated a certain function in a fine-grained time frame) There you are. -O3 is slower than -O2, -O2 is only very very slightly faster than -O (and if you re-run, half the time it will be slower), and a "k-l33t cFlaGz omghax" is only a notch faster than those. This is one of the sources I developed which benefits the [b]most[/b] from this tweaking! In a real-world application it makes so little difference it's not worth recompiling anyway. "hella faster" my ass. You're better off overclocking or something.
Gentoo Is Rice. You are a ricer. You got owned by someone who bothers measuring things. HAND.
(Besides, USE is the real advantage of Gentoo, the sooner you take that more seriously the better your life will be)
Yeah. Unfortunately a lot of vendors are replacing wonderful Prism* chips with Ti chips that are less reliable (two such chips in the house, both flake out once every few hours, if indeed they work at all), almost completely unsupported in nixes, and just generally aren't as cool. Ti should stick to making calculators, or at the very least document the PC hardware they do taint the world with, so we nixers can make use of them.