Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Operating Systems Software BSD

DragonFlyBSD 1.0 Released 272

eeg3 writes "One year after starting the project as a fork of the FreeBSD-4.x tree, the DragonFly Team is pleased to announce its 1.0 release. Check out the project's diary for a list of the improvements the project has implemented. Also, be sure to grab it from one of the mirrors."
This discussion has been archived. No new comments can be posted.

DragonFlyBSD 1.0 Released

Comments Filter:
  • Serious question: (Score:5, Interesting)

    by Anonymous Coward on Tuesday July 13, 2004 @07:34PM (#9692488)
    What was the reason behind this fork?
    • Re:Serious question: (Score:5, Informative)

      by RupertJ ( 520598 ) on Tuesday July 13, 2004 @07:42PM (#9692552)
      IIRC, the DF team wanted to implement SMP in a different way and weren't happy with the over-complicated approach in parts of FreeBSD. They're also ripping out a fair bit of the Perl dependent stuff too.

      Check the DF interview article for more info.
      • Re:Serious question: (Score:4, Informative)

        by swb ( 14022 ) on Tuesday July 13, 2004 @07:48PM (#9692607)
        Isn't Perl supposed to be dropped from FreeBSD's base real soon now? AFAIK it wasn't supposed to be a permenant part of 5, and wasn't going to be necessary to build world.

        For a project that wanted to get away from FreeBSD, the final diary entry shows at least two imports from FreeBSD.

        I can't be critical of a group of people that release their own BSD in their spare time, but I guess I'm not seeing SMP as being important enough to fork an entire BSD system.
        • Re:Serious question: (Score:3, Interesting)

          by RupertJ ( 520598 )
          Totally agree on the SMP thing. I work with some seriously "into it" techies (including myself) who live and breathe Linux/OpenBSD/FreeBSD/Solaris/HP-UX/IRIX at both work and home. Not a single one of them has a personal box with more than one CPU. Maybe that's a European, or maybe even specifically UK trend for developer's own kit at home. Weird. Maybe others would like to chip in here.

          As for the "two imports" thing, the only OSS project that I was aware of a serious initial temporary code-freeze on was w
          • Re:Serious question: (Score:2, Informative)

            by Anonymous Coward
            I have a couple SMP boxes at home.

            Once you use a dual cpu machine, you never want to go back to single cpu.

            This is true whether you're using Windows 2000/XP or *BSD/Linux.

            When running Windows 2000, misbehaving apps that would normally suck up 100% of cpu only consume 1/2 of available cpu power.

            Only downside (and maybe this is good for the reason mentioned just now) is that most apps don't take advantage of multiple cpus yet.

            Another comment I have is that hyperthreading and other pseudo-smp technologie
            • Good points, and it could also be that quality multi-CPU hardware always seems to fetch a hefty price here in Blighty. I remember seeing a Sun Ultra 80 with 4 x 400MHz processors going for something like US$600 on eBay USA, whereas a dual 300MHz Ultra 60 went on the UK site for about equivalent $650. Before anyone jumps down my throat with quotations for a dual P4 Xeon, notice the first line included the word "quality".

              I've just bought an HP Visualize Workstation from a place in the USA. In the UK, 400 (~U
            • Re:Serious question: (Score:4, Interesting)

              by NanoGator ( 522640 ) on Tuesday July 13, 2004 @08:57PM (#9693069) Homepage Journal
              "Only downside (and maybe this is good for the reason mentioned just now) is that most apps don't take advantage of multiple cpus yet."

              It's still useful even when you don't have SMP software. If you have an app that's burnin all of one CPU up, you still have the other CPU available to do just about anything else. For example, I have a plugin for Lightwave that is a 3D renderer. It's not multi-threaded yet, so I couldn't make it go faster with both processors. So while that was rendering, I played a game of Quake. Q3 ran great, and the rendering still happened on time. Pretty slick.
            • Re:Serious question: (Score:3, Interesting)

              by tverbeek ( 457094 )
              Once you use a dual cpu machine, you never want to go back to single cpu. This is true whether you're using Windows 2000/XP or *BSD/Linux.

              Or OS X.

              Budget constraints forced me to buy the least-possible PowerMac G5 for my home system last year, with only 1 CPU. The dual-G5 systems at the work place make me wish they paid me well enough to afford one ("two"?) myself.

          • Re:Serious question: (Score:5, Informative)

            by bsd_usr ( 140514 ) on Tuesday July 13, 2004 @08:21PM (#9692832) Homepage

            They're dropping Perl from the base. Meaning that it won't be required in order to build the system. Also, it will be installed as a third party port (add-on software).

            Actually, the 4.X branch still has Perl in the base system. The 4.X branch is where DFBSD forked from. The 5.X branch is where Perl was removed.

            Before, there were quite a few "system" programs that were perl scripts. Those programs were rewritten as "C" programs in order to rid the dependency of Perl in the base system.

            It's not a bad thing. A Unix OS really doesn't need Perl. And if you really do need it, you can easily install it via the ports system or via the package system. No biggie. Makes the base install smaller and neater.

            • Re:Serious question: (Score:5, Informative)

              by m.dillon ( 147925 ) on Tuesday July 13, 2004 @08:52PM (#9693031) Homepage
              Well, price and power is also a downside, especially if you run the boxes 24x7. All of our dual-cpu boxes (primarily DELL-2550's and some old VALinux boxes [running FreeBSD or DragonFly]) eat power like there was no tomorrow. Our single-cpu AMD64 boxes, on the otherhand, are twice as fast (as both cpus in the dell put together) and eat half the power (or less).

              In nearly all cases you will be paying a premium for a SMP box over a UP box, so much so that if space is not an issue for you, and you have no special requirements (e.g. big honking database app), it will be more cost and maintainance effective to buy two single-cpu boxes then one dual-cpu box.

              What this means is that I, at least, am turning off the SMP boxes in my machines room as fast as I can migrate them to new, faster, and far cheaper UP boxes.

              On the flip side, though, both Intel and AMD are moving to dual core (and power-pc has had quad cores for a long time), so a SMP-efficient kernel design is as important as ever. Within the next 5 years I believe that all consumer cpus will be dual-core at a minimum.

              Now all one needs to be able to do is seemlessly cluster them together, which is precisely one of our long-term goals! (seemless != the current hacks you see on Linux currently).

              -Matt

              • future vs. now (Score:4, Interesting)

                by r00t ( 33219 ) on Tuesday July 13, 2004 @09:46PM (#9693344) Journal
                You're comparing future DragonflyBSD features
                with current Linux features.

                Hey, Linux has a future too. It isn't stagnant.
                There are a number of active projects to give
                seamless clustering to Linux. The filesystem
                will be shared, including coherent page cache
                and user-accesible (flock, etc.) locks. There
                are a couple SSI projects. This stuff now has
                a conference of it's own. Major developers care.

                • Matt: "(seemless != the current hacks you see on Linux currently)"

                  r00t: " You're comparing future DragonflyBSD features with current Linux features."

                  I think he just meant it as an example. You know, brackets...

                  And besides, he put in "current" and "currently" in the same sentense so your comment seams a bit tense as well as redundant. I think we all agree that Linux will improve over time...
                • OMFG he criticized Linux! I'm going to cry!
                • Re:future vs. now (Score:1, Informative)

                  by Anonymous Coward
                  I've been an avid follower of the developments in FreeBSD for around 5 years now, so my overview of the entire history of "glue that binds" FreeBSD together isn't complete. That said, I've come to be a bit disappointed at how events in the last 18 months or so seem to be pushing the project in a direction that has made things more difficult, instead of more successful, that has shown distain for experience and quality and made FreeBSD a platform for large ego's to push their personal projects down everyone'
                • I think he said currently. Like. Twice.
              • Re:Serious question: (Score:4, Informative)

                by Alan Hicks ( 660661 ) on Tuesday July 13, 2004 @10:17PM (#9693490) Homepage
                Well, price and power is also a downside, especially if you run the boxes 24x7. All of our dual-cpu boxes (primarily DELL-2550's and some old VALinux boxes [running FreeBSD or DragonFly]) eat power like there was no tomorrow. Our single-cpu AMD64 boxes, on the otherhand, are twice as fast (as both cpus in the dell put together) and eat half the power (or less).

                I can't speak for whatever you're VA-Linux machines are, but aren't those Dells 2U rack mounts with something like 800 Mhz processors. Comparing that to a modern Athlon64 or Opteron isn't exactly fair.

                For the record, my purely anecdotal evidence follows. SMP machines are an order of magnitude better than a single UP, even at a lower combined clock rate. They just seem to work better, balance things better, and never get particularly bogged down by any single process like a UP machine.

                • by LWATCDR ( 28044 ) on Wednesday July 14, 2004 @08:31AM (#9696007) Homepage Journal
                  "For the record, my purely anecdotal evidence follows. SMP machines are an order of magnitude better than a single UP"
                  I do not think that you mean an order of magnitude. An order of magnitude would mean that you think an SMP machine is 10x better than a UP machine.

                  It is an easy rule of thumb. You buy an SMP machine when you can not find an UP machine that is fast enough.
                • " and never get particularly bogged down by any single process like a UP machine. "

                  Doh. That's coz most people haven't figured out a general/common way to make single process use both CPUs, so when you have a single process, extra CPUs are wasted.

                  One person's bogged down system is another person's CPU-usage efficient system.
                  • and never get particularly bogged down by any single process like a UP machine.
                    Doh. That's coz most people haven't figured out a general/common way to make single process use both CPUs, so when you have a single process, extra CPUs are wasted.
                    Well, the BeOS folks did, but that OS is now rather dead for other reasons.
            • by MavEtJu ( 241979 ) <<gro.ujtevam> <ta> <todhsals>> on Tuesday July 13, 2004 @09:24PM (#9693231) Homepage
              A Unix OS really doesn't need Perl.

              That was not the reason. The reason is that there is more than one Perl version out right now (5.0, 5.6, 5.8) and that different people need different versions. So to get rid of this, Perl is removed from the base-system and if you need whatever-version of perl, install it via the ports system. Much more flexible.

              Edwin
          • by pyrrhonist ( 701154 ) on Tuesday July 13, 2004 @09:32PM (#9693270)
            Not a single one of them has a personal box with more than one CPU.

            Does any of your friends have a CPU with Hyperthreading? That uses an SMP kernel, doesn't it?

            Maybe others would like to chip in here.

            Ha! I get it!

            • kudos to you (seriously), puns are great, too bad they aren't appreciated by everyone... glad to see you making one :)
            • But without a scheduler specifically written for hyperthreading, you might not get that great of performance. Hyperthreading and true SMP just act differently.
              • But without a scheduler specifically written for hyperthreading, you might not get that great of performance. Hyperthreading and true SMP just act differently.

                So what you're saying is that BSD doesn't do hyperthreading?

                • Of course not. Sheesh!

                  It (as in FreeBSD) does indeed do hyperthreading. But don't expect huge performance boosts after turning it on. For some usage profiles you might see an improvement, but for others you might actually get a performance decrease.

                  This is simply because FreeBSD hasn't specifically targetted the scheduler at hyperthreading. What it does is to treat treat a HT CPU machine as if it were a dual-CPU SMP machine. The official adjective to use in this situation is "naive".

                  This doesn't mean tha
                  • "What it does is to treat treat a HT CPU machine as if it were a dual-CPU SMP machine. The official adjective to use in this situation is "naive"."

                    "Naive" isn't so bad in that situation.

                    "Naive" is bad when you have a dual HT CPU machine being treated as a real quad-CPU SMP machine.

                    It's ugly when you have two CPU intensive processes being migrated to two HTs on ONE real CPU, instead of being migrated to TWO real CPUs.

                    This HT thing is really overrated. It probably works well for _some_ programs that don't
          • Not a single one of them has a personal box with more than one CPU.

            I can think of a very "sneaky" reason why. Dual processors tend to make response time much less dependent on system load. For a server, consistent response can easily be more important than the average response. It's predictable. For a developer on his own machine, this benefit only serves to mask variations that are important to the developer.
          • With Perl being dropped from FreeBSD, what are they actually replacing it with? (I know very little about the FreeBSD project and it shows =).

            Leaving aside CPAN, Perl is a nice integration of sh, sed, grep and awk. sh, sed, grep and awk are still there, so you probably don't have to replace Perl with anything.

          • Totally agree on the SMP thing. I work with some seriously "into it" techies (including myself) who live and breathe Linux/OpenBSD/FreeBSD/Solaris/HP-UX/IRIX at both work and home. Not a single one of them has a personal box with more than one CPU. Maybe that's a European, or maybe even specifically UK trend for developer's own kit at home. Weird. Maybe others would like to chip in here.

            I'm actually replacing a dual CPU system (PIII-667) with a single CPU system. I think you can get longer life out of a
        • by Anonymous Coward
          They're not "trying to get away from FreeBSD". They think FreeBSD 5 has taken the wrong direction in some areas. They consider DFly to be the logical continuation of the FreeBSD 4 tree.

          Because they're aware of how high quality FreeBSD is, they're very comfortable taking lots of code (drivers, etc) that would be impossible for such a small team to write/maintain. All they have to do is modify the code to work with their kernel modifications.

          In addition to their kernel changes, they plan on (eventually)
        • Re:Serious question: (Score:5, Informative)

          by aanantha ( 186040 ) <ahilan_anantha@yahoo.com> on Tuesday July 13, 2004 @09:24PM (#9693228)
          SMP will be mainstream very soon. You already need SMP support to use Hyperthreading/SMT. All recent Pentium 4's are 2-way hyperthreaded: so 2 logical processors. 2 sets of registers with shared functional units and cache.

          Intel and AMD will be coming out with dual core CPUs by the end of next year: 2 CPUs in one chip with a very speed interconnect between the two. A dual CPU configuration is often faster than a single CPU that's twice as fast. (On the other hand, Hyperthreading gives a measly 30% at most). A dual core Pentium series processor would have 2 real processors each with 2 logical processors: so a quad processor. Once all new computers have at least 2 processors in them, the operating systems that can utilize them effectively will be have a significant advantage.
          • Actually, a dual CPU configuration is rarely twice as fast as a single CPU that's twice as fast. Especially not in shared-bus architectures like the P4. Or the dual-core P4/AMD64 CPUs, which will share a memory bus.
            • Re:Serious question: (Score:1, Informative)

              by Anonymous Coward
              All joking aside, FreeBSD really is "dying" in a sense. After Jordan and Mike left, the project has been a shambles. The best way to describe FreeBSD kernel code now is "shabby". Matt is a brilliant perfectionist who wants to do the right thing. The current state of FreeBSD kept him from pursuing excellence.

              Unfortunately the FreeBSD core has come to be dominated by political types who are short on engineering skills. They gave Matt the air and locked him out of CVS. The FreeBSD kernel is currently full o

            • Actually, a dual CPU configuration is rarely twice as fast as a single CPU that's twice as fast.

              This was a typo, right? Because I said 2 CPUs were often faster than 1 CPU running at twice the clock rate, not that it was twice as fast. I admit that "often faster" was overstating it. It really depends on how parallel and I/O bound your workload is. The responsiveness of a dual processor system can be better than a single processor system because there will be half as many wasteful context switches per CPU.

            • The P6 and NetBurst SMP architectures use a shared memory bus. This means that as you add CPUs to a system, you decrease the memory bandwidth available to each CPU. The total memeory bandwidth of the system never changes.

              The K8 architecture uses a point-to-point memory system. The Opteron CPU includes the memory controller on the die and uses HyperTransport links to communicate between CPUs. This means that as you add CPUs to a system, you increase the overall memory bandwidth of the system. Each CPU
        • by phoenix_rizzen ( 256998 ) on Wednesday July 14, 2004 @11:01AM (#9697501)
          Perl was removed from the source tree with the release of FreeBSD 5.0. The installer installs Perl from a package so that the installed system still has Perl. But, it can be removed with a simple "pkg_delete perl\*" or upgraded to whichever version the user wants/needs/requires. All the system administration scripts that were written in Perl have been rewritten in either C or sh.

          DragonFlyBSD doesn't "want to get away from FreeBSD". They want to try out new directions, new technologies, new ways of doing things. There have been several dozen imports from FreeBSD 4.x and 5.x, as well as from NetBSD and OpenBSD. That's the nice thing about the BSDs: they are all separate projects, but the source code flows freely between them all.

          Considering that SMP will soon become standard issue in the x86 world, I don't see how SMP can not be important. Both Intel and AMD are putting the finishing touched on their dual-core CPUs. In another year, two at the most, you'll be buying a system with one physical CPU "chip", but two physical CPUs on it, making every system an SMP system.

          There are several different ways to make an SMP system. FreeBSD 4.x used a simple "Big Giant Lock" on the kernel. FreeBSD 5.x uses fine-grained, mutex-based locking and Kernel Scheduled Entities. DragonFly will use a lockless, message-passing system based on Lightweight Kernel Threads. Very different beasts, and it's not possible to use both LWKT and KSE in the same system. Why not fork off another project, see if it works or not, and either let it live as a separate OS or fold the tech back into FreeBSD as needed?? Forks are not inherently bad things.
        • I can't be critical of a group of people that release their own BSD in their spare time, but I guess I'm not seeing SMP as being important enough to fork an entire BSD system.

          That would be one of the main points. DragonFly wanted to get away from a specifically symmetric model (the "S" in SMP) that was being adopted for FreeBSD 5.x.

          Part of their aim is a more modern MP model that also benefits UP, and does not depend on symmetric processing. This can also gives them a headstart on support for the futu

    • Re:Serious question: (Score:5, Informative)

      by Bloody Pulp ( 101306 ) on Tuesday July 13, 2004 @07:51PM (#9692628) Journal
      DragonFlyBSD project is intended to take over development of the FreeBSD 4.X branch. Using a different method SMP and rewrite of packaging system.

      Check out the original announcement of DragonFlyBSD on the FreeBSD stable list:

      http://lists.freebsd.org/pipermail/freebsd-stabl e/ 2003-July/002183.html

      • by Anonymous Coward
        Well, FreeBSD 5.X also take over development of the FreeBSD 4.X branch. They just don't do it the same way.
  • For those of us hearing about this fork for the first time, could somebody explain what these people felt was so wrong about the FreeBSD tree that they decided to go off on their own?

    Or, to put it another way... what's the diference between DragonFlyBSD and FreeBSD?
    • FreeBSD 5 (Score:5, Informative)

      by CaptainPinko ( 753849 ) on Tuesday July 13, 2004 @07:47PM (#9692593)
      They felt that the approach the FreeBSD was taking for FreeBSD 5 was going in the wrong direction. I believe they hada problem with all the Mutexs or something specific like that. The main focus of DragonflyBSD is scalability and clustering. The are hoping to have SIS (Single Image Systems) as a priority. It won't be hear anytime son but thats a long term goal. OSNews has had some stuff on them over that last while. Here is the thread http://osnews.com/comment.php?news_id=7660 and here is the torrent I used http://download.exodusmachine.net/torrents/dfly-1. 0REL.iso.gz.torrent . Let me be the first to say: I for one welcome our new Dragonflu overlords! http://www.dragonflybsd.org/main/mascot.cgi
    • by Teckla ( 630646 ) on Tuesday July 13, 2004 @07:48PM (#9692605)

      For those of us hearing about this fork for the first time, could somebody explain what these people felt was so wrong about the FreeBSD tree that they decided to go off on their own? Or, to put it another way... what's the diference between DragonFlyBSD and FreeBSD?

      With all due respect, they answer your questions right on their home page! RTFHTML!

    • by eeg3 ( 785382 ) on Tuesday July 13, 2004 @07:52PM (#9692635) Homepage
      Quoting Matt Dillon, the project creator:

      However, while committer relations have always been an issue, DragonFly split off from FreeBSD-5 over major architectural differences, not anything else. We really do feel that FreeBSD-5 is taking the wrong approach to SMP and building something that is so complex that it will ultimately not be maintainable. We think we have a better way.

      You can find more information if you actually visit the project homepage [dragonflybsd.org], or read a fairly recent ONLamp.com interview [onlamp.com] with the developers.
  • Packages? (Score:4, Interesting)

    by RLiegh ( 247921 ) on Tuesday July 13, 2004 @07:50PM (#9692619) Homepage Journal
    What is the ports/packages situation look like for Dragonfly? Have they ported the old ones over, or is their selection severely limited?
    • Re:Packages? (Score:3, Informative)

      by eeg3 ( 785382 )
      Quoting Matt Dillon, the project creator:

      We have been in rigorous discussion over what kind of ports/packaging system we want to have. We have already agreed that the core ports/packaging system visible to end-users should be a binary system rather then a source build system. This isn't to say that sources would not be made available for customization purposes, just that most users just want to get a port/package installed as quickly as possible. While the BSD ports/packaging system does have a binary ins
    • Re:Packages? (Score:5, Informative)

      by m.dillon ( 147925 ) on Tuesday July 13, 2004 @08:00PM (#9692692) Homepage
      It's a big hack at the moment... we have an override system that runs on top of FreeBSD ports to try to keep the more interesting ports operational.

      The DragonFly team has been discussing what ports/packages system to move to (or to build one) that supports our requirements. We've investigated several existing packaging systems so far and are right now investigating OpenPkg (www.openpkg.org), as it has the multi-instance support that is an absolute requirement for us.

      Keep in mind that the DragonFly *USERLAND* is still primarily FreeBSD-4.xish (though with all the C99 stuff from FreeBSD-5 integrated), so anything that runs on 4.x will run on DFly with only minor tweaking.

      -Matt

      • by Hatta ( 162192 ) on Tuesday July 13, 2004 @10:03PM (#9693433) Journal
        Keep in mind that the DragonFly *USERLAND* is still primarily FreeBSD-4.xish (though with all the C99 stuff from FreeBSD-5 integrated), so anything that runs on 4.x will run on DFly with only minor tweaking.

        Now I'm really tempted to switch to BSD. Can't beat a system with integrated C99 [overgrow.com]
      • Just wanted to thank you a "little" belatedly for your ixemul.library for the Amiga in the days of yore, and IIRC the initial port of gcc... saved my ass in a dev project as my A3000 was the only thing my company "had" that could build/run the code I was working on... the project HAD to compile/run/work on a Solaris box I did not have physical or remote access to... It did.

        Once Dragonfly matures a bit, I will have to try it.
        Peace.
        • Oh my god. I'm laughing like a freak now. I had no idea what ixemul.library was (I checked it up now though) and I thought it had something to do with XML, 'cause "ix em ul" is pretty much exactly how French people say "XML". We used to joke pretty much about that were I used to work, 'cause I went on a few business trips to France around 2000 when XML was all the rage.

          And zen, ze applickatsion invockates ze ixemul.librrarrrii...

          Thanks for the laugh.
      • The DragonFly team has been discussing what ports/packages system to move to (or to build one) that supports our requirements. We've investigated several existing packaging systems so far and are right now investigating OpenPkg (www.openpkg.org), as it has the multi-instance support that is an absolute requirement for us.
        Took a look at openpkg.org, and it seems interesting. What is multi-instance support?

        Do you think OpenPkg has any advantages for the end-user, or are the differences more like things tha

    • From their downloads page on the site:

      GoBSD.com, a BSD-centric community website, is providing access to thousands of pre-built DragonFly software packages. These can be added via pkg_add -r packagename.

      From a quick cursory glance at the site, it looks like there are more than enough packages sitting around to be getting on with, you shouldn't be left with nothing to use if you don't want to.

      And there's always the option of compiling from source...

  • New BSD distros... (Score:3, Interesting)

    by NoMoreNicksLeft ( 516230 ) <john.oyler@noSpAm.comcast.net> on Tuesday July 13, 2004 @07:56PM (#9692664) Journal
    Deserve their own slashdot icon. Give this thing 3 months, and if they're still around, do the right thing Taco.
  • by Anonymous Coward
    fish wife!....flying tart! no, no! It got off to a flying START, and it's name...

    was DragonFly!
  • by Anonymous Coward on Tuesday July 13, 2004 @08:02PM (#9692707)
    The logo looks neat but the name is way too long to pronouce in conversation.

    Maybe they could name it Firebird. Oh wait...
  • by beforewisdom ( 729725 ) on Tuesday July 13, 2004 @08:53PM (#9693038)
    Does Dragonfly offer any visible differences to the casual end user?
  • Congratulations to the Dragonfly team! Instead of continously whining and moaning, they are speaking their opinion with what really matters: hard work and code. It will be interesting to see how well it continues to develope and evolve.
  • There are some really cool innovations here [dragonflybsd.org] that were a long time coming. One thing about Linux being slightly aged, large and now widley adopted, is that there is too much inertia against major change. DragonFly targets some serios kernel inefficiencies that will probably never get addressed in Linux. Rock on DragonFly!
  • Team Interview (Score:4, Interesting)

    by No_Weak_Heart ( 444982 ) on Wednesday July 14, 2004 @12:28AM (#9694189)

    Here's a nice, in depth interview at ONLamp [onlamp.com] with the core developer team from just last week. Covers a lot of ground, I found it very informative.

  • http://www.dragonflybsd.org/main/mascot.cgi [dragonflybsd.org]

    Fred is one mean looking insect, the go-lucky demon and the fat penguin are TOAST!

    Oh, it's ON now!

  • Could someone type "uname -a" and send results!
    • Re:uname(1) (Score:2, Interesting)

      DragonFly sage.**domain_removed** 1.0-RELEASE DragonFly 1.0-RELEASE #4: Sun Jul 11 20:29:40 GMT 2004 root@:/usr/obj/usr/src/sys/GENERIC i386

      Installed it this morning. Worth noting:

      - Dfly refers to BSD slices using the Linux/Windows term 'partition', and to BSD partitions as 'subpartitions'.

      - Installer cannot create a partition; you must do so manually with fdisk. Installer can format the partition, however.

      - Easy, streamlined installer that gives you a base BSD system.

      - DOES NOT INSTALL A
      • Re:uname(1) (Score:2, Informative)

        by jsonn ( 792303 )
        DragonFly and FreeBSD come with fetch, which offers most of the functionality of wget (minus the mirror stuff). That's enough to download tarballs and the like. For packages, you can also directly use "pkg_add -r" to use binary packages e.g. from gobsd.com without having to compile them or even install the ports tree.

        A browser doesn't belong into a base system, compare with Debian which also doesn't have one by default.

        Having the bash as default shell is a typical Linux user comment. There are better shel
  • The BSD communities alone are just about enough to sell me on using a BSD. They're not as ready to jump into flamewars as some others can be. If there's an unresolvable disagreement, one side will just fork it and everybody still gets along. If I had the fortitude to switch to BSD I probably would. Being part of such a level-headed group would be much easier on the nerves when looking for help.

    Or am I mistaken? These are just my perceptions from the outside. Is the BSD Way not as rosy as I picture it?
  • Isn't it bad Karma for an OS to have a BUG as their mascot?

Do you suffer painful hallucination? -- Don Juan, cited by Carlos Casteneda

Working...