Boomer Beta Source Code Posted

Boomer, aka PSARC 2008/318 -- the new audio subsystem for Solaris, and the project I've been working on for the last several months -- has released source code for our work in progress. A status update and link to the webrev is available here.

Comments

Phobos said…
hello!

I've been kind of following Boomer's and OSS' development for some time now, and I have a question...

I have read the documents on opensolaris.org and as I understood there are no plans of supporting things like MIDI, because they are not supported on OSS at this time...

but then, I read posts like this one: http://4front-tech.com/hannublog/?p=15 by Hannu, wanting to add MIDI support to OSS 4.2... but also expressing his dissapointment at how different Boomer is from OSS now, and how difficult will it be to integrate new features from OSS into Boomer...

Isn't this something that should have been taken in account before?.. will new features from OSS be integrated in opensolaris?
December 31, 2008 at 9:44 AM
Unknown said…
MIDI support is not a priority for us right now. It is unlikely that will ever change... there just isn't that much call for it anymore. (It used to be much more important when audio devices were 8-bit only, and MIDI was required to get high quality music from computers.)

We originally planned to integrate OSS "as-is", but there were a rather large number of technical reasons why this was just not possible -- there were severe architectural limitations in the 4Front code base, and trying to fix them all and retain purity to the upstream source at the same time was not possible. (I can't really express the full list of issues publicly at this time, but the list was large.)

We decided rather intentionally to "cherry pick" the best parts of 4Front's code, as well as some Sun legacy (for example the conversions Sun had in legacy for ULAW and ALAW were much higher quality, and Sun drivers have support for suspend/resume and dynamic reconfiguration).

We believe in this case, that Sun and Solaris was best served by making the best possible implementation for the audio stack we could do, while retaining fidelity to the OSS APIs and compatibility with the legacy Sun APIs.

We believe that it will be possible to cherry pick some of the innovations that come from 4Front in the future, but we reserve to the right to decline to integrate features that we believe are not terribly relevant, or will cause more support issues than solve problems. (I believe MIDI falls into this category.)

Notably, we aren't the first OS to elect to take this approach. The same approach to 4Front's code base (cherry picking) has been used by both Linux and the BSDs. While many believe that the rationale was license based, I believe at least part of the rationale was technical in nature.
December 31, 2008 at 9:56 AM
Post a Comment

Popular posts from this blog

An important milestone

Yesterday, with very little fanfare, illumos passed an important milestone. This milestone was the integration of  195 Need replacement for nfs/lockd+klm This is work that I originally tasked Gordon Ross and Dan Kruchinin to work while we were colleagues at  Nexenta .  Gordon started the work, picking up bits from FreeBSD as a starting point and gluing it to the illumos entry points.  Dan continued with it, and fleshed out a lot of the skeleton that Gordon had started.  It was subsequently picked up by the engineers at Delphix , and -- after some important bug fixing work was completed -- was integrated into their product quite some time ago -- reportedly its been stable since December in their product. The reason this is such an important milestone, is two fold: First, this represents a substantial collaborative effort, involving contributions from parties across several organizational boundaries.  The level of collaboration achieved here is a w...
Read more

GNU grep - A Cautionary Tale About GPLv3

My company, DEY Storage Systems , is in the process of creating a new product around the illumos operating system.  As you might imagine, this product includes a variety of open and proprietary source code.  The product itself is not delivered as a separate executable, but as a complete product.  We don't permit our customers to crack it open, both from the sense of protecting our IP, but also to protect our support and release engineering organizations -- our software releases consist only of a single file and we don't supply tools or source for other parties to modify that file. One of the pieces that we wanted to integrate into the tree is an excellent little piece of software called Zookeeper , produced by the Apache organization.  Like illumos, Zookeeper has a nice non-viral copyleft license, which makes it nice for integration into our product. However, I discovered that as part of our integration, one of my engineers had decided to integrate GNU grep. ...
Read more

The Hand May Be Forced

Well, as you may have read , Oracle has decided that at some point very soon, we're going to lose normal regular access to the source code for OS/Net. (I.e. the Solaris kernel and supporting programs.) While I would have vastly preferred for Illumos to have a cooperative and collaborative relationship with Oracle , it appears that Oracle doesn't value this. In fact, the exact words were from the management at Oracle were as follows: Solaris is not something we outsource to others, it is not the assembly of someone else’s technology, and it is not a sustaining-only product. While I understand the need to own the technology, there are few things that could be stated that show a stronger NIH attitude than this. Its unlikely that there will ever be a way for Oracle and the greater community to have a collaborative relationship. This is a dark day for OpenSolaris -- its effectively dead now. (Its parent, Solaris, lives on however.) How unfortunate. For Oracle that is. Because...
Read more