Slashdot Mirror

← Back to Stories (view on slashdot.org)

IRC Forum with Matthew Dillon of DragonFly BSD

Posted by CowboyNeal on from the up-close-and-personal dept.

weebl writes "Thursday October 9th at 6:00PM PDT (9PM EDT/1AM GMT) SlashNET's #forum channel will be hosting a Q&A session with Matthew Dillon of the DragonFly BSD Project. This is your opportunity to ask about DragonFly BSD, BSD in general, or any other questions you might have for him. DragonFly BSD was first announced this past July." If you can't make it to the forum, SlashNET will have a bot running earlier in the day for question submissions, and logs available afterward.

223 comments

  1. Shame.... by NightSpots · · Score: 5, Interesting

    His contributions to FreeBSD will be missed.

    I'm sure I represent a large portion of the community who greatly appreciated his work on the VM subsystem (he even pointed the Linux folks in the right direction on more than one occassion), and am disappointed to see him leaving the project.

    I understand that not everyone gets along, that goals differ between members; it's just a shame to see it happen.

    --

    --
    Use Vobbo for Video Blogs
    1. Re:Shame.... by Anonymous Coward · · Score: 0

      (he even pointed the Linux folks in the right direction on more than one occassion)

      So THAT's where the copyrighted SCO code came from eh? Well good riddance, I say.

    2. Re:Shame.... by NightSpots · · Score: 1, Insightful

      (Joking aside....)

      Everyone knows that the BSD codebase is infinitely more clean than the Linux codebase.

      Remember, the last few times there have been license issues with FreeBSD, it was people (*ahem* linux *ahem*) stealing FROM them.

      --

      --
      Use Vobbo for Video Blogs
    3. Re:Shame.... by Anonymous Coward · · Score: 0

      Well, if he keeps doing great stuff like 'There's Something About Mary,' his movie career will regain its previously monumental status and eclipse all of his contributions to BSD. ;)

    4. Re:Shame.... by Anonymous Coward · · Score: 0

      What issues with the FreeBSD codebase?

      Its hard to steal under the BSD license..

    5. Re:Shame.... by Anonymous Coward · · Score: 1, Insightful

      He didn't use the right words. He meant that Linux kernel developers use code from BSD and don't have the decency to give credits -still perfectly within the BSD lincese. Of course this is not something new to Linux. IMHO, i'm not sure if Linux is more BSDish or SCOish -time will tell.

    6. Re:Shame.... by Anonymous Coward · · Score: 0

      Nope. Steal is the right word.

    7. Re:Shame.... by Anonymous Coward · · Score: 0

      > Its hard to steal under the BSD license

      No, it's easy. Just take UNIX source code and stick Berkeley copyrights on it. See BSD UNIX 4.4 and FreeBSD 1.x.

    8. Re:Shame.... by shepd · · Score: 1

      >Nope. Steal is the right word.

      Nope, it ain't.

      I think you'll find law in most other countries similarly clear on this issue.

      --
      If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
    9. Re:Shame.... by Anonymous Coward · · Score: 0

      ahh that BSD license sure is "free" huh?!

    10. Re:Shame.... by CoolVibe · · Score: 4, Insightful
      Why the hell is everyone thinking that Matt left? This fork isn't an 'angry' fork. DFBSD is just another BSD based off of FreeBSD 4 that is exploring some new ideas that Matt has. It's evolution. If DragonFly beats the pants off of 5.x in the future, I'm sure lots of DragonFly code will be appearing in the "official" FreeBSD tree.

      Matt already wrote a SHITLOAD of code for DragonFly. He already overhauled the threading in the kernel, and put in a totally new slab allocator. Right now he's overhauling the namecache system.

      Also, the DragonFly gang are doing chores nobody in the official FreeBSD camp cares enough about, like removal of __P(), removal of the 'register' keyword and ANSIfication of old K&R code. Of course we'll be seeing those efforts back in the other BSDs.

      These changes that Matt and his merry gang of hackers are making are changes that would never be accepted by the FreeBSD deities with a commit bit,because they're intrusive. Hence the reason Matt forked off DragonFly.

      He never left FreeBSD, dammit. Get over it.

    11. Re:Shame.... by Anonymous Coward · · Score: 0

      Matt's VM is what inspired Rik Van Riel to write the Linux VM, and the Linux VM is *HEAVILY* based on these ideas/concepts. He spoke at length to Dillon for months.

      Dillon's still part of the FreeBSD community.

      He just sees a different direction that is interesting, that he wants to pursue. I actually find his DFBSD fascinating - it's a "more AmigaOS-like" OS. And, IMHO, AmigaOS rocked for the time.

      But, Dillon's still part of FreeBSD. He's still contributing. Not as much, but hey, you can only keep so much up for so long... :)

    12. Re:Shame.... by m.dillon · · Score: 4, Informative
      The more I look back upon it the more I think forking off DragonFly was the right thing to do. The timing could not be better, in fact. A year ago would have been too early (because we would have had to backport a whole lot more from 5.x, whereas in the last year the FreeBSD folks have backported a considerable amount of work from 5.x to 4.x), A year from now would be too late (4.x would have been 'dead' for too long a period of time). Now is the right time.

      I still contribute to FreeBSD. If I see a bug or a security issue in DragonFly that also exists in FreeBSD they get a head's up, and some of the patch sets we've comitted to DragonFly have been organized in as legible a way as possible to promote a possible port from DragonFly to FreeBSD for those FreeBSD folks interested in the work. But my main focus these days is DragonFly.

      The biggest loss to FreeBSD from my departure is that they have one less person tracking down bugs in the kernel. To be sure, I had done less and less of that over the last year as FreeBSD-5 continued to diverge from what I believed could be supported, but before anyone chimes in with a silly 'Matt hasn't done anything' comment I will note that I spent several days reviewing and commenting on Jeff's scheduler and slab allocator work, which benefited greatly from the comments, plus brainstorming sessions with Julian on KSEs, with Alan and Tor on VM issues, and so forth. I had attempted to put FreeBSD-5 on a better track several times, but the ideas were rejected in piecemeal. I don't think there are any big-picture/multi-disciplinary folk left in the project, which is a problem. Basically the FreeBSD-5 team seems to suffer from a sort of myopia. It is possible to defend a piece of work taken in isolation, such as priority stealing for mutexes or kernel preemption, but when you look at the big picture there are simply too many such pieces, each complex in its own way, in the FreeBSD-5 kernel. The result is a huge mess that only a few programmers can actually navigate through without introducing new bugs, and that is a real problem insofar as progress in FreeBSD-5 goes. Too many developers are working only in their own little corner of their world and too few developers are doing general debugging and architectural work. And, most especially, too few developers are looking out for and supporting the end-users, something that has been a significant part of my work ethic ever since I wrote DICE. There are plenty of FreeBSD developers, their numbers certainly are not decreasing, but the class of developers is far less balanced now then it was in 1998. That is my opinion, anyway.

      Not having to deal with FreeBSD politics anymore as significant reduced my stress levels, and being able to work on innovative new designs rather then having to fix other people's bugs has improved my disposition dramatically :-).

      -Matt

    13. Re:Shame.... by NightSpots · · Score: 1

      He never left FreeBSD, dammit. Get over it.

      He was stripped of his commit bit. Effectively, that means his contributions are slow and filtered. He's not gone, but his role is diminished.

      --

      --
      Use Vobbo for Video Blogs
    14. Re:Shame.... by renoX · · Score: 1

      >removal of __P(), removal of the 'register' keyword and ANSIfication of old K&R code

      *removal of __P()?
      Could you explain what this is? I suppose that this is FreeBSD specific..

      *removal of the 'register' keyword
      If memory serves, the register keyword is only a hint to the compiler, so a global search and replace should be enough to remove the register keyword, no?

      *ANSIfication of old K&R code
      K&R, ouch my memory is fading, but I think that some preprocessor can do it automatically, no?

      Not that I'm not criticising: cleaning old code is good, but the two points I understood do not seem too difficult.

      The thing which looked interesting in DragonFly is the execution of system call within the user's context if it is possible (I've read that the AmigaOS could do this before).
      I'm wondering what is the main problem to do this for an OS?
      There must be some difficulties otherwise every OS would do it..

    15. Re:Shame.... by Anonymous Coward · · Score: 0

      *removal of __P()?
      Could you explain what this is? I suppose that this is FreeBSD specific..

      Google is your friend

      If memory serves, the register keyword is only a hint to the compiler, so a global search and replace should be enough to remove the register keyword, no?

      The problem probably isn't doing the work, but getting the changes accepted by the powers-that-don't-like-change.

    16. Re:Shame.... by renoX · · Score: 1

      I did a google search before posting, but without success, thanks for the link.

      >The problem probably isn't doing the work, but getting the changes accepted by the powers-that-don't-like-change.

      Well now that he has his own codebase, this shouldn't be too much a problem ;-)

    17. Re:Shame.... by sander · · Score: 1

      __P () is what lets the same code be compiled by both ansi and k&r c compilers - ansi compiler sees the prototype and k&r sees a version that keeps it civil too.

    18. Re:Shame.... by Anonymous Coward · · Score: 0

      removal of __P(), removal of the 'register' keyword and ANSIfication of old K&R code

      That's started in the 5.x branch quite a while ago. Since Matt broke off the 4.x branch instead, he had to redo all that.

    19. Re:Shame.... by Anonymous Coward · · Score: 0
      What I Know About BSD
      1. You can not play games on it.
      2. It cannot be used by my grandma.
      3. It lacks a GUI of any note.
      4. There is no support available for it.
      5. It is an assortment of fragmented OSes.
      6. It cannot be run on the x86 platform.
      7. You have to compile everything and know C.
      8. Support for the latest hardware is always poor.
      9. It is incompatiable with GNU/Linux.
      10. It is dying.
  2. Re:Owned by SCO by Anonymous Coward · · Score: 0, Offtopic

    SCO isnt a very nice company. I would classify their attempts to extract funds from the Linux community as "crappy"....also, I believe them to have alterior motives

  3. IRC Is Dead by Rick+the+Red · · Score: 3, Funny

    Didn't you get the memo?

    --
    If all this should have a reason, we would be the last to know.
  4. A dragonfly bit me the other day by Dancin_Santa · · Score: 2, Funny

    I was just doing some gardening and it bit me on the back of the hand.

    I don't want to use any operating system that reminds me of that traumatic experience.

    I liked Dillon in Footloose, though.

    1. Re:A dragonfly bit me the other day by Brandybuck · · Score: 2, Funny

      Phhhhft! Linus got charged by an angry penguin, and had to run for his life, but he still works on Linux. I mean, having some rabid penguin chase you around a zoo is much more traumatic that getting bit by a dragonfly.

      --
      Don't blame me, I didn't vote for either of them!
    2. Re:A dragonfly bit me the other day by Anonymous Coward · · Score: 0

      it bit me

      I know your post bugs me, so I can understand why a dragonfly would want to take a bite.

  5. Be sure to ask him... by Anonymous Coward · · Score: 0, Funny

    about the future of *BSD and its imminent death.

    1. Re:Be sure to ask him... by Anonymous Coward · · Score: 0

      Hey, it's still $699 cheaper than Linux...

    2. Re:Be sure to ask him... by Anonymous Coward · · Score: 0

      Nope, fraid not. Same $699 license fee applies. At least Microsoft thinks so, since they're licensing BSD code from SCO right now.

  6. focus by endx7 · · Score: 3, Interesting

    This will be a good chance to find out what DragonFly BSD will be standing for.

    We all know the 3 main (free) BSDs have their focuses, namely:
    FreeBSD: ease-of-use and i386 platform (plus a few others)
    NetBSD: portability
    OpenBSD: security, plus some focus on ease-of-use
    and then there are a few other minors, and Mac OS X

    But the question is, what is DragonFly BSD's focus? What will it offer for us? How will it be useful?

    Perhaps we'll learn at this chat session.

    1. Re:focus by NightSpots · · Score: 4, Informative

      Since it's based on FreeBSD 4, it'll be "All of good things of FreeBSD 4 with a focus on performance."

      There's a LOT of work going into fine grained locking to allow faster SMP (which is a classic slowdown in FreeBSD 4) - light weight kernel threads, advanced caching, messaging APIs, and even plans for a package system that (if it works?) would completely change the way people think about installing third party software.

      There are a lot of big things planned. It may be slow to start, hopefully it'll take off... and we'll see some cross development with the other BSDs.

      --

      --
      Use Vobbo for Video Blogs
    2. Re:focus by Anonymous Coward · · Score: 0

      But the question is, what is DragonFly BSD's focus? What will it offer for us? How will it be useful?

      It will have more copied SCO code than the competition. It will also encourage homosexuality, pedophilia, and piracy of copyrighted music.

    3. Re:focus by Anonymous Coward · · Score: 1, Insightful
      Perhaps we'll learn at this chat session.

      Perhaps you can learn at this webpage, dipshit.

    4. Re:focus by thallgren · · Score: 5, Insightful

      >There's a LOT of work going into fine grained locking to allow faster SMP

      Unless I'm totally wrong, this is exacly the opposite from what DragonFlyBSD is about. Matt has never liked the way FreeBSD and Linux are designed, a kernel sprinkeled with locks.

      Instead, he's trying to do a kernel where kernel-side subsystems communicate via message-passing, not too far from how exec.library worked in AmigaOS.

      So Matt and his cowboys/cowgirls are actually removing locks. :-)

      Regards, Tommy

    5. Re:focus by Leimy · · Score: 3, Informative

      As far as I know... and I have been following the list as well as reading the website... I see no plans to rely on fine-grained locking as an SMP enabling mechanism. There is an AmigaOS based messaging system that will allow people to run things like Filesystem drivers in userland should they choose to or they can keep it in ther kernel.

      But why are you reading /. comments to find out what this thing is? Go to the website and see for yourself.

    6. Re:focus by goon · · Score: 1

      OpenBsd could probably summed up more accurately as emphasising stability and security. Not so sure about ease of use.

      --
      peterrenshaw ~ Another Scrappy Startup
    7. Re:focus by m.dillon · · Score: 3, Informative
      Some MP locking is unavoidable, but DragonFly will have much, much less of it then any other MP operating system that I know of. Having to use an MP lock is basically an admission that there will be cache contention between cpus... if not the lock itself, then the data that is being covered by the lock. If you have 4 cpus and all of them at one time or another are accessing a common data structure, then you are wasting 3/4 of your available aggregate L1 and L2 cache space storing that data structure plus you are wasting cycles obtaining the lock, wasting hardware cycles due to cache management operations, and wasting cpu.

      Now, of course, some data structures are more important then others. It doesn't make sense to try to avoid all locking... there are plenty of situations where you have to eat the duplication in the cache and plenty of situations where you have to eat cache mastership changes.

      But there are a ton of situations where the waste is not necessary. In DragonFly these situations translate to: The scheduler, the slab allocator, device driver interrupt management, and the networking stack, just to begin with.

      Lets take the networking stack as an example. In a fine-grained mutex model if a cpu is available it might be called upon to run pending work for the network stack... say processing packets for various TCP connections. In order to do the work the kernel will pull the next packet off the queue, figure out the protocol and port, obtain a fine-grained mutex on the PCB, and then do the work.

      In the DragonFly model the network interrupt will queue the packet and the queueing code will peek at the packet and direct it to a particular protocol thread. Any given connection will be directed to a single thread so, for example, if you have a 4-cpu system and you have told the kernel to create 4 TCP protocol stack threads (one on each cpu), then each new TCP connection will be assigned to a particular thread. Only that thread will process packets associated with that particular TCP connection, which means that no locks are required to process packets for that TCP connection and no L1/L2 cache duplication will occur between cpus because only one thread will ever touch it. If you have 1000 TCP connections, each of your four TCP protocol stack threads will be assigned approximately 250 of them.

      In DragonFly's case the trick then becomes to balance the assignments, but even here we get a leg-up because simply distributing the connections by ^^ mod the number of protocol threads will get you most of the way to that goal. When you add in the cache-locality you have just achieved (you have 4 times the available data cache by not sharing the PCBs across multiple cpus) the result is far higher performance then a fine-grained-but-perfectly-balanced model could ever give you.

      -Matt

  7. Why Dragonfly? by Valar · · Score: 4, Interesting

    If I am a happy Linux or BSD (of some non-Dragonfly kind), then what would you say to entice me to switch? In other words, what do you think Dragonfly is particularly good at, that maybe is lacking elsewhere?

    --

    ====
    Crudely Drawn Games
    1. Re:Why Dragonfly? by Valar · · Score: 1

      Sorry, I forgot to mention this: that was addressed to any DragonFly users in the crowd. The comment doesn't make much sense otherwise. Though I have been known to talk to myself...

      --

      ====
      Crudely Drawn Games
    2. Re:Why Dragonfly? by Anonymous Coward · · Score: 0

      Well, that make me want to switch! Sounds great!

    3. Re:Why Dragonfly? by be-fan · · Score: 3, Informative

      Dragonfly isn't a completed project at this point, or even one that made changes substantial enough to differentiate it from other systems. Dragonfly forked from FreeBSD because they have some very different ideas about where the kernel should be headed than the FreeBSD folks. Dragonfly will be based on a model of very lightweight threads that communicate via a messaging mechanism. They think they can get highly scalable designs without all the locking that the Linux and FreeBSD designs use. If it works, it could be a very large step forward for multi-CPU and clustured systems.

      --
      A deep unwavering belief is a sure sign you're missing something...
    4. Re:Why Dragonfly? by m.dillon · · Score: 4, Interesting
      DragonFly's first official release will be in a little less then a year. Half of that time is going to be spent rewriting the infrastructure, which is outlined on the site www.dragonflybsd.org We already have light weight threads and our slab allocator in place (which are a biggies) and the basic infrastructure for syscall messaging and DEV messaging in place. We are also steadily bringing in those elements from FreeBSD-5.x that make sense. At the moment my focus is on fixing inherited bugs and rewriting the namecache code. Other DragonFly developers are focused on syscall sepraration, networking, and userland bits. We are being very, very careful to preserve and improve upon the stability inherent in earlier 4.x releases. In fact, the namecache stage-3 work has been delayed over two weeks now while I have backed up and refocused on fixing a number of unrelated bugs.

      The biggest topic on our lists right now is the discussion on the infrastructure required to support a good binary and source-based package management system. FreeBSD's package management system currently suffers greatly from bitrot and upgrade-breakage (where upgrading one package breaks half a dozen others), amoung other problems. We are discussing the use of variant symlinks and VFS-based 'environments' for deploying and validating port dependancies in a manner that allows multiple versions of anything to coexist on the same system.

      Basically you can think of DragonFly as being all the things I've always wanted to do but couldn't due to politics in the FreeBSD camp. FreeBSD-5 has gone down a road that I believe will lead to a slow, cumbersome, and unmaintainable result. There are plenty of examples of this but the most aggregious is thread preemption in the kernel, preemptive thread movement between cpus (also while in the kernel), and a ridiculously complex API for various types of mutex operations. There are good things in FreeBSD-5, and we will snarf them as appropriate.

      The timing is appropriate. FreeBSD-4.x is nearing its end-of-life, and it is obvious that less care is being taken in preserving its vaunted stability then in the past. DragonFly will be the logical successor to FreeBSD-4.x statring in around a year, and I also fully expect to beat the shit out of FreeBSD-5 SMP-performance-wise by the time too.

      DragonFly's kernel model is basically to operate on cpus in isolation, with movement beween cpus strictly managed. For example, there is a separate light weight kernel scheduler on each cpu which handles all operations related to that cpu and requires the use of no mutexes. The slab allocator is also per-cpu and mutexless. If an operation needs to work on a data structure owned by another cpu an asynchronous IPI (message) is sent to that cpu rather then performing a locking/mutex operation. For example, if cpu #1 needs to free data owned by cpu #2's slab allocator, cpu #1 queues the work to cpu #2 (and in the case of a memory free, the work does not have to be done immediately). The term 'asynchronous' is important in this context, because it means that the IPI latency between cpus can be entirely absorbed and that sequences of messages (in more heavily loaded systems) can be processed in a tight loop. When we get into more complex entities such as the networking stack, the intention is to run the protocol stacks as threads (possibly multiple threads, one on each cpu or as needed by the situation) and assign protocol control blocks to particular threads on particular cpus. This eliminates nearly all locking and mutex operations related to any given protocol control block and guarentees cache locality of reference. If done properly the individual cpu caches on SMP systems will wind up with less duplication and far higher efficiencies then one gets using a fine-grained locking mutex model. In fact, DragonFly's model works equally well in both UP and SMP environments and we expect the SMP support will cause virtually no loss in performance on UP boxes.

      -Matt

    5. Re:Why Dragonfly? by Dick+Faze · · Score: 1

      So does all this mean that MP FreeBSD machines will be able to do all the funky science shit I see on two out of three pages of "Linux Journal"? 860 node BSD clusters in our future? That sure would help me out in the next Usenet pissing contest. Plus I could justify taking W2k off my 4 way xeon box. Matt should be elected to high public office.

    6. Re:Why Dragonfly? by aphor · · Score: 1

      The biggest benefit/drawback that I see is all the Slashdot trolling mirroring/mocking/echoing the "Imagine a Beowulf cluster of these" with "Imagine a Dragonfly cluster of these..." The change will be felt mostly when the pissing contest and flamewar between the trolls' biters resurrect the old Linux/BSD holy war.

      I predict this will happen when people figure out how to get the Dragonfly threading/messaging code into NetBSD.

      --
      --- Nothing clever here: move along now...
  8. Re:It is now official by endx7 · · Score: 4, Funny

    It is now official - Netcraft has confirmed: *BSD is dying

    I really shouldn't reply to this kind of comment, but doesn't that comment seem kinda weird if you consider the fact netcraft runs FreeBSD?

  9. Re:DragonFly BSD Problems by Anonymous Coward · · Score: 0

    Wow, insert "OS X" in every place where there is a DragonFly BSD in that message, and you have the same Mac OS X troll that's been posted on every Apple story for several months. I can't believe someone actually modded you 'Interesting.'.

  10. Re:Owned by SCO by Anonymous Coward · · Score: 0

    "posterior"

    ass

  11. Re:In other news, YEAH RED SOX!!!! by Anonymous Coward · · Score: 0

    First the Giants (my team) choke, now the A's choke, and tomorrow a sex offender will be elected governor. It's a great time to be a Californian!

  12. Re:DragonFly BSD Problems by Anonymous Coward · · Score: 0

    >what is the deal with you DragonFly BSD fanatics?

    >I won't bore you with the laundry list of other problems that I've encountered while working on various DragonFly BSD machines

    This is a troll.

    If you are using DragonFlyBSD its because you are using bleeding edge diff's to the FreeBSD 4.8 source tree. DragonFly is a few months old, and likely unapolegetically broken in some places.
    I doubt that anyone is currently using it in production. 'DragonFlyBSD fanatic' is an amusing strawman.

    I am curious about this poster's long history of DragonFlyBSD woes. Dillon started the fork in July. There is no official install-CD as yet. It is curious that one so disaffected with BSD-ish systems would be slogging through CVS to build the boxes that have given him 3-4 months of woes.

    ignore this guy

  13. The real shame by the+man+with+the+pla · · Score: 3, Insightful

    Matt Dillon deserves absoluetely no pitty. His outrageous immaturity justified the revocation of his commit bit 1000 times over. Shame on you for painting him to be some kind of victim.

    --
    The linux hacker
    1. Re:The real shame by Anonymous Coward · · Score: 0
      roger that -- mod this shit up!

      dillon is another bsd megalomanic like Theo

    2. Re:The real shame by m.dillon · · Score: 2

      Gee I hope not *exactly* like Theo. But watch out who you lambast. Theo is responsible for or as managed some fairly major improvements in the open-source world, and we are far better off with that work.

    3. Re:The real shame by Anonymous Coward · · Score: 0

      FACK OFF! I'm with the Liberation Army of Palestine.

  14. Is this the guy that wrote dcron? by kingLatency · · Score: 1, Interesting

    Since this guy shares the name with that actor, I remembered the name. Is this the same Matt Dillon who is responsible for dcron on my Gentoo system?

    --
    "I've got to stop masturbating! It makes me too lazy! Stop it, Albert. Stop it." -- Albert Einstein
    1. Re:Is this the guy that wrote dcron? by Anonymous Coward · · Score: 0

      No. He's the one who cleaned up Dodge City.

    2. Re:Is this the guy that wrote dcron? by m.dillon · · Score: 3, Interesting
      Yah. I still get an occassional email regarding dcron. DCron was written because, at the time anyway, the VixieCron that Linux was using had a huge number of bugs in it. For example, just changing the time could cause VixieCron to suddenly execute hundreds of jobs all at once. This was a long time ago and I expect VixieCron has been fixed since then, but that was the original motivation for writing DCron. I just wanted something small, simple, and dependable, with per-user capabilities.

      It is gratifying to see that DCron is still being used regularly, but I am a bit miffed that nobody has gone and made any truely significant improvements to it. That is part of the nature of open-source, I guess.

      -Matt

    3. Re:Is this the guy that wrote dcron? by schon · · Score: 1

      It is gratifying to see that DCron is still being used regularly, but I am a bit miffed that nobody has gone and made any truely significant improvements to it.

      As a happy user of DCron, I can't honestly think there's anything significant to improve upon. It works, and works well. Thanks for a great piece of software!

  15. Re:Owned by SCO by Anonymous Coward · · Score: 0

    That was a sweet putdown on so many levels. Still laughing...

  16. Re:DragonFly BSD Problems by Anonymous Coward · · Score: 0

    I did, for I am weasel.

  17. Too many Matt Dillons! by PHPee · · Score: 4, Funny

    As soon as I saw Matt Dillon's name associated with BSD, I got really excited. I mean, who knew that the ol' gunslinger Marshal Matt Dillon became a programmer?

    Then, I realized I must have been thinking about the wrong Matt Dillon, but I still thought it was weird that the guy from There's Something About Mary became involved in a BSD project.

    Finally I remembered the other Matt Dillon who developed the DICE C compiler for the Amiga back in the good old days.

    1. Re:Too many Matt Dillons! by MobyTurbo · · Score: 2, Informative
      Finally I remembered the other Matt Dillon who developed the DICE C compiler for the Amiga back in the good old days.
      That Matt Dillon is the FreeBSD one, he did both the DICE compiler and the FreeBSD VM (and some other FreeBSD stuff.)
    2. Re:Too many Matt Dillons! by Anonymous Coward · · Score: 0

      He can hardly be credited with "doing" the FreeBSD VM (depending on your definition of "doing"). The VM system was originally picked up from CMU Mach (where it was written by Avie Tevanian and Michael Wayne Young) into BSD and improved in FreeBSD significantly by some of the older (in terms of involvement) FreeBSD developers (John S. Dyson, at least).

      Matt Dillon's involvement with FreeBSD was relatively recent (starting in '98 or so), and while he has contributed to the VM system significantly, crediting him for creating it isn't really justified.

    3. Re:Too many Matt Dillons! by m.dillon · · Score: 4, Informative
      You could credit me with being the primary mover for fixing the VM system going from 3.x to 4.x, and the buffer cache as well. I did some rewriting when it was called for, but most reorganized smaller sections of code in order to get rid of race conditions (bug fixing), clean up performance issues, and so forth. This created some friction because nobody else was willing to do the necessary work yet everyone still had an opinion on how the work should be done.

      I also completely rewrote the swap management code from the old list-of-holes format to a fixed radix tree with dynamic size hinting, fixed issues in VN and MFS, and generally put out a lot of fires all over the tree. Most of what I did in BSDland was fix bugs, because there were a lot of bugs that needed fixing and, again, there isn't much of a point having an advanced operating system if it crashes every so often.

      I probably spent far more time fixing bugs then anything else. My involvement with FreeBSD began during my BEST Internet days, in the 94 or 95 timeframe, with a commit bit coming in '98 I think, but my involvement with BSD began in 1985 at UC Berkeley, at about the same time I got involved with the Amiga.

    4. Re:Too many Matt Dillons! by Anonymous Coward · · Score: 0

      He also wrote the bible and fathered 2 of my children.

  18. Re:On *BSD's Tombstone: by AvengerXP · · Score: 0, Offtopic

    Might be a troll but you have to admit it's pretty nice.

    --
    Trolls dont like to be Flamebait, because they burn so well. Protect our Troll heritage!
  19. Re:BSD is developed by idiots by Anonymous Coward · · Score: 0
    BSD is really bad, but it is supported and developed by idiots, and doesn't have enough protection of our Freedom, and is just absolutely unfriendly to users.

    Do you mean the _OS_ is unfriendly or are you referring to the *BSD _community_?

    If the latter, I would say there is just as much, if not more "RTFM STFU j00 sux0r n00b!" in today's Linux "community" nowadays.

  20. Re:*BSD for Windows XP? by Anonymous Coward · · Score: 0

    I think that Windows XP has built-in security features that will disallow the installation of an OS such as BSD that is not "trusted". This is reasonable, after all BSD was responsible for the so-called "internet worm" and many other security holes.

    Anyway, XP takes the best parts of the obsolete Unix paradigm, and combines it with a truly best-of-breed user experience, while throwing out the rest. You don't need anything else.

  21. Re:*BSD for Windows XP? by Dancin_Santa · · Score: 1

    BSD is an operating system, so it actually can't run under WinXP. It gets to run all by itself.

    You could install it on another partition and actually dual boot BSD and Windows (dual booting is where you have two operating systems on the same machine, side by side). You can only run one operating system at a time, though.

    You can download the latest FreeBSD ISO (bootable CD image) from here

  22. Re:*BSD for Windows XP? by Anonymous Coward · · Score: 0

    BTW, be sure to install those service packs, they provide lots of exciting new features. You're really missing out otherwise.

  23. The logs will be at slashnet.org by Motherfucking+Shit · · Score: 4, Informative

    For some reason, nobody ever bothers to mention where the logs of the Slashdot IRC forums get posted. After the IRC interview with CmdrTaco and Hemos a few months ago, it took me some digging to figure out where the log wound up.

    For those who can't make the chat, the log will eventually be at http://www.slashnet.org/forums/

    Editors: After the chat is over, any chance of having the log URL linked to the story text as an update?

    --
    "BSD: Free as in speech. Linux: Free as in beer. Windows 10: Free as in herpes." --Man On Pink Corner in #52607549.
  24. Lets make a bet... by Billly+Gates · · Score: 1, Interesting

    .. on how many hundreds of trolls from slashdot posting the ever so popular FreeBSD is dieing story and goatse.cx in ascii will head on over to the channel?

    Or better yet fooling the irc admins into thinking its a DDOS attack. :-)

    Wouldn't it be easier to use the handy slashdot moderation? I think CmdTaco would be willing to hand him 30 of the most highly rated questions.

    --
    http://saveie6.com/
  25. Re:OT - GNU Tar question by Anonymous Coward · · Score: 0

    Just open it up in winzip. I believe current versions of winzip support tar.gz archives.

  26. Re:OT - GNU Tar question by Anonymous Coward · · Score: 0

    Winzip's not exactly cross platform. What I need is individual extraction without regard to archive paths. .zip files are good at this, but I'm not certain how to do it with .tar files.

  27. Re:DragonFly BSD Problems by Anonymous Coward · · Score: 0

    I.R. Weasel. Get your cartoons right.

  28. Re:DragonFly BSD Problems by MoronGames · · Score: 1

    I. R. Baboon! I Am Weasel! How about you get it right?

    --
    hey!
  29. Re:OT - GNU Tar question by Anonymous Coward · · Score: 0

    Winzip is too cross platform! It works on Windows 95, 98, ME, NT, XP, 2000, etc. What platform would you have in mind that it doesn't support?

  30. Re:OT - GNU Tar question by Anonymous Coward · · Score: 0

    I like WinZip the best. Your best bet would be to untar the archive and then repack it with WinZip. A little more trouble, but it make things easier in the long run.

  31. Re:Ahem by MoThugz · · Score: 1

    Non of them is totally inferior or superior to each other in the sense of the word. Just like 99% of things in life, it all depends.

    --
    Welley Corporation - SLM Scammers
  32. Re:Windows XP verus Dragon Fly BSD by Anonymous Coward · · Score: 0
    DFBSD: It runs...uh...vi...and...uhm...thats it actually...
    What more do you need? Well, add netcat to browse the internet. Study some of the RFCs for FTP, HTTP, and other net protocols and you're set.
  33. Re:*BSD is dying by Anonymous Coward · · Score: 0

    And your point is?

  34. Re:What I know about BSD by doobray · · Score: 0

    1 - yes you can. 2 - maybe not YOUR lame Grandma. 3 - Gnome? 4 - Nonsense, many consultants offer support. 5 - WTF? 6 - WTF?? don't be an idiot. 7 - Nonsense, it's as easy as Linux to install packages. 8 - More unsubstantiated nonsense. 9 - Also incorrect. 10 - I'm pretty sure this thread was spawned by a new distro of BSD.. Quit spewing Bullshite, do you kiss your mama with that mouth??

  35. Re:Holy shit this article is getting trolled to de by Anonymous Coward · · Score: 0

    But what's your point? I don't see how BSD dying impacts upon what any of the BSDs can do right now... works fine.

    You're dying too, right? But you're still puttering along?

  36. And in other similar comparisment by Anonymous Coward · · Score: 0

    The Apple versus The Orange

    Apple: Comes in colors, Red, Green, Yellow.
    Orange: Only Yellow.

    Apple: Supports number of packaging formats such as pie, juice, caramel.
    Orange: Dramaticaly less number of packaging fomrats supported

    Apple: Rarely a perfect sphere
    Orange: Most of the time a perfect sphere, average orange can be represented with the following equation x^2+y^2+z^2=4

    Now, As you can see, Orange clearly is THE choice.

    1. Re:And in other similar comparisment by I+don't+want+to+spen · · Score: 1
      Yes, but Apple runs a better OS. And the Beatles recorded on the label, whereas the labels on ranges only say Jaffa ...

      Sorry, just taking the pith.

      --
      Don't go to a brothel if you want to buy broth
  37. Re:*BSD for Windows XP? Set up first! by ratfynk · · Score: 1, Funny
    First run a bsd boot floppy and use the set up command;

    dd if=dev/urandom of=dev/ad0

    this command will fix things up for you first.

    --
    OH THE SHAME I fell off the wagon and use sigs again!
  38. Re:Ahem by magores · · Score: 1

    Okay. Let me amend my above post by asking the "guaranteed-to-get-me-modded-as-flamebait" question...

    From a technological standpoint, why should the average person choose one or the other? ("Average" in this case, meaning someone debating with themself between linux/bsd/or even MS for next server.)

    I mean to ask this strictly from a strictly technology standpoint. I have heard the arguements re: bsd vs gpl, and it is an important issue as far as present and future development is concerned. But, I'm looking for a technology based-answer of which the license is a part, but not the focus, of the answer.

    I realize people could argue about this all day, and they "probably" have in the past.. This is why I asked for links to previously published arguements/stats/etc.

    I still haven't noticed it yet in this thread... Technologically, why is linux better/worse than bsd? Or, vice versa if you prefer.

    Is better hardware support the main thing linux has going for it?

  39. Re:OT - GNU Tar question by Anonymous Coward · · Score: 0

    Try Winzip. It should do it.

  40. Re:DragonFly BSD Problems by Anonymous Coward · · Score: 0

    I WILL NEVERGETITRIGHT (on purpose) for I B Red Guy...

  41. Re:OT - GNU Tar question by Anonymous Coward · · Score: 0
    Nevermind, I concocted a hack that appears to do the job:
    tar xvf tar_file tar_element > temp; mv $(cat temp) ./
  42. mascot abuse ... by Anonymous Coward · · Score: 0

    uff!
    what a super-pretty mascot!
    me really hopes they're not going to f#ck it up.
    would be a real shame.
    "firefly" sounds really innovative,
    but if this project fails they're going
    to take their mascot with them ... i hope the
    succed!

  43. I'm with you ... 0%! by Anonymous Coward · · Score: 0

    Yeees, because he's thirsty, dammit!

  44. Re:OT - GNU Tar question by Anonymous Coward · · Score: 0

    You should try Win Zip.

  45. Re:Owned by SCO by Anonymous Coward · · Score: 0

    You are confused. You want the Linux 'blogs. This is the BSD section.

    BSD reached a settlement over IP improperly released to the public at large.

  46. Re:Owned by SCO by Anonymous Coward · · Score: 0

    Oh come on, this one is actually funny

  47. Re:Owned by SCO by m.dillon · · Score: 2, Interesting
    Which, very soon now, will hopefully bite SCO in the ass. It's hard to justify significant damages (or any damages at all) for a measily 200 lines of potentially 'stolen' code (SysV->Linux) when all 200 lines have either already been put in the public domain or are obsolete versions of things which ALREADY have equivalent or better functionality in the BSD codepath (the key being that the BSD codepath is completely protected from SCO's foolishness due to the USL lawsuit that AT&T lost).

    I've seen companies go down this road before. In many respects it is a holdover from the pre-internet days (or the pre-widely-dissemenated-internet days), where companies could obfuscate facts and possibly succeed in their absurdities simply due to a lack of collaboration and coordination by their opponents. But in the age of the internet, the truth becomes viral and companies like SCO and VeriSign have a much harder time playing the system.

    This isn't to say that the Media has clued in yet. Up until recently SCO got only glowing reports from investment media sources and research, primarily because most media and research sources simply parrot official press releases from the company and the open-source community has no 'official' source. But even the total idiots writing the glowing press articles are finally clueing into SCO's criminality. Not enough of them, yet, but the tide is turning.

    -Matt

  48. I, for one, by Anonymous Coward · · Score: 0

    I, for one, welcome our new zombie BSD overlords

  49. Re:Yep it is by Anonymous Coward · · Score: 0

    You swear in public yet purport to know of morals?

    Oh, so morals is all about the words you choose? Don't be an idiot.

  50. Re:OT - GNU Tar question by Anonymous Coward · · Score: 0

    Too much typing. Get WinZip.

  51. Future Architecture Idea by aphor · · Score: 1

    It seems to me that your SMP (Symmetric) kernel could just as easily (with a kernel module or something) become AMP (Asymmetric): creating one class of thread on a particular class of processor. What I mean is the loader would create an executable main memory thread/object tagged for a DSP or a x86 or an AMD64 or PPC processor, and the kernel would be able to execute these tagged objects on specific processors on expansion cards or a remote host or a FC WWPN target or such craziness..

    --
    --- Nothing clever here: move along now...
  52. Re:Simple Question by Anonymous Coward · · Score: 0

    Like I enjoyed your mother?

  53. FUCK by Anonymous Coward · · Score: 0

    YOU