Slashdot Mirror

DragonFly BSD has operation-level journaling already implemented at the VFS layer.

I've already read Wayner, but stop and think what you've just said here. That's the ONLY reason that OpenBSD exists? You mean OpenBSD and OpenSSH (which are both part of the same project) exist for no other reason? Concern for security, "true hacker" coding skillz, ability to coordinate and organize the efforts of many people... these count for nothing? I will remind you that there have been other people who disagreed with *BSD project members and other forks as well. You are failing to give Theo and his crew the credit they deserve. OpenBSD is much more than the offspring of a temper tantrum.

We could add a comment here about how we simultaneously need and despise the noisy idealists and visionaries in our midst, throw in some stuff about RMS, MLK, John Lennon, drink vodka toasts to Victor Tsoi and then lie in a besotted, weeping clump on the floor.

Check out Dragonfly If you want to see where all the BSD noteworthy BSD innovation has gone.

I think DragonFly BSD developers would agree with you.

DF is not meant to be a pure microkernel (its aim is to get the best of both worlds, a la Amiga) and instaead of writing it from scratch (working on an unusable product for years) they started modifying the FreeBSD 4.0 kernel towards a modular architecture, but every release is stable enough to be used in a lot of pratical cases (if not as stable as a tipical BSD release).

It's note really ready but you can take a look at it.

I think DragonFly BSD developers would agree with you.

DF is not meant to be a pure microkernel (its aim is to get the best of both worlds, a la Amiga) and instaead of writing it from scratch (working on an unusable product for years) they started modifying the FreeBSD 4.0 kernel towards a modular architecture, but every release is stable enough to be used in a lot of pratical cases (if not as stable as a tipical BSD release).

It's note really ready but you can take a look at it.

While DragonFly is not meant to be a pure microkernel (its aim is to get the best of both worlds, a la Amiga) I think it deserves a mention too.

DF has a different approach on _developing_ a microkernel. Instaead of writing it from scratch (working on an unusable product for years) they started modifying the FreeBSD 4.0 kernel towards a modular architecture, but every release is stable enough to be used in a lot of pratical cases (if not as stable as a tipical BSD release).

I am not a developer and I do not use DF a lot, but I think it will pay to keep an eye on them, they have the potential to take a many of the concepts behind the microkernel design and itroduce them to a lager audience.

While DragonFly is not meant to be a pure microkernel (its aim is to get the best of both worlds, a la Amiga) I think it deserves a mention too.

DF has a different approach on _developing_ a microkernel. Instaead of writing it from scratch (working on an unusable product for years) they started modifying the FreeBSD 4.0 kernel towards a modular architecture, but every release is stable enough to be used in a lot of pratical cases (if not as stable as a tipical BSD release).

I am not a developer and I do not use DF a lot, but I think it will pay to keep an eye on them, they have the potential to take a many of the concepts behind the microkernel design and itroduce them to a lager audience.

You obviously don't understand the BSD world. The BSD projects aren't different because they are better at different things; they're different (and better at different things) because they have different priorities and goals that are largely incompatible. FreeBSD targets high-stress server environments where performance and reliability are paramount, so FreeBSD can do some bizarre stuff to improve performance--a while back someone did a benchmark between Linux and the three main BSDs, and the socket() graph shows you the kind of hacks FreeBSD does to improve performance.

NetBSD makes a clean, clear codebase a top priority, and its portability is kind of a feedback loop that both results from that decision and motivates it. NetBSD also tries to be very research friendly, and its high-performance networking stack is frequently used to set Internet2 records. They are also the least vociferous about software Freedom, as they were the last of the major BSDs to adopt X.org, and the only one to still use the "four-clause" version of the CSRG license.

OpenBSD also strives for clear code, but places much greater emphasis than the others on security and strong cryptography. OpenBSD periodically audits code, checks for bugs proactively, and the same kinds of bizarre hacks FreeBSD uses to improve performance are used in OpenBSD to improve security (such as making structuring vm pages out of order to prevent malicious buffer overflows. OpenBSD is also the most strongly advocating Free Software, as they spearheaded (along with Debian) the campaign to dump Xfree86, maintain a version of Apache 1.3 because the 2.x license was less free, and include no binary drivers or otherwise unfree in the base distribution. They're kind of like a BSD version of the FSF.

DragonFly[BSD] is the newcomer of the bunch, a fork of FreeBSD. So far the over-arching goals are to improve modularity and to replace bulky structures and processes with lighter, quicker versions. The plan to replace the usual syscall table with a messaging api (apparently like a lightweight Mach-type thing, but evidently not microkernel design) make it very different from its cousins.

It's important to note that these are not just the result of a few random patches to the system approved by a czar, as in Linux, but explicit decisions by the core developers to follow a particular blueprint, to make a particular improvement, or to support (or not) an obsolete API/ABI. If you want to submit a patch out of the blue, you certainly can, and if it's competently coded it will probably be accepted, but the overwhelming majority of code contributions come from the core developers following architectural guidelines. If you tried to combine all 3-4 codebases, the incompatibility of several design decisions would end up combining a stable OS, a lightweight OS, a portable OS, and a secure OS into something that managed to preserve none of these features.

That said, however, because of the similar licensing requirements, the BSD projects all share code extensively, and are frequently source (if not binary) compatible with each other. So it's not like Linux, where packaging systems are completely different but the OS features are all the same (because they use the exact same codebase). In an odd way, the members of BSD family are both more closely related and more different from one another than the various Linux distros are.

So what you have is not only a real-time backup, but also the ability to unwind any possibly damage after a break-in or other event. If your backup server is only running a journalling client, it can be made extremely secure, and also provide an excellent auditing tool.

It would also be possible to delay the streams and have arbitrarily old filesystems available. Or to use a local journal as a buffer to smooth out the IO load as it is piped off site. It could also be used to augment a non-journalling filesystem, for crash recovery purposes, assuming your filesystem provides at least some consistency guarantees. In fact Netapp does something similar by logging FS operations to NVRAM, while the filesystem only writes consistentcy points periodically.

Although I haven't read about the NetBSD work, I am sceptical that they could get the error handling to work correctly at that level. With the DragonFly journalling, there is support for transactional consistency, as well as recovering from interrupted network connections. While it is not complete, much of it is in place and functional.

See the mountctl manual page for attaching a journal to a mount, and the jscan manual page for processing the journal.

So what you have is not only a real-time backup, but also the ability to unwind any possibly damage after a break-in or other event. If your backup server is only running a journalling client, it can be made extremely secure, and also provide an excellent auditing tool.

It would also be possible to delay the streams and have arbitrarily old filesystems available. Or to use a local journal as a buffer to smooth out the IO load as it is piped off site. It could also be used to augment a non-journalling filesystem, for crash recovery purposes, assuming your filesystem provides at least some consistency guarantees. In fact Netapp does something similar by logging FS operations to NVRAM, while the filesystem only writes consistentcy points periodically.

Although I haven't read about the NetBSD work, I am sceptical that they could get the error handling to work correctly at that level. With the DragonFly journalling, there is support for transactional consistency, as well as recovering from interrupted network connections. While it is not complete, much of it is in place and functional.

See the mountctl manual page for attaching a journal to a mount, and the jscan manual page for processing the journal.

Why do embedded developers continue to imprison themselves in the GPL trap by using Linux, when there are better available alternatives that provide more freedom for developers?

Unfortunately, we probably won't see a new release of DragonFly BSD until after the new year.

http://leaf.dragonflybsd.org/mailarchive/kernel/20 05-10/msg00030.html

For those who are unaware, DragonFly BSD is a heavily modified continuation of FreeBSD 4.x. It is done by Matt Dillon and many others who are/were prime FreeBSD developers in the past, but disagreed with the current FreeBSD development path.

I find a hard time keeping track of all the *BSDs.

There are THREE (not counting DragonFly BSD)

  OpenBSD = Secure
  FreeBSD = Feature-Rich
  NetBSD = Portable (54 Architectures?!)

Contrast that to the seventeen-jillion Linux distros out there; I hardly think folks can complain about being confused by the overwhelming multitude (NOT!) of BSD derivatives.

Seriously, though. I like to tell people BSD stands for "Better Stripped Down" 'cuz if you need a small server, running on commodity (read: "used") hardware, BSD will serve you very well.

You don't want your firewall running OOo, or come standard with seven different mail readers. Lean and mean, that's BSD's selling point.

as it happens, pkgsrc integration is planned for the next december release.

The BSDs don't have the fragmentation that Linux has.

I say simply "FreeBSD"

By that I qualify my package management, my system boot scripts, where my conf files are, how the system works

"Linux", on the other hand, can mean a bunch of things:

Do the same applications run on each of the *BSDs without recompliation? I tend to doubt it, but I haven't tried it ...

Apache is Apache no matter in which Linux distro you run it

okay, Stallman, GNU/Linux, as you wish

Back on topic, that Linux machine must have had some hardware flaw. Bad memory comes to mind...

In any event, certain hardware devices have buggy drivers, even in the latest versions of whatever Linux kernels and distributions you prefer. The vendors generally make Windows drivers, where the Linux drivers are often reverse engineered, and it often shows in the quality.

For the *BSDs, the drivers you get are generally more reliable than those in Linux, but if you've got some new device, where Linux would support it (and the driver might have some issues), *BSD is likely to not support it at all.

But I do agree with you too -- FreeBSD does make a better server than any of the Linux distributions. However, the commercial application support is very spotty. However, I've heard that the Linux emulation is quite good, and it can run most Linux applications with little trouble. Though that just sounds so ... wrong ... to use it for a production server. But if it works ...

I'm a *BIG* huge fan of DragonFly BSD and from everything I've seen and read, Matt Dillon and co. are fantastic coders. However, the reason why 5.x has for a long time sucked has far more to do with the fact that the FreeBSD Project bit off more than it could chew; they were adding far too many features all at one time for them to be able to do it all in a managable, and timely fashion, and not due to the loss of Matt Dillon.

SMPng (fine grained kernel locking), KSE (multi-threading the kernel, and providing both M:N and 1:1 threading for userland programs), TrustedBSD MAC Framework and POSIX ACLs, Itanium, AMD64, PowerPC and UltraSparc processor ports, GEOM and GBDE, full kernel preemption, new drivers (including a mass migration to NetBSD's BUSDMA APIs), inclusion of OpenBSD cryptographic code, a new SMP aware process scheduler (Shed_ULE), devfs, a few thousand new ports/packages and a ton of other things that I can't even remember right now were all begun around the same time, all requiring the others to be aware of the various changes that were being made all over the kernel and userland. Matt Dillon was around for at least half of that work, and even then, it was far too big a project for the FreeBSD developers to have undertaken all at one time.

Quite frankly, it was madness. Let's not forget that they also had to support the 4.x branch because it would have required one to be absolutely insane to employ 5.x in *any* mission critical tasks during most of it's lifetime. (OT: I remember when 5.0-RELEASE came out, I attempted to switch to another virtual terminal, only to be greeted with what I called the "Lava Lamp of Death," because that's what I saw on screen, and I was unable to get out of it without rebooting.)

I hold Matt Dillon in high regard, but his departure from the project was not the reason for it's woes over the last few years. Poor planning and a monsterous set of goals were the biggest reasons why it's taken so long for FreeBSD 5.x to get to where it is today.

DragonFly is not currently without it's problems either. The serializing token code will probably have to be completely replaced at least one more time (making it Matt's third attempt IIRC) because although he believes the current API to be both nice and correct, the implementation is bug-prone, having caused a number of issues that seriously impacted the stability of DragonFly in multiprocessor systems:

http://leaf.dragonflybsd.org/mailarchive/bugs/2005 -09/msg00018.html

DragonFly also suffers from the lack of a proper package management system. FreeBSD 4.x ports with the dfports overrides is neither up to date, nor especially fun to make work when something breaks, and although pkgsrc is an option, not all of the most important ports (like X.org) currently build on DragonFly without a number of patches from Jörg Sonnenberger (which sadly have not yet been integrated into pkgsrc itself by the NetBSD folks), and even then (at least for me) it seems to be hit or miss.

I am not the most knowledgable person in regards to these issues; I'm not a programmer, but I read alot of documentation as well as the mailing lists for both projects, and I have used both systems over the past three years (and FreeBSD since 4.5), and I can safely say that it was not Matt Dillon's loss that was the cause of the nightmare that was 5.x until the most recent releases, but was rather due to people trying to do more in one go than was probably a good idea to have tried.

All that said, I am looking forward to both DragonFly 1.4 (which I hope will become my primary platform as overall it's bugged me far less than any other OS I've used), and FreeBSD 6.0 (despite the fact that it no longer feels "right" to me for day to day stuff anymore).

--Jeremy Almey

You should only use free software and avoid unfree software.

You know what's strange about this, just about a year ago there was an article on Slashdot titled, "What's New in the FreeBSD Network Stack". Now, the same guy who made that presentation is asking for money to overhaul it. I don't get it. What's more, didn't it turn out that quite a bit of the performance boost they achieved was due to code that Jeffrey Hsu had written for DragonFly BSD. Maybe DragonFly has the best network stack. They're definitely doing a lot of cool stuff.

I'd like to see FreeBSD clear up their problems with 6.x, but I'm not overly hopeful. I find it very telling that one of the early architects of the 5.x series, Matt Dillon, decided to scrap it, and start his own project, scrapping all the 5.x code, and reverting to 4.8 as a starting point. What he's doing is very intriguing, honestly, but I don't think it's ready for everyday use yet.

FreeBSD 4.x is here, and will be for a little while. The machines running it that I have will stay with it until it's time to upgrade them (due to hardware needs, application needs, or whenever security updates go away).

For new things, I'm using both Debian and NetBSD. I'm very happy with the latter, actually. It appears that the NetBSD team are doing things that are both technically-sound, and just make sense from a natural progression standpoint.

It's kind of sad that so much computing history has been obliterated by the PeeCee. Still, european amiga users mostly jumped ship to Linux.

I remember the [Euro]Demo scene of the early 90s. Good Lord Lir, there were some amazing women into coding on the Amiga. You'd head off to some scandinavian computer camp for the weekend, and be surrounded by 5'10" brunettes who could make an Amiga raytrace in 64K - and they mostly weren't men in drag! (boy, I checked!).

Good times.

Linux could stand to learn a lot from AmigaOS - handling of removeable media being #1.

If you're looking for modern-day "Amiga successors" there are a few choices - Linux+KDE (== NewIcons+ClassAct) or Linux+GNOME (==MagicWB+MUI), obviously, but also:

AROS: http://www.aros.org/ - AmigaOS, but on x86/x64. All the coolness and failings of AmigaOS (i.e. no true memprotect. preemptive-multitasking:co-op-multitasking::full-m emprotect:amiga-memprotect)

DragonFly BSD http://www.dragonflybsd.org/ - Matt Dillon, author of THE Amiga compiler, DICE C, turns his hand to OS design. Like Amiga, only without historical resource-constrained decisions. Message-passing everywhere.

AMIGA ROCKS ON!

There's a real fine line between doing something that no one else is doing versus doing something because you don't like the way other people did it. I'd be open to switching my OS if a new OS did everything that my existing OS did *and* added a bunch of new stuff that made the effort worthwhile. My (admittedly limited) experience with alternative OS projects is that they're trying to solve problems that others have already solved. A new OS probably won't make that much of a difference to me.


This is usually the case, but some forks of existing code bases (consider dragonfly bsd) are very talented developers who have ideas that can't possibly be worked into larger problems because of the disruption they would cause. DFBSD should be incorporating some "new" concepts that (as far as I can tell) aren't in ANY other OS. The other factors that came into play when the OS was started (much like the other BSD forks, the founder/leader was removed from an existing BSD project) seem to be mostly secondary to the technical goals.

Anyone know if the DragonFlyBSD people are considering going anywhere with this? It seems right up their alley.

You can already download FreeBSD 7 Here.

When if you actually read the DragonflyBSD mailing lists for the current status of O/S most of the components are *STILL* under giant
( http://leaf.dragonflybsd.org/mailarchive/users/200 5-06/msg00112.html )

including the network stack, don't hold your breath.

Yes, mistakes were made and things have gone less than well. But have no fear! Ex-FreeBSD developer Matt Dillon to the rescue! For a fellow like yourself can use DragonflyBSD instead of FreeBSD 5.0. It offers the SMP capabilities you crave and need, without the Giant Lock syndrome of FreeBSD 5.0.

Fred, http://www.dragonflybsd.org/main/mascot.cgi

to quote, "the go-lucky demon and the fat penguin are TOAST!"

Just that want to make me want to join that project.

Documentation is very easy to find and readily available for the BSDs:

NetBSD packages
OpenBSD packages
FreeBSD packages

DragonFly uses FreeBSDs ports at this time as per the FAQ

Also see FreshPorts

...and isn't this the challenge being addressed by DragonFly BSD?

Software people use threads already, as long as the VM and OS are up to the task. I don't see why it should matter if some of the threads are implemented in hardware.

FreeBSD 5 is disappointing. It's a stack of hacks over hacks over old unmaintainable code.

I have way more hope in the DragonFlyBSD project. Old code is being rewritten the right way.

If you like FreeBSD 4.x, there's a better upgrade path: DragonFlyBSD. You will probably get better performance out of it and as long as you stick with the RELEASE or PREVIEW tags, DragonFlyBSD is extremely stable.

Don't forget OpenBSD, NetBSD, or DragonFly BSD.

you should check out DragonFlyBSD

It is explicitly not a microkernel and they don't plan to make it one, but it has some microkernel-like properties. For example, programs do not invoke system calls directly, they pass though a translation layer in userspace. This allows a bunch of very cool things that I will not enumerate here because they're on the website.

It's not done yet but they have a working release.

"So AMP must be possible. Right?"

DragonFlyBSD pretty much does that. They claim that it will improve performance, but they're still behind where FreeBSD 4.x was when they forked. They wanted to get it working before they optimized, so it's unclear what they'll be able to do when they get around to it.

The hardware won't change though. It has to support all the other OSes.

I think Dragonfly BSD attempts to address this. I hope they do well.

IMPORTANT UPDATE: Please show your support for Ceren in this poll of Geek Babes!

Is it any wonder people think Linux users are a bunch of flaming homosexuals when its fronted by obviously gay losers like these?! BSD has a mascot who leaves us in no doubt that this is the OS for real men! If Linux had more hot chicks and gorgeous babes then maybe it would be able to compete with BSD! Hell this girl should be a model!

Linux is a joke as long as it continues to lack sexy girls like her! I mean just look at this girl! Doesn't she excite you? I know this little hottie puts me in need of a cold shower! This guy looks like he is about to cream his pants standing next to such a fox. As you can see, no man can resist this sexy little minx. Don't you wish the guy in this pic was you? Are you telling me you wouldn't like to get your hands on this ass?! Wouldn't this just make your Christmas?! Yes doctor, this uber babe definitely gets my pulse racing! Oh how I envy the lucky girl in this shot! Linux has nothing that can possibly compete. Come on, you must admit she is better than an overweight penguin or a gay looking goat! Wouldn't this be more liklely to influence your choice of OS?

With sexy chicks like the lovely Ceren you could have people queuing up to buy open source products. Could you really refuse to buy a copy of BSD if she told you to? Personally I know I would give my right arm to get this close to such a divine beauty!

Don't be a fag! Join the campaign for more cute open source babes today!

$Id: ceren.html,v 9.0 2004/08/01 16:01:34 ceren_rocks Exp $

This is why the DragonFlyBSD project does exist.

But which one is the dead one? DragonFly?

IMPORTANT UPDATE: Please show your support for Ceren in this poll of Geek Babes!

Is it any wonder people think Linux users are a bunch of flaming homosexuals when its fronted by obviously gay losers like these?! BSD has a mascot who leaves us in no doubt that this is the OS for real men! If Linux had more hot chicks and gorgeous babes then maybe it would be able to compete with BSD! Hell this girl should be a model!

Linux is a joke as long as it continues to lack sexy girls like her! I mean just look at this girl! Doesn't she excite you? I know this little hottie puts me in need of a cold shower! This guy looks like he is about to cream his pants standing next to such a fox. As you can see, no man can resist this sexy little minx. Don't you wish the guy in this pic was you? Are you telling me you wouldn't like to get your hands on this ass?! Wouldn't this just make your Christmas?! Yes doctor, this uber babe definitely gets my pulse racing! Oh how I envy the lucky girl in this shot! Linux has nothing that can possibly compete. Come on, you must admit she is better than an overweight penguin or a gay looking goat! Wouldn't this be more liklely to influence your choice of OS?

With sexy chicks like the lovely Ceren you could have people queuing up to buy open source products. Could you really refuse to buy a copy of BSD if she told you to? Personally I know I would give my right arm to get this close to such a divine beauty!

Don't be a fag! Join the campaign for more cute open source babes today!

$Id: ceren.html,v 9.0 2004/08/01 16:01:34 ceren_rocks Exp $

IMPORTANT UPDATE: Please show your support for Ceren in this poll of Geek Babes!

Is it any wonder people think Linux users are a bunch of flaming homosexuals when its fronted by obviously gay losers like these?! BSD has a mascot who leaves us in no doubt that this is the OS for real men! If Linux had more hot chicks and gorgeous babes then maybe it would be able to compete with BSD! Hell this girl should be a model!

Linux is a joke as long as it continues to lack sexy girls like her! I mean just look at this girl! Doesn't she excite you? I know this little hottie puts me in need of a cold shower! This guy looks like he is about to cream his pants standing next to such a fox. As you can see, no man can resist this sexy little minx. Don't you wish the guy in this pic was you? Are you telling me you wouldn't like to get your hands on this ass?! Wouldn't this just make your Christmas?! Yes doctor, this uber babe definitely gets my pulse racing! Oh how I envy the lucky girl in this shot! Linux has nothing that can possibly compete. Come on, you must admit she is better than an overweight penguin or a gay looking goat! Wouldn't this be more liklely to influence your choice of OS?

With sexy chicks like the lovely Ceren you could have people queuing up to buy open source products. Could you really refuse to buy a copy of BSD if she told you to? Personally I know I would give my right arm to get this close to such a divine beauty!

Don't be a fag! Join the campaign for more cute open source babes today!

$Id: ceren.html,v 9.0 2004/08/01 16:01:34 ceren_rocks Exp $

I like BSD systems and I am specially interested in DragonFly, but I use OpenBSD/NetBSD/FreeBSD too. I administer Windows XP (Microsoft), Windows 2003 (Microsoft), Solaris and sometimes Linux, I am concidering to get a mini-Mac (Apple) to get some MacOSx knowledge.

The case made by Matt was that the FreeBSD architecture had been hacked with undocumented junk sprinkled throughout the source tree. A change in one area ripples through the whole tree. Matt rightly said that only one or two people really understand the internals of FreeBSD anymore. Jordan Hubbard and Mike Smith both pointed this out earlier. The FreeBSD source tree is becoming more and more unmaintainable. PHK is perhaps the only person left who fully understands FreeBSD internals. Unfortunately he is considered part of the problem by many.

And the problem started when FreeBSD started chasing feature checklists trying to match Linux. This is probably the root of all the ugly hacks. In practical terms, it was Linux which was driving FreeBSD development, rather than some rational architectural plan. FreeBSD got sucked into a resource expensive "arms race" which drained the "treasury" so to speak. NetBSD stayed out of the fray, choosing instead to follow its own vision. And it has payed off nicely for NetBSD.

In any case, if there is to be a FreeBSD 6.0 someday, it will probably look like Dragonfly. I would say that future is now. Dragonfly 1.0 == FreeBSD 6.0.

The case made by Matt was that the FreeBSD architecture had been hacked with undocumented junk sprinkled throughout the source tree. A change in one area ripples through the whole tree. Matt rightly said that only one or two people really understand the internals of FreeBSD anymore. Jordan Hubbard and Mike Smith both pointed this out earlier. The FreeBSD source tree is becoming more and more unmaintainable. PHK is perhaps the only person left who fully understands FreeBSD internals. Unfortunately he is considered part of the problem by many.

And the problem started when FreeBSD started chasing feature checklists trying to match Linux. This is probably the root of all the ugly hacks. In practical terms, it was Linux which was driving FreeBSD development, rather than some rational architectural plan. FreeBSD got sucked into a resource expensive "arms race" which drained the "treasury" so to speak. NetBSD stayed out of the fray, choosing instead to follow its own vision. And it has payed off nicely for NetBSD.

In any case, if there is to be a FreeBSD 6.0 someday, it will probably look like Dragonfly. I would say that future is now. Dragonfly 1.0 == FreeBSD 6.0.

And if you follow the development you'll note

FreeBSD's advantages are thinning out fast

IMPORTANT UPDATE: Please show your support for Ceren in this poll of Geek Babes!

Is it any wonder people think Linux users are a bunch of flaming homosexuals when its fronted by obviously gay losers like these?! BSD has a mascot who leaves us in no doubt that this is the OS for real men! If Linux had more hot chicks and gorgeous babes then maybe it would be able to compete with BSD! Hell this girl should be a model!

Linux is a joke as long as it continues to lack sexy girls like her! I mean just look at this girl! Doesn't she excite you? I know this little hottie puts me in need of a cold shower! This guy looks like he is about to cream his pants standing next to such a fox. As you can see, no man can resist this sexy little minx. Don't you wish the guy in this pic was you? Are you telling me you wouldn't like to get your hands on this ass?! Wouldn't this just make your Christmas?! Yes doctor, this uber babe definitely gets my pulse racing! Oh how I envy the lucky girl in this shot! Linux has nothing that can possibly compete. Come on, you must admit she is better than an overweight penguin or a gay looking goat! Wouldn't this be more liklely to influence your choice of OS?

With sexy chicks like the lovely Ceren you could have people queuing up to buy open source products. Could you really refuse to buy a copy of BSD if she told you to? Personally I know I would give my right arm to get this close to such a divine beauty!

Don't be a fag! Join the campaign for more cute open source babes today!

$Id: ceren.html,v 9.0 2004/08/01 16:01:34 ceren_rocks Exp $

IMPORTANT UPDATE: Please show your support for Ceren in this poll of Geek Babes!

Is it any wonder people think Linux users are a bunch of flaming homosexuals when its fronted by obviously gay losers like these?! BSD has a mascot who leaves us in no doubt that this is the OS for real men! If Linux had more hot chicks and gorgeous babes then maybe it would be able to compete with BSD! Hell this girl should be a model!

Linux is a joke as long as it continues to lack sexy girls like her! I mean just look at this girl! Doesn't she excite you? I know this little hottie puts me in need of a cold shower! This guy looks like he is about to cream his pants standing next to such a fox. As you can see, no man can resist this sexy little minx. Don't you wish the guy in this pic was you? Are you telling me you wouldn't like to get your hands on this ass?! Wouldn't this just make your Christmas?! Yes doctor, this uber babe definitely gets my pulse racing! Oh how I envy the lucky girl in this shot! Linux has nothing that can possibly compete. Come on, you must admit she is better than an overweight penguin or a gay looking goat! Wouldn't this be more liklely to influence your choice of OS?

With sexy chicks like the lovely Ceren you could have people queuing up to buy open source products. Could you really refuse to buy a copy of BSD if she told you to? Personally I know I would give my right arm to get this close to such a divine beauty!

Don't be a fag! Join the campaign for more cute open source babes today!

$Id: ceren.html,v 9.0 2004/08/01 16:01:34 ceren_rocks Exp $

The problems with SMP on FreeBSD goes to show you that design by committee doesn't work.

If you want to see a BSD where SMP works correctly, have a look at DragonFly.

No, this sort of architecture is a general trend towards paralellization. It is smart, and it is known to work, and I would expect some bright Sparc wise people to chime in and say "u-huh" and some SGI wise people to chime in and say "I've seen some of this before." The OS people are starting to move things in this direction, and I've heard that Darwin has had the asynchronous messaging type threading model for a while (RTFA: the article explicitly mentions Tiger's GPU leveraging techniques). If you have the head for it, try reading up on NUMA and compare that with SMP.

The math is simple. CPUs are CPUs, and anyone can make one that is the same speed as the competition, and if they do it second they can do it cheaper. The guy that can make 20 CPUs work like one CPU that does 20 times the work in a given time will win because he can always just throw more hardware at the problem. The SMP guys have to go back to the drawing board. In this case, the only way to beat-em is to join-em. Maybe doing the specific "Cell" computing design isn't it, but the ol' PC is dead. If these things start hitting the commodity price-points.

That's a big, fat IF. So, don't bet on it (yet), but it's even worse to ignore it.

I'm a heavy Linux user. Why don't I use BSD?

I have a better question, as I don't care why you don't use FreeBSD: why do you feel obligated to tell us why you don't use it? If Linux works for you, great. Quite honestly all of your points are moot from my point for view for the following reasons:

1) This depends on your definition of a "desktop." To me, a Laptop is not a Desktop. If they were the same thing, why would they have different prefixes, Desk- and Lap-? I've used Fedora Core and I think it makes a Lousy Desktop. It has too many things I don't use installed in the default Desktop install. FreeBSD makes a much better desktop, with a much tighter install, while keeping all the bells and whistles *I* like. My opinion though. Since this is a subjective thing, I would say this point is moot and completely relative to the user.

2) Why would you need SMP for a standard desktop? And while I would Agree that FreeBSD doesn't do SMP Gracefully, it still does it basically the same way as Linux does from a theorhetical standpoint. I would argue the same thing that Matt Dillon argues - the basic underlying ideas behind both Linux and FreeBSD's SMP model are flawed and ungraceful. Check out the DFly site for more details. Technically, this is a moot point and is only a matter of time before FreeBSD is at the same level as Linux...i would argue they're so close right now the difference is insignificant.

3) While you might be correct with mindshare, there is not correlation between quantity of mindshare and quality of the final product. While the linux kernel is generally good, due to the decentalized nature of the linux community in general you end up with literally thousands of different distributions for different purposes, most of which are redundant and virtually useless. With BSD you have four to five different "distributions" with generalized goals - FreeBSD (server/workstation performance), OpenBSD (security), NetBSD (portability/stability), DragonFly BSD (cutting edge research/kernel-level innovations), and Darwin/OS X (general desktop optimization). While most interesting packages are indeed developed on linux, the majority run fine on all BSD's, with FreeBSD being compatible with the majority of the so-called cool linux-developed apps, including binary commercial linux games. FreeBSD also has binary 3D acceleration on x86 if you use an nVidia card, just like Linux. Moot point.

4) You mention the learning curve. Trust me, when i moved from linux to FreeBSD, there was virtually no learning curve. The RC system is much more sensical than the init.d system in my opinion. /etc/rc.conf controls base-system-level startup scripts with a simple binary switch (i.e. sshd_enable="YES"). User-installed programs with startup scripts are controled by their own files in /usr/local/etc/rc.d. To activate these, generally you just move prog_name.sh.sample to prog_name.sh. The system will then start it up the next time you reboot. The scripts are also startable from the commandline by root, without need for a reboot. Package management is as easy as pkg_add -r [progname] for binary packages, or simply installing something from the ports directory. The program is then patched and compiled from source. Simple. It would take you, if you're an advanced linux user, probably a weekend to get up to speed on how to admin a FreeBSD machine, and maybe a week to master it.

5) As for patches, you'll probably notice by checking out the FreeBSD website there hasn't been a security advisory in the base system since December 1st, 2004...more than a month ago. When they tag a source tree as stable, you better fucking believe it's stable. Ports, however, may introduce security vulnerabilities as they're programs not directly controled by the freebsd project, perse. If there's a program that the ports team feels isn't secure, they won

DragonFly is making huge advances. Sweeping changes are being made all the time that make DragonFly easier to maintain and more scalable, but performance is still good on a uniprocessor system, and stability is much the same as FreeBSD4 (which was the last FreeBSD release which actually worked). When the giant lock comes off, FreeBSD likely won't be able to hang with them. The upcoming multicore processors will just make things worse. FreeBSD6 is following the same path as FreeBSD5. If things keep going the same way, FreeBSD7 will have to be a DragonFly fork, just to stay relevant.

But will anyone care? FreeBSD is hemorrhaging developers. Right now, if the right three or four developers left, there wouldn't be enough detailed knowledge about the kernel workings to maintain the kernel without a long learning period that the FreeBSD project can't afford. Furthermore, how many of those developers will want to keep working on FreeBSD when it's just a DragonFly fork? DragonFly is positioned to replace FreeBSD, as well as fill niches that no BSD has filled before. Why would anyone want to work on FreeBSD, either as a DragonFly fork or as an obviously non-viable kernel model?

FreeBSD was nice, and is nice; I'm using RELENG_5 now, but shortly DragonFly will have a lot of its features in place, and I'll be moving to it. There are many others like me, ready to swap once DragonFly is ready, and you'd better believe that's trouble for FreeBSD.

DragonFly is making huge advances. Sweeping changes are being made all the time that make DragonFly easier to maintain and more scalable, but performance is still good on a uniprocessor system, and stability is much the same as FreeBSD4 (which was the last FreeBSD release which actually worked). When the giant lock comes off, FreeBSD likely won't be able to hang with them. The upcoming multicore processors will just make things worse. FreeBSD6 is following the same path as FreeBSD5. If things keep going the same way, FreeBSD7 will have to be a DragonFly fork, just to stay relevant.

But will anyone care? FreeBSD is hemorrhaging developers. Right now, if the right three or four developers left, there wouldn't be enough detailed knowledge about the kernel workings to maintain the kernel without a long learning period that the FreeBSD project can't afford. Furthermore, how many of those developers will want to keep working on FreeBSD when it's just a DragonFly fork? DragonFly is positioned to replace FreeBSD, as well as fill niches that no BSD has filled before. Why would anyone want to work on FreeBSD, either as a DragonFly fork or as an obviously non-viable kernel model?

FreeBSD was nice, and is nice; I'm using RELENG_5 now, but shortly DragonFly will have a lot of its features in place, and I'll be moving to it. There are many others like me, ready to swap once DragonFly is ready, and you'd better believe that's trouble for FreeBSD.