Slashdot Mirror

← Back to Stories (view on slashdot.org)

Interview with Matthew Dillon of DragonFly BSD

Posted by michael on from the laziness-impatience-and-hubris dept.

JigSaw writes "Well-known FreeBSD/DragonFly/Linux/Amiga system hacker Matthew Dillon discusses a number of interesting points regarding where the BSDs are going, the status and goals of his latest project DragonFly BSD, the status of his innovative Backplane distributed database, his exciting plans to develop DragonFly into a transparently cluster-capable system implementing native SSI (Single System Image) which is something that no other operating system can do today, and more."

53 of 233 comments (clear)

  1. I guess that'll show em. by AltGrendel · · Score: 3, Funny

    BSD isn't dead.

    --
    The simple truth is that interstellar distances will not fit into the human imagination

    - Douglas Adams

    1. Re:I guess that'll show em. by ScrewMaster · · Score: 4, Funny

      This is Slashdot, where any sufficiently advanced opinion is indistinguishable from fact.

      --
      The higher the technology, the sharper that two-edged sword.
    2. Re:I guess that'll show em. by Rick+the+Red · · Score: 5, Interesting

      I think of the various Linux distros as "forks" of whatever Linus himself runs. There are literally dozens of Linux forks. Too bad Linus doesn't release a distro, so we'd know what Linux is supposed to look like. If you sit down at a Linux system you have no idea what you're going to find. From a Systems Administration standpoint alone that makes *BSD a better choice for corporations with a large number of hosts, but Linux gets all the press.

      --
      If all this should have a reason, we would be the last to know.
    3. Re:I guess that'll show em. by SillyNickName4me · · Score: 4, Insightful

      Hmm.. yeah, since a recent update I can no longer run a.out binaries from the 2.x era... but for as far as external packages and ports are concerned, thats about the first case where you can't get software for older releases to work with a current version using one of the compatxx packages.

      That said, some tools (esp those using kmem) should be kept in sync with the kernel, and when at it, why not just build a new userland, its easier then figuring out what you have to update.

      The concurrently developing BSD variatiens allow trying out a variety of low level solutions to problems while sharing a lot of their experiences.

      Such diversity doesn't really exist in Linux despite its zillion distributions (which provide a lot of variation in user experience tho)

    4. Re:I guess that'll show em. by UID500 · · Score: 5, Interesting

      Um, linux is a kernel, not a distro. the linux kernel is what "linux is supposed to look like" to linus.

      --
      FreeBSD Addicts
    5. Re:I guess that'll show em. by Anonymovs+Coward · · Score: 5, Insightful
      Um, linux is a kernel, not a distro.

      Which is unfortunate in many ways. For example, Matt has introduced variant symlinks into DragonFly, and has major plans involving vfs namespaces etc which will really solve a lot of problems in package management, like allowing two different conflicting versions of a package to exist at the same time. He can do all this because he's looking at the whole picture, and so are the others: the entire source tree for the base system is there on my machine, in one nicely-arranged subdirectory. I don't foresee major changes happening in the linux kernel driven by distributors. To this day, breakages with binary-incompatible glibc etc are constant annoyances with linux unless you choose a stable distributed version from a branded linux distro and stick to it. the linux kernel is what "linux is supposed to look like" to linus.

      What is "the linux kernel"? There's a Red Hat kernel, a Mandrake kernel, a SuSE kernel, and you can't really drop a generic Linus kernel into any of the commercial distros and expect it to work properly. (Debian and Gentoo are better.)

      I'm not dissing linux, it's better than the mainstream alternatives and has far better hardware support and graphical system administration tools than the BSDs. In fact after 2 years with FreeBSD I myself had switched to Linux on my new machine because of hardware issues (I've now mostly switched to DragonFly and the hardware issues are mostly gone). And I use Linux at work and have no desire to change that. But there are reasons why a lot of technically aware people find the BSDs nicer systems to play with.

    6. Re:I guess that'll show em. by 4b696e67 · · Score: 2, Interesting

      Too bad Linus doesn't release a distro, so we'd know what Linux is supposed to look like.

      If I'm not mistaken Linus has said he won't endorse or release a distro for that reason alone. Friendly competition between the distros is a good thing. It sparks invention and true innovation. Even the various *BSDs help each other out.

      If you sit down at a Linux system you have no idea what you're going to find.

      I disagree there. Most *nixes are fairly similar. You have a /dev directory. You have an init process. You have standard utilities such as ls, cp, grep, sed, awk, etc. I have used AIX, Solaris, FreeBSD, and Linux and they do have their differences, but they are more alike than different.

      From a Systems Administration standpoint alone that makes *BSD a better choice for corporations with a large number of hosts, but Linux gets all the press.

      I disagree there as well. I feel that from an administration standpoint with a large number of hosts it wouldn't matter if you were using RedHat, Gentoo, FreeBSD, OpenBSD, or any other *nix for that matter as long as the machines you were running were using the same distro. No, you wouldn't want 10 RedHat boxes, 20 OpenBSD boxes, 35 Gentoo boxes, and 15 AIX boxes. On the other hand, if you had 80 Gentoo boxes that were all kept up to date you wouldn't be any worse off than if you had 80 FreeBSD boxes (generally speaking, I know each OS has its strengths and weaknesses).

      IMO the best OS to administer is the OS you know. You could have the best/most secure OS ever, but you would still get owned if you didn't know how to administer it. Hell, even the "security hole haven" Windows can be made more or less secure by a good admin.

    7. Re:I guess that'll show em. by anthonyrcalgary · · Score: 3, Insightful

      As I'm sure we're all aware, market share is not necessarily indicitive of quality or suitability for a given purpose. Just think about what that would say about Windows if it were true.

      --
      When someone might yell at me, it has to be OpenBSD.
    8. Re:I guess that'll show em. by Anonymovs+Coward · · Score: 4, Insightful
      Linux really has very few problems with userspace backward compatibility. What did you have in mind?

      Merely my brief experience with Gentoo, when they first upgraded glibc (from 2.2 to 2.3 iirc) and broke half the packages, then downgraded it again and broke everything else. This is really a pet peeve: aren't minor versions supposed to be compatible? And a zillion similar but smaller-scale annoyances, well expressed by Bill Paul many years ago and the years haven't eased the pain all that much.

      And BSDs are more likely to introduce binary incompatibilities

      Clearly you haven't used the BSDs. You may have library incompatibilities between major versions, but just install the earlier "compat libraries" and you're set. I upgraded from FreeBSD 4 to FreeBSD 5 -- a huge upgrade, over 2 years in the making -- and all my software just worked, even complex stuff like KDE and Mozilla that had been compiled under 4.x.

    9. Re:I guess that'll show em. by Rick+the+Red · · Score: 4, Informative
      I feel that from an administration standpoint with a large number of hosts it wouldn't matter if you were using RedHat, Gentoo, FreeBSD, OpenBSD, or any other *nix for that matter as long as the machines you were running were using the same distro.
      You haven't actually been an admin at a company with a large number of machines, have you? I worked for a large aerospace company and our Management (he wasn't even a PHB) wanted to know why we had an average of one admin for 20 machines when HP said one admin should be able to handle 200. Then HP explained that those 200 machines were absolutely identical -- same exact hardware, same exact OS patch level, and same exact applications. In the Real World, we had no two machines alike and thus needed the 1/20 ratio. And this was all the same brand of hardware and OS! Each department was different, which basically made vacation and illness backups a matter of "pray they don't call you." The admins who had the easiest time of it were those who worked on BSD boxes; the VR4 boxes were all over the map; even the users understood that if their admin was away, they were better off not bothering the backup on call for any more than password resets because they'd as likely break something else as fix your problem.

      Granted, if you ran an all RedHat shop or an all Mandrake shop things would be easier than simply an all Linux shop, but the same would be true for an all OpenBSD shop vs an all FreeBSD or NetBSD shop. But if each department is free to buy what they want I'd rather find who-knows-which-BSD on the box than who-knows-which-Linux.

      --
      If all this should have a reason, we would be the last to know.
    10. Re:I guess that'll show em. by yanestra · · Score: 3, Informative
      Merely my brief experience with Gentoo, when they first upgraded glibc (from 2.2 to 2.3 iirc) and broke half the packages, then downgraded it again and broke everything else. This is really a pet peeve: aren't minor versions supposed to be compatible?
      There's a big difference between binary executable and logical compatibility. You have compiled several files with newer libraries and then downgraded. You expected that the newly compiled programs to run with old libraries - which they in fact do, as long as there has no special feature of the newer libraries been used - inherently.

      If you are unhappy with your executables be broken, simply keep a copy of the older libraries. (With Gentoo, simply delete the old package file in /var/db/pkg before updating.)

  2. Different threading model by Mr.+Darl+McBride · · Score: 3, Interesting

    It looks like the gist of the threading model for Dragonfly is that threads all stay on one processor. I assume this is for user processes only, and that this isn't pervasive through the kernel?

    1. Re:Different threading model by Anonymous Coward · · Score: 5, Funny

      No BSD secrets for you, Darl!

    2. Re:Different threading model by Mr.+Darl+McBride · · Score: 5, Informative
      It looks like the gist of the threading model for Dragonfly is that threads all stay on one processor. I assume this is for user processes only, and that this isn't pervasive through the kernel?
      Nevermind, found an overview here.
    3. Re:Different threading model by Kaladis+Nefarian · · Score: 5, Informative

      No this is to do with kernel threads. The userland threading is the same as in FreeBSD 4.x atm, AFAIK. The idea is to keep the model simple, unlike in FreeBSD 5.x where they are having trouble keeping it all sane with their fine-grained mutex model. Have a look at the dragonfly.kernel newsgroup, in nntp.dragonflybsd.org for more details on the SMP model, Matt talks about it regularly earlier on.

      --
      * Several monkeys are here, playing banjos and wearing small hats.
    4. Re:Different threading model by Mr.+Darl+McBride · · Score: 5, Funny
      No BSD secrets for you, Darl!
      It is important that I discover what they have created so that I may license it back to them.

      ~Darl

    5. Re:Different threading model by m.dillon · · Score: 5, Informative
      Not exactly. All this means is that threads do not migrate preemptively, nor do they migrate while blocked or switched out while in kernel mode. Threads only migrate if (a) the thread itself wants to move to another cpu or (b) the thread is returning to user mode and the userland scheduler decides to migrate the thread to balance the load out (which only applies to threads associated with user processes since no other type of thread can 'return to usermode').

      Kernel threads almost universally stay on the cpu they were originally assigned to. High performance threaded subsystems, such as the network stack, are replicated. That is, the network stack creates multiple threads (one per cpu) and those threads do not migrate because, obviously, they do not need to.

      Generally speaking, the purpose of making thread migration explicit instead of automatic is to partition a larger data set across available cpu caches rather then cause the same data to be shared amoungst all cpu caches. The processors operate a lot more efficiently and SMP scales a lot better. Most people do not realize the horrendous cost of moving threads between cpus because the cache mastership change is invisibly handled by hardware, but the cost is still there and still very real.

      -Matt

    6. Re:Different threading model by Mr.+Darl+McBride · · Score: 2, Insightful
      At what level does this model give way to standard mutexes? You can't have four drivers for your network card on a four CPU system or four drivers driving your ATAPI bus.

      Do you do anything special in the mutex code to take advantage of the four async top level threads and prevent mutex waits?

    7. Re:Different threading model by Mr.+Darl+McBride · · Score: 2, Insightful

      I should also ask -- is this thread replication model your own design, or do you know of any papers or previous implementations?

    8. Re:Different threading model by m.dillon · · Score: 4, Informative
      The system core is lockless... there are no mutexes. For example, the LWKT scheduler core operates entirely without mutexes. Only critical sections are used to protect against local interrupts. A critical section is per-cpu, and really only needs to increment and decrement a per-cpu variable. As such the crit_enter()/crit_exit() code does not need to use any locked bus-cycle instructions or anything fancy at all, really.

      The LWKT scheduler on any given cpu is only allowed to operate on threads owned by that cpu. If you attempt to wakeup a thread owned by a different cpu, an asynchronous IPI message is sent to the target cpu's LWKT subsystem requesting that the specified thread be woken up. It's really that simple. Same goes for cross-cpu scheduling.

      IPI messages themselves are lockless and require no mutexes to operate because the cpucpu messaging uses a software crossbar (array of FIFOs) approach.

    9. Re:Different threading model by m.dillon · · Score: 4, Informative
      No, the critical section code simply increments and decrements a per-cpu variable. No locking is required at all... critical sections are local to the cpu, not global to the system.

      In regards to cache issues, lets say you have a quad opteron system. Each cpu has a 1MB L2 cache. If you migrate threads willy nilly you basically wind up in a situation where each of the four cpu's L2 caches contain the same data. In effect, you wind up with a system that globally has only a tad more then 1MB of L2 cache. If you partition data (such as TCP protocol data) across distinct threads, and place those threads on different cpus, then you are in effect partioning your system's memory across all four cpu caches and you wind up with a system that globally has 3-4MB of L2 cache instead of 1-2MB.

      There are two costs being saved here. (1) the cost of having to go to main memory when a piece of data is not in the L1/L2 cache, which can run into the hundreds of cpu cycles, and (2) the cost of cache mastership changes for all the data associated with the thread that was migrated (repeated each time the thread migrates).

      -Matt

    10. Re:Different threading model by m.dillon · · Score: 4, Informative

      I don't think it's anyone's design in particular, but I tend to sit down and write things from scratch rather then copy other people's ideas. In the case of the thread replication used by the network stack, it is primarily Jeffrey Hsu's work and since he is big on reading papers I'm sure it's a combination of his own design and ideas gleaned from various published papers.

    11. Re:Different threading model by m.dillon · · Score: 2, Informative
      It's an advantage in concept. The serializing token abstraction is a far easier model to program to because the semantics are totally different then mutexes. For example, when you obtain multiple mutexes you have to be very careful about lock ordering issues, and when you have one major subsystem holding a mutex call another major subsystem that might block, you have to (in FreeBSD-5) make the second subsystem aware of the first subsystem's mutexes, creating major code pollution all over the place.

      The serializing tokens used by DragonFly work differently. They only guarentee serialization while the thread holding the token is actually running. Other threads holding the same token will be allowed to run when the first thread blocks or switches away synchronously, and the original thread will not get the cpu back until the tokens it is holding are available again.

      This means that threads can obtain tokens in any order they wish, and that threads can hold tokens across blocking situations or calls to other subsystems without having to tell those subsystems about it. It may seem like a small thing, but the result is a huge simplification of the programming model. The tokens act almost like mini-BGL's (Big Giant Locks) but have the added advantage of protecting against interrupt threads trying to hold the same token. We are planning to expand the token idea further into a shared/exclusive model. The shared/exclusive model would have characteristics very similar to RCU.

      The actual internal implementation of our token code is also quite a bit more flexible, allowing us to rip the guts out and rework it as needed for performance without changing the abstraction.

      -Matt

  3. For a project that gets no press by RLiegh · · Score: 5, Interesting

    Dragonfly BSD seems to be chugging along quite nicely.

    The further away they get from their 4.x FreeBSD roots, though, the more I wish they'd release an ISO. Particularly since the last ISOs for the 4 series of FreeBSD are probably going to be totally gone in a few months.

    1. Re:For a project that gets no press by Anonymovs+Coward · · Score: 3, Informative

      They do have ISOs, click the "download" link on their main page. The ISO is a liveCD, so you can boot your computer with it, like knoppix (no X or GUI stuff though). What they don't have is a friendly installer. But the /README file has detailed instructions on installing it to the hard disk, which should be easy if you have BSD experience, or if you're a brave newbie you can try it anyway.

  4. Re:What?! by RLiegh · · Score: 3, Funny

    It's official. ftp.FreeBSD.org/pub/FreeBSD/iso confirms it. FreeBSD 4.x is dying. kreskin... usenet... falling dead last in the number of ISO's distributed on ftp.freebsd.org ....all practical purposes...stephen king is dead.

  5. Divide and conquer by florin · · Score: 4, Funny

    Yeah yeah forking is always sweet and this sure sounds like a lot of fun already, but what I'm really waiting for is for someone to put together a BSD-from-scratch distribution! I mean, I know I could just build one with Linux.. BUT only having a single kernel to choose means my grimy little subculture won't be as obscure as it could be. Just think how exclusive I'd be if I could pick one of the NetBSD, OpenBSD, either of the active branches of FreeBSD, and PicoBSD, Dragonfly BSD or Darwin kernels..

    1. Re:Divide and conquer by Anonymous Coward · · Score: 5, Interesting

      There is no need for BSD-from-scratch disto.

      1: All the BSDs are entirely different operating systems, which are lumped into one category becuase of their roots.
      2: Since no extra bullshit is thrown in like linux, there is less need for reworking the base.
      3: BSD is not obscure in the least, it is rather alive and florishing.

      BTW you forgot to mention Solaris, which has it's roots in BSD too.

    2. Re:Divide and conquer by Rick+the+Red · · Score: 2, Insightful

      GNU/HURD is begging, alright. Begging for developers, begging for users, begging to be noticed. Does anyone actually use it? Even these guys don't.

      --
      If all this should have a reason, we would be the last to know.
    3. Re:Divide and conquer by Anonymovs+Coward · · Score: 4, Informative
      From that interview, it sounds like DragonFly is going to have a different package management system in the future. Which means either the base is going to change,

      The BSD base isn't packaged. BSD types like having a source tree for their entire base system and being able to do "make buildworld" and "make installworld" to upgrade it. The package management system is entirely for third party applications. This is not Debian or Gentoo who have no code maintained by themselves other than installation and package management stuff. The BSDs maintain the kernel, the libc, other key libraries, and all the base utilities like ls, cp, mount, etc. And there's also a lot of "contrib" software in the base system -- some of it necessary to build the system (gcc and binutils), some of it just there out of tradition or regarded as "too useful to be moved to ports" (bind, sendmail).

    4. Re:Divide and conquer by Rick+the+Red · · Score: 2, Funny
      Attention Moderators:

      If my post was "Flamebait" then answer my question: Who actually uses GNU/HURD? The GNU guys don't even use it! That's a statement of fact, not a flame. I certainly don't expect them to use anything that's not released under the GPL, so their use of Linux is no real surprise, but given Stallman's history with the whole "Linux" vs "GNU/Linux" thing I'm assuming he'd use GNU/HURD if it was any good.

      --
      If all this should have a reason, we would be the last to know.
    5. Re:Divide and conquer by Anonymous Coward · · Score: 4, Insightful

      Oh well you know, just all sorts of functionality that was driven by Linux, like finely grained SMP, support for enterprise level hardware, USB, SANE, ACPI, DRI/DRM and what have you more. And let's not get started on the apps. I mean, there's a reason why all the BSDs make an effort to run Linux binaries, not the other way around.

      hold on cowboy...
      linux drove usb support? check your history...

      linux has better support for smp? right... 'cos the linux smp support isn't a rip of free-bsd's first smp incarnation, and free's 'new' smp code is some hack up by a big school kid is it?

      linux has better support for enterprise hardware? shall we start with... i dunno... scsi support... get your history book out and do some experimenting with old linux v's old *bsd installs - try backing up a raid and restoring, then come back and tell me how good scsi isn't fundamental enterprise computing...

      next you'll tell me that open's code auditing and goal of bug-free secure code is inferior to linux's free for all crap-code fest

      excuse my rant, i'd don't mean to bag linux - every OS has its place - even windows.

      but man... linux zealots and their damn superiority complex, re-writing history... i even heard someone try to explain the sco crap the other day... he actually said that 'unix is a brand of linux'

  6. Not by a long shot. by Tony-A · · Score: 5, Interesting

    "The reason for this excitement is that it is becoming clear to us that we can develop very clean-looking, elegant, debuggable, SMP scaleable software using this model whereas using the mutex model generally results in much less elegant (even ugly), difficult-to-debug code. Code complexity and code quality is a very important issue in any large piece of software and we believe we have hit on a model that directly addresses the issue in an SMP environment without compromising performance."

    I don't really know what he's talking about, but:
    If he's right, everybody wins.
    Even if he's wrong and we find out why, everybody wins.
    It sounds like Linux isn't hurting BSD any, and methinks for a number of reasons, Linux wouldn't be what it is today without the BSD's.

  7. Michael by LittleLebowskiUrbanA · · Score: 2, Interesting

    What w/ the laziness and impatience remarks? Just can't help making a dig at anything not Debian?

    --
    This guy is way out there
    1. Re:Michael by Waffle+Iron · · Score: 2, Informative
      I think it was intended to be a complement, as in:

      "The three chief virtues of a programmer are: Laziness, Impatience and Hubris." -- Larry Wall

  8. Amazing. by xeeno · · Score: 5, Funny

    There's actually something on the front page about BSD. And it says nothing about SCO or linux.

  9. Something no other OS can do? by fmayhar · · Score: 5, Informative

    It's simply not true that "a transparently cluster-capable system implementing native SSI" is "something that no other operating system can do today." We were doing it at Locus in 1994 with SVR4 then with Tandem in 1996 with NonStop Clusters for Unixware. Now some of the same folks at HP have introduced OpenSSI, which is essentially the same code, less all the Unixware-related bits, ported to Linux and placed under the GPL. They are coming up hard on their 1.0 release, which is not bad for five people and such a large task.

    OpenSSI is the real thing, it has processes that migrate from node to node, distributed file systems, the works. And it's running now on clusters literally all over the world. (Not many clusters, true, but maybe that will change if the Slashdot crowd finds out about it.)

    I'm happy to say that there's a lot of my code in that system, as well.

    I know a little about what Matt wants to do with his SSI in Dragonfly, but he should certainly take a look at OpenSSI; we had to solve a lot of the problems you run into when you build such a beast.

    (And a beast it is. As complex as a kernel can be, when you have what is essentially a distributed kernel across several nodes, the complexity goes up by orders of magnitude. Makes tracking down those weird hangs pretty exciting, in a painful, time-consuming kind of way.)

    1. Re:Something no other OS can do? by fmayhar · · Score: 3, Interesting

      Not so much, no. The bits that were ported were never tainted and the bits that were tainted weren't ported. Because of the way we did our development, what belonged to us was never mixed with what was merely licensed. So when I said "strip out all the bits related to Unixware" I meant precisely that. Not "strip out all the Unixware bits" but strip out all the stuff in the locally-developed code that was Unixware-specific.

      Of course, I was only there for the very beginning of the port; by the time the code was placed under the GPL I had been at BSDi for a while.

    2. Re:Something no other OS can do? by Anonymous Coward · · Score: 3, Interesting
      It's simply not true that "a transparently cluster-capable system implementing native SSI" is "something that no other operating system can do today."

      He didn't say that, here's the paragraph from the interview (emphasis mine)..

      Well I strongly believe that any project needs to have an unattainable goal, and our unattainable goal (which I hope actually winds up being attainable) is to develop DragonFly into a transparently cluster-capable system implementing native SSI (Single System Image). It is something that no non-commercial system today can do (the type of clustering Linux supports isn't even close to the type of clustering that we have as our goal, and clustering has never been one of the other BSD's goals as far as I can tell).
  10. Re:Here we go again by buffer-overflowed · · Score: 3, Funny

    Because BSD users have a mascot called "Beastie" who is a devilish little chap and they use "daemons" to accomplish things that seem like magic to normal people.

    So, you see, it's obvious... BSD made a deal with the devil! And it's users weigh the same as ducks, therefor they are made of wood, and since they're made of wood, they are witches!

    I mean, didn't you ever wonder why we call them "holy wars"?

    --
    The key to the enjoyment of pop music is to replace any instance of "love" with "C.H.U.D."
  11. Re:SSI? by Kaladis+Nefarian · · Score: 5, Informative

    If you read the article, Matt says (about SSI): "It is something that no non-commercial system today can do"...

    --
    * Several monkeys are here, playing banjos and wearing small hats.
  12. The Ballad of Matthew Dillon by Anonymous Coward · · Score: 2, Funny

    The once was a fellow named Dillon
    Whose Dragonfly project was illin'.
    He found, to his dread,
    His *BSD dead
    And Linux was doin' the killin'.

    1. Re:The Ballad of Matthew Dillon by kfg · · Score: 5, Funny

      There once was a Master of Screws
      Who thought it most wonderful news
      That the AC's post
      was more funny than most
      But not all mods agreed with his views.

      KFG

    2. Re:The Ballad of Matthew Dillon by VValdo · · Score: 4, Funny

      There once was a fellow named Dillon
      Whom everyone thought was a villain,
      He cried, "That's not me!"
      "I use BSD!"
      "Because I find it fulfillin'."

      W

      --
      -------------------
      This is my SIG. There are many like it, but this one is mine.
  13. Linux has no SSI? by Anonymous Coward · · Score: 3, Interesting

    Funny, the Slashdot blurb accuses him of saying that no other system today does SSI, while according to the article he simply said their (future, potential) SSI plans will beat Linux's (present, working) SSI clustering.

    Anybody have thoughts comparing the DragonFly SSI(warning, PDF) and the Linux one?
    (Open)Mosix has had craploads of work done on it, and by the time DragonFly's is done, it will be even further ahead. I somehow doubt DragonFly's will end up being better.

    PK

    1. Re: Linux has no SSI? by Anonymous Coward · · Score: 2, Interesting

      I believe that Matt meant out of the box for one, and native for another. "Linux's" SSI is a third party package that is not exactly seamlessly integrated into the kernel, nor does it seem like it will be any time soon. Such would take the kinds of fundamental kernel alterations that are going into DragonFly, and I seriously doubt that Linus is up for that at the moment.

  14. Re:So I looked at OpenSSI's website. .. by Bastian · · Score: 2, Interesting

    . . . and read their brief overview at the top of the page.

    And it almost made no sense to me. Those buzzwords work great one at a time, but the brain starts to make a noise kind of like the one the TV makes after the TV channel goes off the air when you string too many together at once. Especially when nothing but commas separates them.

    Did anyone at HP's marketing department take an courses in English at college? Or were they just as non-clueful about what OpenSSI is when they wrote that blurb as I was when I first went to their website?

    Someone should tell them Kant already has a patent on writing paragraphs that take as long to read as pages.

  15. Backplane non-free, non-relational by leandrod · · Score: 3, Interesting

    This SSI stuff sounds interesting, but I'd like to see his stuff compared to OpenSSI. Now the Backplane SQL DBMS seems interesting, but... First, they make the common mistake of calling SQL relational. This in itself will prevent them becoming significantly better at the logic level, which is a pity. Second, it looks very interesting as far as the backend goes. But the question here as always is, why create something from scratch? Couldn't, say, PostgreSQL, which was born on BSD anyway, be retrofitted with their stuff? Won't Oracle or IBM leapfrog them if they prove successuful? Third, looks like we have yet another BitKeeper in the making... gratis for free software, but not free itself. Makes me want to stick with PostgreSQL for now. If I wanted something proprietary, I'd go Alphora Dataphor, which at least is fully relational and not yet another SQL.

    --
    Leandro Guimarães Faria Corcete DUTRA
    DA, DBA, SysAdmin, Data Modeller
    GNU Project, Debian GNU/Lin
  16. License contradiction? by XaXXon · · Score: 4, Interesting

    If your application is licensed under the GPL or compatible OSI license (learn more at opensource.org) approved by Backplane, Inc., you are free and welcome to ship the Backplane open source database with your application.

    followed by:

    If you power an application using the Backplane database that you market or sell, or use that application to conduct any form of online commerce (selling/buying products or services over a website) you need to purchase the Backplane Commercial License.

    The example given is if you run an email service from which you sell access to other companies, you must buy the commerical license.

    My question is, what if the program that provides the email service is GPL. Do I have to buy a commercial license or not? One of the great things about GPL software is that if it's an internal piece of software, you can mix proprietary and GPL code as much as you want, as long as you never redistribute the program to anyone.

    Also, how does dual licensing work with this? Can I license it under the GPL to myself, and then sell copies under another license to other people? Obviously THEY would have to buy a commercial license, but do I?

    Just trying to point out some holes in the licensing..

    Oops, just noticed the part at the end saying:
    NOTE: In any of these examples, if the entire application or service is 100% GPL compatible, you may use the Backplane Free License.

    But that still leaves open the question about dual licensing..

  17. Re:Here we go again by Ashish+Kulkarni · · Score: 3, Funny

    heh, you might want to take a look at this joke. ;-)

  18. Re:SSI? by funwithBSD · · Score: 3, Funny

    Yeah, rules out OpenVMS too...

    I am always amazed at the rockin' shit OpenVMS can do... just about everything that DragonFly is suggesting... plus the fact that a hacker that got in would likely just say WTF? and log out.

    --
    Never answer an anonymous letter. - Yogi Berra
  19. Re: SSI? by molnarcs · · Score: 3, Insightful
    I don't think the parent post warrants such an outburst. You obviously need to see a doctor. Yes, now and then the items on your list (BSD is cleaner, more organized, etc..) do come up, but then, what the hell does operarc and mplayer.conf do in /etc??? (sorry, I couldn't resist :-P)

    You need to take a break IMHO.
    Jesus fucking christ give it a fucking rest already please? Just go about your BSD stuff and be happy. Just constantly rubbishing Linux at every opportunity just makes you look like an imbicile with Linux envy.
    It seem it is you who has some sort of imbecile rage against BSD, as if it killed one of your relatives or something. Saying things like 'this will be better than what linux has or will probably have' shouldn't throw you in such a fit. Look. Matt might be up to something. He might succeed. He might not. Either way,(even linux) developers might/will learn something from this 'experiment'. Can't hurt, right?

    Now go, fetch that valium before you have stroke.

    ps: (modded as insightful? - come on ...)

  20. Re:SSI? by Alan+Cox · · Score: 4, Insightful

    And to a great extent also things like MOSIX, which go back to V7 unix as well as Linux. Also for that matter OpenSSI (openssi.org)

    The commercial world is full of SSI systems although its never been clear if transparent SSI is the right answer to any problem except "I need it to work now", because coding good apps for SSI setups is hard.

    Dragonfly looks a good project, and looks like it has old BSD folks who actually knew what they were doing working on it.