Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming Operating Systems BSD IT Technology

Interview with Matthew Dillon of DragonFly BSD 233

Posted by michael 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."
This discussion has been archived. No new comments can be posted.

Interview with Matthew Dillon of DragonFly BSD More

Interview with Matthew Dillon of DragonFly BSD

Comments Filter:

  • I guess that'll show em. (Score:3, Funny)

    by AltGrendel ( 175092 ) <ag-slashdotNO@SPAMexit0.us> on Saturday March 13, 2004 @09:07PM (#8557584) Homepage
    BSD isn't dead.

    • Not by a long shot. (Score:5, Interesting)

      by Tony-A ( 29931 ) on Saturday March 13, 2004 @09:23PM (#8557894)
      "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.

    • Amazing. (Score:5, Funny)

      by xeeno ( 313431 ) on Saturday March 13, 2004 @09:33PM (#8558072) Homepage
      There's actually something on the front page about BSD. And it says nothing about SCO or linux.

    • BSD is faaaaar from dead. I'd say that those who claim BSD to be dead dont know what they are talking about. Ive been using FreeBSD as desktop and server OS for 3 years, while ive never really gotten down and dirty with linux, and i cant say i regret my choice of OS. BSD still lives, and (atleast for me) allways will.
    • There are now four BSDs, yet there is only one Linux. Is there something about BSD that makes it fork-prone, or something about Linux that makes it fork-resistant?

      I'm not critisizing either one. I'm just curious, any thoughts?

      • Re:I guess that'll show em. (Score:1, Interesting)

        by Anonymous Coward
        That's funny. One thing that drives me crazy with linux is how it is always changing.

        Redhat9 binaries won't work with redhat7 and debian does things their own way. While mandrake and gentoo do it this way. Then suse jumps in and blah blah blah.

        Sure they all use the same kernel but usually it is never the same kernel.

      • Re:I guess that'll show em. (Score:5, Interesting)

        by Rick the Red ( 307103 ) <Rick.The.Red@gm a i l . com> on Saturday March 13, 2004 @10:39PM (#8559134) Journal
        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.

        • Re:I guess that'll show em. (Score:5, Interesting)

          by UID500 ( 715267 ) on Sunday March 14, 2004 @01:00AM (#8559664) Homepage
          Um, linux is a kernel, not a distro. the linux kernel is what "linux is supposed to look like" to linus.

          • Re:I guess that'll show em. (Score:5, Insightful)

            by Anonymovs Coward ( 724746 ) on Sunday March 14, 2004 @01:45AM (#8559815)
            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.

            • you can't really drop a generic Linus kernel into any of the commercial distros and expect it to work properly

              Huh???? Generic kernels work just fine. You just need to configure them with the correct options. All RH and others do is take a generic kernel and add some additional patches such as IPSec, updated drivers, etc., but none of those are needed for day to day usage for the most part. These are NOT forks of the linux kernel.

              In fact, it's a very good idea to maintain your own kernel with just the opt
        • 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 p

          • Re:I guess that'll show em. (Score:5, Informative)

            by Rick the Red ( 307103 ) <Rick.The.Red@gm a i l . com> on Sunday March 14, 2004 @02:49AM (#8560000) Journal
            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.

            • Re:I guess that'll show em. (Score:1, Interesting)

              by Anonymous Coward
              " 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!"

              You guys are lucky! We have 5 admins to handle over 300 machines that vary from sparcstation 5's, to V880's, to HP ProLiants, to high-end PA-RISC hardware.

              You better believe we pray that we don't get called when one of the "insert product here" experts goes on vacation. And when I go on vacation, I pray nobody manages to get ahold of me !

              Being seriously understaffed sucks,
            • confusion.

              Isn't the point of a single system to have exactly identical machines? You either mount / over NFS or have an image you blast onto the machines regularly. You absolutely mount /home over NFS, and use local disk only for transient, unbacked up data --- like builds, scratch, swap.

              I think HP was right on the money; allowing your infrastructure to heterogenize is a bad thing.

              Note that you can still have dept-local configurations, as long as they are centrally managed images. The idea is that if any
              • It's not practical to have 100% identical machines most of the time. After a while the original replacement hardware starts getting hard to find, but a lot of the time there's no reason to replace the machine. And if you did replace the machine, everything wouldn't be identical anymore...

                If you're in a company with any significant number of computers, you have literally tons of spare parts lying around. All the machines will drift as they're maintained, and get customized. Someone might need more memory, s

              • You absolutely mount /home over NFS, and use local disk only for transient, unbacked up data --- like builds, scratch, swap.

                Actually, the setup, I'm trying to develop, keeps everyone's home directory on their own desktop -- the machine, they are most likely to use most of the time. It is automounted elsewhere, when needed with automounter's map available through NIS. This gives the speed of local disk, the features of file system, that may not work through NFS, and reduces network traffic.

                On the downsid

    • It sounds an awfully lot like they are planning to build a Mach kernel with message ports and everything.

      Maybe he should fork Darwin instead and then I could run it on my iBook. ;)

  • Different threading model (Score:3, Interesting)

    by Mr. Darl McBride ( 704524 ) on Saturday March 13, 2004 @09:08PM (#8557596)
    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?

    • Re:Different threading model (Score:5, Funny)

      by Anonymous Coward on Saturday March 13, 2004 @09:09PM (#8557621)
      No BSD secrets for you, Darl!

    • Re:Different threading model (Score:5, Informative)

      by Mr. Darl McBride ( 704524 ) on Saturday March 13, 2004 @09:14PM (#8557716)
      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 [dragonflybsd.org].

    • Re:Different threading model (Score:5, Informative)

      by Kaladis Nefarian ( 655671 ) on Saturday March 13, 2004 @09:14PM (#8557722) Homepage
      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 [dragonflybsd.org] for more details on the SMP model, Matt talks about it regularly earlier on.

    • Re:Different threading model (Score:5, Informative)

      by m.dillon ( 147925 ) on Saturday March 13, 2004 @10:30PM (#8559102) Homepage
      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

      • Re:Different threading model (Score:1, Interesting)

        by Anonymous Coward
        The cost of moving a thread between CPUs isn't very much. A bit more than a context switch because when you context switch you might have a bit of your old data left in cache somewhere.

        A big problem is sharing cachelines between CPUs, where one or more of those CPUs writes to that cacheline. This problem is second only to lock serialisation when it comes to SMP scalability.

        The Linux kernel for example may move tasks between CPUs (when the task isn't running, of course). This doesn't in any way prevent the

        • Re:Different threading model (Score:5, Informative)

          by m.dillon ( 147925 ) on Sunday March 14, 2004 @01:20PM (#8562317) Homepage
          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

      • 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?

        • Re:Different threading model (Score:5, Informative)

          by m.dillon ( 147925 ) on Sunday March 14, 2004 @01:10PM (#8562258) Homepage
          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.

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

        • Re:Different threading model (Score:5, Informative)

          by m.dillon ( 147925 ) on Sunday March 14, 2004 @01:23PM (#8562335) Homepage
          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.

  • For a project that gets no press (Score:5, Interesting)

    by RLiegh ( 247921 ) on Saturday March 13, 2004 @09:08PM (#8557603) Homepage Journal
    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.

    • Re:For a project that gets no press (Score:4, Informative)

      by Anonymovs Coward ( 724746 ) on Sunday March 14, 2004 @01:52AM (#8559835)
      They do have ISOs, click the "download" link on their main page [dragonflybsd.org]. 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.
  • Queue the BSD is dead posts.
    Why can't we all just get along??

  • Divide and conquer (Score:4, Funny)

    by florin ( 2243 ) on Saturday March 13, 2004 @09:17PM (#8557781)
    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..

    • Re:Divide and conquer (Score:5, Interesting)

      by Anonymous Coward on Saturday March 13, 2004 @09:25PM (#8557945)
      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.
      • BTW you forgot to mention Solaris, which has it's roots in BSD too.

        SunOS 1-4 were primarily BSD. SunOS 5 is primarily System V, with some 'leftovers' from earlier releases. [My guess would be that the BSD bits were left in primarily for backwards compatibility or because SysV didn't have equivalents.]

        In any case, modern Solaris is much more SysV than BSD.

      • SunOS had its roots in BSD. Solaris has it roots in SVR4. The changeover happened in the '94-'95 time frame.
  • cluster-capable system implementing native SSI (Single System Image) which is something that no other operating system can do today

    umm...unicos/mk?

    • Re:SSI? (Score:5, Informative)

      by Kaladis Nefarian ( 655671 ) on Saturday March 13, 2004 @09:36PM (#8558121) Homepage
      If you read the article, Matt says (about SSI): "It is something that no non-commercial system today can do"...

      • Re:SSI? (Score:4, Funny)

        by funwithBSD ( 245349 ) on Sunday March 14, 2004 @01:56AM (#8559851)
        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.
    • Nope, Unicos/mk runs on the T3D/E machines which are not a cluster. Same for Irix or SUN, their SSI scalability is based on NUMA machines not clusters.

    • Re:SSI? (Score:5, Insightful)

      by Alan Cox ( 27532 ) on Sunday March 14, 2004 @09:25AM (#8560932) Homepage
      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.

  • Michael (Score:3, Interesting)

    by LittleLebowskiUrbanA ( 619114 ) on Saturday March 13, 2004 @09:25PM (#8557946) Homepage Journal
    What w/ the laziness and impatience remarks? Just can't help making a dig at anything not Debian?

    • Re:Michael (Score:2, Informative)

      by Waffle Iron ( 339739 )
      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

  • Something no other OS can do? (Score:5, Informative)

    by fmayhar ( 413222 ) <frank AT exit DOT com> on Saturday March 13, 2004 @09:34PM (#8558095) Homepage

    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 [openssi.org], 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.)

    • It's just Matt aiming high. He doesn't care if he (and others) achieve it, but it would be choice if he would. The ultimate goal would be to achieve such a thing without much hassle, but we do know better. It just gives us something to aim for.
    • . . . 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

    • Re:Something no other OS can do? (Score:1, Funny)

      by Anonymous Coward
      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.

      This looks like much stronger grounds for a lawsuit than anything IBM did. Kiss your UNIX licence good-bye HP!!

      • 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


        • Same with IBM and AIX but somehow it didn't stop SCO claiming that IBM's code couldn't be licensed under the GPL.

          As for OpenSSI, is it an integral part of the Linux kernel?

          If not then it isn't really native given that it is a third party add on to Linux (or we might have a different idea of what native means in this context).

          Same with your Unixware example, if it uses a third party product then it isn't really native.

          Now, is there an OS out there that natively* implements SSI? (not a rethorical question

    • Re:Something no other OS can do? (Score:3, Interesting)

      by Anonymous Coward
      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 someth

  • The Ballad of Matthew Dillon (Score:2, Funny)

    by Anonymous Coward
    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'.

  • Linux has no SSI? (Score:3, Interesting)

    by Anonymous Coward on Saturday March 13, 2004 @09:46PM (#8558353)
    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 [shiningsilence.com](warning, PDF) and the Linux [sourceforge.net] 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

    • Re: SSI? (Score:1, Insightful)

      by Anonymous Coward
      DragonFly is being redesigned at it's core to allow this sort of clustering, whereas Linux's clustering software is tacked on third party cruft. DragonFly will have native clustering capability soon, and it will be at a level equal to that currently in Linux (although built-in).

      The ultimate goal of which Matt speaks will go far beyond even that, and it'll take time. For Linux to do the same thing, they'd basically have to reinvent their kernel as Matt has done with FreeBSD's, and that's not about to happen

    • Re: Linux has no SSI? (Score:2, Interesting)

      by Anonymous Coward
      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.

  • Backplane non-free, non-relational (Score:4, Interesting)

    by leandrod ( 17766 ) <l@@@dutras...org> on Saturday March 13, 2004 @11:05PM (#8559232) Homepage Journal
    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.
    • Backplane has all of the licensing downsides to MySQL; it looks as though they have taken their policies direct from MySQL AB. And where MySQL has been able to get a cycle of "bait and switch" in to hook people on the product before hitting them up with the real license, Backplane has been quite up front about the product being intended as a "we charge you if you use it" one, which will certainly discourage people from donating free effort to it.

      It's an interesting system in that it is really quite dif

      • Backplane has all of the licensing downsides to MySQL

        Well, I don't consider copyleft a downside. But the Backplane license does not seem even to be free.

        >

        The appropriate approach would probably be to implement a Tutorial D language atop PostgreSQL. After all, that's the approach Dataphor takes; it implements D4 atop Oracle or DB/2.

        Actually Dataphor isn't implmented on top of anything. It just uses an SQL DBMS. AFAIK they don't intend yet to have their own, nor integrate into any, DBMS engine;

  • License contradiction? (Score:5, Interesting)

    by XaXXon ( 202882 ) <xaxxon@@@gmail...com> on Sunday March 14, 2004 @12:42AM (#8559609) Homepage
    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..
  • Hei, Dillon

    It seems that you are working in some
    inovative features.

    I hope that in the way, you fill some patents
    about your work (even if you don't agree with
    software patents), because we are going to
    need it in the upcoming patent fight against
    Microsoft.
  • It sounds like he might want to look into Project UDI [project-udi.org]. It's a device driver abstraction that allows source and to some level binary compatible device drivers across platforms with the UDI environment. I did a little work in it, and from a very top level look at his kernel threading model, looks like a good fit with how UDI does things. It's not very well known, and being a Caldera/NewSCO type thing (developed initially way before the current management started the legal stuff) now has political baggage a

Slashdot Top Deals

A CONS is an object which cares. -- Bernie Greenberg.

Close