OSUNIX overview for Gentoo developers

We realize that from a Gentoo developers perspective OSUNIX does things a bit differently.  To some this is may be good and to others this could be breaking habits and practices which have been built over many years.  Most Gentoo developers will feel very comfortable with our clean approach, direction and philosophy.  Our focus is on building great technology and not licensing wars or other fanatic zealotry.  At the core we've taken a fresh look on many things and try to engineer a path which accomplishes the best of building from source and binary package support.

The highest level difference between Gentoo and OSUNIX
OSUNIX philosophy about main tree
What is an ediff and how it helps overlays
Things about OpenSolaris that suck and we're fixing
OpenSolaris technology which is great
10 reasons to use OSUNIX
Current status and how you can help

The highest level difference between Gentoo and OSUNIX?

Gentoo is a great Linux distribution which focuses on the power of building all software from source and the flexibility to break anything any time.
OSUNIX is a fork from OpenSolaris which from the start is a big difference from the main Gentoo tree.  Until you really dig in and compare Linux and OpenSolaris it's hard to realize all the differences between the start-up, kernel, libc, networking and toolchain.  Instead of absolute flexibility we try to achieve maximum flexibility, but never at the cost of core system stability or core package quality.

OSUNIX philosophy about main tree

The OSUNIX main tree just like FreeBSD or OpenSolaris has the goal to be a very solid foundation.  It's on top of this that we want to build flexibility and high quality packages.  One of the main benefits of Gentoo is it's strong focus on tools for package maintainers and developers.  We've taken the strengths of building from source and optionally coupled it with the strength of binary packages.  Our modified version of pkgcore can build gentoo binary packages, debs, and a new rpm5-like variant that's still under heavy development.  One of our goals is to have pkgcore and smart package manager work seamlessly together.  Our goal is provide both the option to build everything from source or use entirely binary packages.  Having both in sync allows developers to build from source and end users, companies and administrators to have the convenience of binary packages.  Having this functionality entirely in pkgcore is possible, but we wanted to leverage smart package managers well maintained gui and great dependency solver.

What is an ediff and how it helps overlays

Core ebuilds shouldn't have logic or use flags enabled by default.  The goal is to be able to provide the highest level of quality and easily reproduce any problems.  In the past there wasn't an easy way to make a small maintainable variance upon a base ebuild.  As a result overlays and use flags were created.  The complaints most commonly mentioned about overlays is that they are loosely coupled from the main tree and also extraneous to maintain.  With taking a fresh look at the problem we invented something called an "ediff".  The ediff is just a simple -ru patch between two versions of an ebuild.  This extension was simply given so that pkgcore can understand what to do with it when it's side-by-side to an ebuild.  Here's a basic real world example.

OSUNIX main tree is a x86_64 solaris base.

foo package - foo-0.0.1.ebuild

...
src_compile() {
     econf \
        --enable-64 \
        | die "you get the idea"
...

Now we assume that we want to support a new arch i686 and make an overlay for it.  In the overlay we have to disable all the explicit 64bit options that are currently enabled.  It could be the other way around, but this is just one example.

# Gentoo way with lots of if blocks and logic statements

src_compile() {
...
if [ arch == i686 && != arm || other_logic_which_makes_this_harder_to_maintain ]
...

     econf \
        (enable-use 64) \
        | die "you get the idea"

----
# Our main tree example

     econf \
        --enable-64 \
        | die "you get the idea"

# Start to show the benefit of ediff

foo-0.0.1-r1.ebuild
...
src_compile() {
# We could also maybe assume that our --target has changed
# and just leave the --enable-64 out, but verbosity on for
# example purposes
     econf \
        --disable-64 \
        | die "you get the idea"

So now instead of pushing the entirely new ebuild into the overlay we just make an ediff

diff -ru  foo-0.0.1.ebuild foo-0.0.1-r1.ebuild > foo.ediff

--- foo-0.0.1.ebuild  Sat Apr 11 10:04:25 2009
+++ foo-0.0.1-r1.ebuild Sat Apr 11 10:04:20 2009
@@ -1,5 +1,8 @@
  src_compile() {
+# We could also maybe assume that our --target has changed
+# and just leave the --enable-64 out, but verbosity is on for
+# example purposes
      econf \
-       --enable-64 \
+       --disable-64 \
         | die "you get the idea"

Now we have an ediff which is tightly coupled to the main tree.  All you have to do is maintain a diff against the main tree.  We've removed the need for both logic and if blocks for at least the core ebuilds.  The result is a cleaner main tree and isolated variances.

Author note:  I realize most people are scared of change, but when you see it in real world example it becomes clear.

At the highest level in the past overlays could only "overlay" or override ebuilds in the main tree.  Now we give overlays the power to merge and overlay.  When you start to see and treat the main tree as a codebase instead of a bunch metadata it only seems logical to apply a diff for anything you need to change or maintain.

Things about OpenSolaris that suck and we're fixing

1) Horribly disorganized and poorly maintained open source toolchain (mostly fixed)
2) Very difficult to setup a path which works for development, interactive use and core system needs (in progress but needs more help)
3) Terrible packaging that range from current day IPS to 20 year old SVR4 (mostly fixed)
4) Lack of modern workstation features and usability compared to other operating systems (needs help)
5) Some closed binaries need to be replaced (8+ months of work and only a few parts in libc is left. Plan exists, but needs a volunteer with good c coding background)

OpenSolaris technology which is great

ZFS - If zfs wasn't a storage dream I'd think it was written entirely for a developer always pushing the edge too much.  Zfs not only allows you to build truly flexible and great storage solutions, but also comes with some great hidden features and side effects.  For example before each update just do a zfs snapshot.  If your system gets broken just reboot back to the old one.  It takes all the risk out of updates and lets the developer really push the edge.

Zones - Very low overhead virtualization technology that supports Solaris, Linux 2.4, and Linux 2.6 (beta).

Dtrace and observability tools - Even if you forgot to compile with debugging there's a number of really powerful and great developer and admin tools for diagnosing a problem.

SMF - Service management framework : Start-up and service management has never been so over engineered and beautiful at the same time.  The interfaces to controlling and monitoring services is very well organized, but at the cost of being more than simple shell scripts.  At the core the way you control a service for it's full lifetime and even under stress is very logical, but there is a learning curve here.

Boomer - Boomer is OSS, but with new features and a twist that gives a number of cutting edge advantages.  The result is a highly scalable and well engineered audio system that really solves the core problem ALSA was always inspiring to do so.

Crossbow - On top of the very nice networking stack has been added a level of mint for virtualization and ultimately a platform as a base for some serious core routing and networking features.

kmdb - If you're not a kernel developer you won't care, but for the rest of us kmdb makes debugging a panic or driver development a dream.  There's no need for a serial cable or print statements.  From a grub option you can configure the system to drop to kmdb and from there actually debug and get to the root of the problem.

coreadm - This is yet another commonly overlooked, but indispensable feature for both admins and developers.  For any application that drops a core you can centrally configure where and how it's named.  There's a multitude of configuration options for this, but even your fork'ed process is dropping core it's where you expect it to be.  At the highest level this core can be shared and used to debug your problem without the hassle of trying to exactly build the same working environment.

kernel code - Last, but certainly not least is the well engineered and methodically clean kernel code.  All commits go under nothing less than a gauntlet of reviews and for the past 20 years has continuously been engineered to be better.  Large companies like AMD and Intel along with Sun ensure it takes advantage of the performance benefits from the latest chipsets.  Official benchmarks are forthcoming, but early testing is very optimistic against every other modern operating system.

10 reasons to use OSUNIX

1) Most ebuilds require minimal changes to work on OSUNIX
2) Best balance of entirely from source packaging and binary distribution
3) Security in the core and not as a hardened option
4) Leverages all the best of OpenSolaris technology (zfs, zones, smf, dtrace.. etc)
5) Good leadership that understands community comes first
6) Takes advantage of the hard work from a large corporation
7) A great platform and community to build innovation
8) A strong focus on performance
9) Dedicated to removing all closed binaries
10) Emphasis on conforming to standards

Current status and how you can help

We currently are only able to provide developer support, but we're close to having a really solid base.  (About 20 bugs/features away.  Depending on how much help we get it could take a week or 2 months)

Things sometimes move fast, but feel free to check out TODO page or contact us if you'd like to help or just send a friendly hi our way.

• Take a minute to join our community here >>
  
• IRC #osunix irc.freenode.net
• Join our development mailing list