Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Open Source BSD

OpenBSD Fork Bitrig Announced 178

Posted by Unknown Lamer from the netcraft-confirms-netbsd-developers-arming-for-war dept.
With the goal of bringing more experimental development to the OpenBSD code base, a few developers have announced a fork named Bitrig. According to their FAQ, Bitrig aims to build a small system targeting only modern hardware and "be a very commercially friendly code base by using non-viral licenses where possible." Their first step toward that goal was removing GCC in favor of LLVM/Clang. The project roadmap shows their future goals as adding FUSE support, improving multiprocessing, porting the system to ARM, and replacing the GNU C++ library with LLVM's.
This discussion has been archived. No new comments can be posted.

OpenBSD Fork Bitrig Announced More

OpenBSD Fork Bitrig Announced

Comments Filter:

  • wtf is a bitrig? (Score:3, Funny)

    by noh8rz3 ( 2593935 ) on Wednesday June 13, 2012 @12:31PM (#40311521)

    sounds like a place to keep my bitcoins...

  • Bitrig will only target actively developing hardware and architectures such as i386 and amd64

    How the fsck is i386 actively developing?

    • Bitrig will only target (actively developing hardware) and (architectures such as i386 and amd64)

      Does that help you parse it?

      • Re: (Score:2)

        by mcgrew ( 92797 ) *

        Double woiosh to you, sir. It wasn't a parsing problem, he was pointing out an incredible stupidity. Look at the number -- I haven't seen an i386 [wikipedia.org] since the early nineties.

    • Re:i386 (Score:5, Informative)

      by gman003 ( 1693318 ) on Wednesday June 13, 2012 @01:45PM (#40312527)

      "i386" is OpenBSD-speak for the architecture variously known as "x86", "x86-32", "i686", "IA-32", and "32-bit Intel". Just as "amd64" is OpenBSD-speak for the architecture known to others as "x64", "x86-64", "IA-32e", "64-bit Intel", "Intel 64", and whatever VIA calls it.

      • I did parse "i386" as "32-bit x86, including i686". I haven't seen too much development on that in recent years -- can you even buy such a machine any more?

    • Re:i386 (Score:5, Informative)

      by AlphaWolf_HK ( 692722 ) on Wednesday June 13, 2012 @05:59PM (#40315997)

      As others have said, though I'll add a bit more depth, is that i386 is the catch all for anything x86, with the exception of ensuring that it distinguishes from the 286 and below. The 386 was a major step up from the 286 and below due not only to being 32-bit, but also allowing protected mode and virtual mode operations, in addition to paging.

      Virtually no modern software is adaptable to a 286 processor, whereas nearly all of them are adaptable to a 386, hence the common usage of "i386". As a matter of fact, intel actually didn't stop producing the 386 until around 2007. It was still widely used for embedded applications long after it was already obsolete.

  • I wish them luck. (Score:5, Interesting)

    by Anonymous Coward on Wednesday June 13, 2012 @12:58PM (#40311931)

    This is a good "Put up or shut up" moment for BSD. For all the whining I hear about "Viral" and "Anti Business" licenses the various *BSD projects sure do have a meager adoption (Buisness, home, free or otherwise) compared to their GPL counterparts (Linux). I think an aggressive, forward looking BSD project would be great to have.

    Granted, not all the most popular open source projects have "Viral" licenses (Eg - Most Apache foundation projects), but maybe.. Just maybe Linux's success is in part due to the GPL.

    Some people feel the GPL is stealing something that they're somehow entitled too. In reality, it's more of an exchange. You give up the ability to have a certain business model, and in return you get the collective work of everyone else who's made the same agreement. You give up exclusive control of your source in return for a world-class, flexible, free, operating system with widespread uses. For free. With a BSD style license you're able to opt out of that "collective work" provision. You can take, but you don't have to give. As a result, the project does not grow.

    It's probably in your long-term interest for the project to grow. I think the success of Linux proves this.

    • Re: (Score:2)

      by Ichijo ( 607641 )

      For all the whining I hear about "Viral" and "Anti Business" licenses the various *BSD projects sure do have a meager adoption (Buisness, home, free or otherwise) compared to their GPL counterparts (Linux).

      Actually, OSX (Darwin BSD [wikipedia.org]) is nearly twice as popular as Linux (9.0% vs. 4.9% [w3schools.com]).

      • Actually, OSX (Darwin BSD) is nearly twice as popular as Linux

        Actually, no it isn't. Unless you're restricting yourself away from servers and embedded devices. But why would you do that? This isn't a thread specifically about desktop operating systems.

    • Um, you really don't have a clue, do you?

    • This is a good "Put up or shut up" moment for BSD. For all the whining I hear about "Viral" and "Anti Business" licenses the various *BSD projects sure do have a meager adoption (Buisness, home, free or otherwise) compared to their GPL counterparts (Linux). I think an aggressive, forward looking BSD project would be great to have.

      Granted, not all the most popular open source projects have "Viral" licenses (Eg - Most Apache foundation projects), but maybe.. Just maybe Linux's success is in part due to the GPL.

      Some people feel the GPL is stealing something that they're somehow entitled too. In reality, it's more of an exchange. You give up the ability to have a certain business model, and in return you get the collective work of everyone else who's made the same agreement. You give up exclusive control of your source in return for a world-class, flexible, free, operating system with widespread uses. For free. With a BSD style license you're able to opt out of that "collective work" provision. You can take, but you don't have to give. As a result, the project does not grow.

      This is based on assumptions that don't hold water.

      In particular, the primary assumption is that a significant fraction of contributions to GPLed projects come from companies that are forced to give these contributions, and that would not give these contributions if they could avoid it (as in BSD).

      My impression (from having participated in BSD development and followed Linux development) is that contributions in this area is actually a larger fraction of development on the BSD side of the fence: Embedded sys

  • Why not starting with FreeBSD? (Score:3, Insightful)

    by Conley Index ( 957833 ) on Wednesday June 13, 2012 @01:07PM (#40312051)

    Most points of their agenda are common with FreeBSD and some are already done there or actively been worked on. No one would stand in their way porting WAPBL from NetBSD (if done decently). Ok, stripping the base is (fortunatelly) not on the FreeBSD agenda, but making most of it optional for embedded needs is.

    From their FAQ, "OpenBSD [...] has some of the best code around". Ok, but I still do not buy it. If they want to leave some of the conservatism that comes with the security focus of OpenBSD behind (from the article), I do not find a real reason why they started with OpenBSD.

    Not that some more good, modern code with any of the BSD would be wrong...

    • It would have been good for them to take their project and changes back to NetBSD, which might have been happy to use the improvements. As it is, there are a lot of legacy servers not based on x86 that could use this fork, so if it was too much work, then making the changes and then integrating it upstream into NetBSD might have been a better idea, and NetBSD could have made it available on all architectures. Another thing they could have done - take their changes, gone to Minix, and there, put their chan

    • Re: (Score:2)

      by rev0lt ( 1950662 )
      From what I've read (diagonally) from the article, the fork was started by OpenBSD developers. I guess they decided to fork something they already have good knowledge of. FreeBSD internals are quite different, and while NetBSD has some similarities, they have come a long way since the OpenBSD fork.

  • no SPARC support? (Score:2, Interesting)

    by Anonymous Coward

    I only used OpenBSD for SPARC hardware and it really belongs to the "big iron". Is this project aiming for the desktop? embedded platforms? Well, good luck with device drivers then. We already have linux for all that and you can't beat it in hardware support. So what's the point?

    • Frankly, I'm a tad disappointed by them deciding to restrict this project to just the x64 architecture, given the portability of both OpenBSD and NetBSD, As I note above, they could have preserved the portability aspect of it by doing it on NetBSD or even Minix.

      Yeah, there are a plethora of OSs wanting to run on PCs. Sparc is one target they could have had. Another would have been Itanium. They might even have gotten some Intel and/or HP backing had they gone that route, and little competition, since

    • So what's the point?

      1: License. Some people dislike GPL and other copyleft licenses, and demand something BSD-licensed or similar. I personally don't care, but for those that do, this is a Good Thing.

      2: Just to be different. It's good to have *options*. I personally despise most Linux's init system. Too convoluted, too complicated, at least for my taste. Some distros, like Arch, have adopted a BSD-style init system. OpenBSD, and by extension Bitrig, also have a BSD-style init system. There's also the different package/port sys

        1. Every BSD distro there currently is runs on an x86, not to mention the various legacy x86 based Unixes that are already out there
        2. Again, there is a plethora of distros targeting PCs. If someone is going to come out w/ something new, especially when based on a server unix like OpenBSD, then why not target orphaned platforms instead, like Sparc and Itanium, which have limited options to start w/?
        3. I agree w/ the above AC - talking about floppies in this day & age when even CDs are going out of style seems

  • Code reinvestment and positive feedback loops. (Score:5, Insightful)

    by bmo ( 77928 ) on Wednesday June 13, 2012 @01:18PM (#40312161)

    "be a very commercially friendly code base by using non-viral licenses where possible."

    The advantages to Linux over BSD licensed operating systems is that improvements are reinvested in the code base, by mandate. This accelerates development at a much faster rate than we've seen with any of the BSDs since it is a positive feedback loop. Contrary to this, companies take BSD code, improve it, and tend to release nothing back. Because they don't have to. Look at OSX.

    So now we have a project that is "focused on modern hardware and SMP" among other things. Compare and contrast to Linux which keeps up with modern hardware a lot better than any of the BSDs. I'm betting the goal of "keeping up with modern hardware" is going to fall by the wayside when they eventually discover how difficult it is when it's just them doing all the heavy lifting.

    I also take issue with the "commercially friendly" jab. Linux is GPL, and it's commercially friendly. Sensible companies are not afraid one bit of using Linux. The ones who are don't understand what they're missing when it comes to the code reinvestment cycle.

    --
    BMO Downmods coming in 3... 2 ... 1...

    • The advantages to Linux over BSD licensed operating systems is that improvements are reinvested in the code base, by mandate. This accelerates development at a much faster rate than we've seen with any of the BSDs since it is a positive feedback loop. Contrary to this, companies take BSD code, improve it, and tend to release nothing back. Because they don't have to. Look at OSX.

      Such as libdispatch, WebKit and LLVM/Clang? Just to mention a few.

      Maybe I missed your point but just because Apple doesn't release their entire operating system as open source doesn't mean that they don't invest and contribute to open source.

      • Re: (Score:3)

        by bmo ( 77928 )

        Webkit isn't BSD. It's LGPL, because it came from khtml.
        Libdispatch is Apache.
        LLVM/Clang - oh look, you finally struck gold, a BSD license.

        --
        BMO

        • OK. I missed your point then. I thought that you pointed out Apples as an example of an organization that doesn't contribute back.

          Anyway, they do contribute to fair amount of projects. Libdispatch even originated from Apple if I remember correctly.

          • Re: (Score:2)

            by bmo ( 77928 )

            Apple has a bunch of BSD code they've modified and never given out. I did not claim that they never do, but they tend not to.

            Apple is under no obligation to contribute back. This behaviour was apparent when they tried to deal with the khtml crew and had no idea how to share code, causing a shitstorm and the khtml devs to reject their code. They had to learn how to share code with outside devs. Eventually this happened and we wound up with webkit.

            What I'm trying to say is that the BSD license does not en

            • Apple has a bunch of BSD code they've modified and never given out. I did not claim that they never do, but they tend not to.

              And the FreeBSD people would have absolutely not problem with this, assuming it were true. But alas, it isn't true. It just happens that most of Apple's changes aren't incorporated into FreeBSD because it just doesn't make much sense for them to be (e.g. the changes are particular to Apple products or their own operating system), but they do release those changes in the open source version of their OS (Darwin). The parts of Mac OS X that aren't open source or distributed with Darwin are mostly parts whic

            • What I'm trying to say is that the BSD license does not encourage the collegiality which I believe is the GPL's greatest strength.

              BSD doesn't mandate releasing source code of derivative works that are distributed in object code form the way the GPL does; neither license does much one way or the other to "encourage collegiality", which is vastly more a factor of the particular personalities involved in a community than licenses.

              Projects which attract a broad community of developers (individual or corporate)

            • Apple has a bunch of BSD code they've modified and never given out.

              You claimed that twice, but didn't cite any examples. I can grab the sources for all of the FreeBSD-derived parts of libc and the kernel, for example, as well as all of use userspace utilities, from opensource.apple.com. There's little point in doing so, however, because Apple employs enough FreeBSD developers that most stuff that's sufficiently interesting gets pushed back by them already.

              What I'm trying to say is that the BSD license does not encourage the collegiality which I believe is the GPL's greatest strength.

              The 75+ companies represented at the Vendor Summit at BSDCan would disagree. The strong community was one of the mos

            • Apple chose to invest in the BSD codebase because they could do this, and would likely otherwise have gone a completely different route (e.g, licensing vxWorks as a base.) So having Apple contribute all changes back was not in the cards.

              Apart from that, I'm fairly sure FreeBSD was offered re-licensing on most Apple code for integration back into FreeBSD if we were interested (mail to a private mailing list); lack of takeup on this seemed to be that nobody on the FreeBSD side had the spare capacity to deal

    • Re: (Score:2)

      by Raenex ( 947668 )

      BMO Downmods coming in 3... 2 ... 1...

      Oh look, it's the special-pleading-to-get-upmods trick.

  • Honest question: So what were the BSDs (Open,Free,Net) using to compile and run on x86 and amd64 before llvm/clang was around? GCC ?

    GCC had its share of problems but this sounds a little ungrateful for what GCC has allowed hackers to do. An open source "good enough" compiler is better then a high priced closed source compiler that may or may not be available for your hardware.

    • Honest question: So what were the BSDs (Open,Free,Net) using to compile and run on x86 and amd64 before llvm/clang was around? GCC ?

      GCC.

      GCC had its share of problems but this sounds a little ungrateful for what GCC has allowed hackers to do.

      I'm only familiar with FreeBSD but I guess the situation is similar at NetBSD and OpenBSD. They are not ungrateful. They have found another compiler that they think is better for their needs. That simple. Makes good headlines though.

      An open source "good enough" compiler is better then a high priced closed source compiler that may or may not be available for your hardware.

      I agree, but isn't Clang open source?

  • Whenever I see announcements of "We're creating a fork!!!" the first thing I think of:
    http://www.levenez.com/unix/ [levenez.com]

    Lots of tiny branches that just stop.

    • Re: (Score:2)

      by Saija ( 1114681 )
      I think that looks like evolution, you know, the tree of the species with some dying and some changing onto something else
  • It is a nice idea but the name makes me want to roll my eyes. Why not something cool like TornadoBSD or something along those lines? :D

Slashdot Top Deals

Keep up the good work! But please don't ask me to help.

Close