[oi-dev] [discuss] Re: basis for better collaboration on illumos and OpenIndiana: small circle, Big circle

Thu Feb 20 03:34:05 UTC 2014

The reason we need a minimum of criteria for collaboration is precisely
because the different distributions have different focus, approach, and use
case scenarios in mind, but a set of core features that will make it to a
unified kernel will be for everyone's benefit.  Additional layers will be
built upon this basic core and the abstraction of these feature-sets and
their encapsulation from the layers below and above it will ensure that
there is more or less a predictable and uniform way each of these layers
interact together and how they behave on top of the core.  I mean each
distro-specific feature-set will be spun out and encapsulated into separate
layers of development on top of the kernel (and these layers will be
slightly or wildly different in each distribution) but the core will remain
mainly intact but dynamically developed jointly by the different distros in
an upstream manner.

For example, support for Linux platform ABI through branded zones like
"Solaris Containers for Linux Applications" (SCLA) has been implemented by
Sun before.  This is possible because there is a Linux platform ABI to
speak of.  It makes sense if we can agree on a minimum set of behavior and
features that make up an OpenSolaris-based platform ABI, implemented
through a smaller standard reference distribution that will embody this
minimum standard, like a smaller text-based OpenIndiana server install or
LiveCD that will serve as reference, example and basis of other distros
that will build layers of additional layers on top of it.  We must reckon
that Solaris itself in the beginning was the direct result of unification
efforts by AT&T, Sun and others, and so SVR4 was born which was the basis
and foundation of many later UNIX systems and other OS'es and so on.  I
think it's not too late to gather the efforts of our separating communities
in the different branches of OpenSolaris-based distros to arrive at s
single standard like the mainline Linux kernel, and a jointly-developed
single reference distro like Sun's OpenSolaris LiveCD in the past,
resulting in a slim OpenIndiana which can be a reference to other distros
or even as a basis for a larger full-featured GUI-based OpenIndiana LiveCD.

on Mon, Feb 17, 2014 at 5:38 AM, David H <davidhalko at gmail.com> wrote:
>
>    Collaboration Criteria:
>    - The original promise was for both Intel & SPARC in the community,
>    that promise should be kept.

I believe so, too. I have been in contact with Martin Bochnig and he is
very positive about collaboration and unification efforts.  He is willing
to release his progress so far and will be putting up a wiki to explain his
process and recipe for x86, x86_64 and SPARC architectures.  He has been
collaborating with DilOS folks and I know things will be better the moment
we start plotting their development against how ilumos-kernel has evolved
and how OpenIndiana has grown.  The key factor here is: how much code from
OpenSolaris has been discarded simply because Nexenta or Joyent has found
no use for it?  I believe there may be many such valuable artifacts (like
SPARC support) from Sun's OpenSolaris that has been lost, because slashing
them was expedient and caused "less" bugs.  Another factor is: what
improvements have been developed outside of the ambit of
illumos-OpenIndiana circles, by other branches like SchilliX, Belenix,
MartUX/OpenSXCE, DilOS, XstreamOS, OmniOS, etc.?  David, you have a very
good partial list, and to be frank yes! many oppotunities indeed passed by,
but I think the best is yet to come.  Thanks Srinam for dropping that
Belenix is also underway.

>    Collaboration should be to pool resources to expand the ecosystem -
>    not pool all available resources in order to keep the ecosystem
>    limited in overall scope.
>
>    Thanks, Dave

AMEN to that.

The tug and pull of Jorg and Peter's arguments is healthy for our
community.  This way we can strike a balance between the tyranical standard
approach with a rigid set of feature compliance and the very fuzzy
definition of what OpenSolaris-based distros are evolving into.  By keeping
our criteria for collaboration at a minimum, we are inviting more synergy
between developers on the basic general stuff and at the same time
promoting more choices how to implement different solutions to the same
familiar problems and opening more ways to implement new solutions to needs
unforeseen or poorly addresed before.

To quote Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de>
at another instance (Wed, 12 Feb 2014 14:28:47 +0100):
>
> "Collaboration is a result of promises and credibility by implementing
said promises. Collaboration is also a result of compromises. If you are
not willing to make compromises, you try to dictace what other people may
do and this is not compatibile with collaboration.
>
> I am open for a collaboration for OpenSolaris as long as there is room
for different goals in the different distros."

Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de>
(Thu, Feb 13, 2014 at 5:35 PM):
>
> If you like to collaborate between different projects, this will need
both sides to make compromises and to give enough room so the other side is
able to have a benefit.
>

> I am willing to give other people enough room and I guess that you would
do the same. So let us see whether OI is willing to colaborate. As I
mentioned since a long time: OpenSolaris has not enough people to make each
job twice, so we need to collaborate if we like OpenSolaris to survive.
>
>
> Jörg

We must put this to practice.
I believe the best is yet to come for free OpenSolaris-based systems.

Sincerely yours,

Seth Nimbosa,

http://twitter.com/nimbosa
FB.com/nimbosa

___________________________________________
> > On Thu, Feb 13, 2014 at 5:35 AM, Joerg Schilling
> > <Joerg.Schilling at fokus.fraunhofer.de> wrote:
> > > seth Nimbosa <darth.serious at gmail.com> wrote:
> > >
> > >> I think the general idea is to get to a minimum criteria as basis for
> wider
> > >> collaboration.  We have to start small and manageable and agreeable.
> Then
> > >> others will follow if they see the benefits of that working together
> for a
> > >> healthier code and healthier community guidelines, then there will be
> lower
> > >> barriers for participation, more consensus-building and pooling
> together
> > >> the best solutions out there.
> > >
> > > It is more than a minimum criteria, we need (as mentioned yesterday)
> an opening
> > > towards OpenSolaris goals that do not prevent collaboration because of
> > > artificial limitations in a single development branch.
> > >
> > > For me, it is important that OpenSolaris keeps the ability to be
> ported to
> > > embedded systems. This reqires some decisions made by Sun and others
> made by
> > > Illumos to be reverted. So the following requirements are important:
> > >
> > > -       Keep support for 32 bit kernels (at least for one CPU target)
> > >
> > > -       Keep support for a UFS root filesystem
> > >
> > > -       Keep support for /usr being on a different FS than /
> > >
> > > -       Allow it to be on a tiny system where you cannot afford the
> monster
> > >         ksh93 to allocate several MBs on a tiny root FS. This requires
> support
> > >         for the Bourne Shell for all scripts that need to be run
> before /usr
> > >         is mounted, which means to fix 6 shell scripts modified by Sun
> in
> > >         spring 2010.
> > >
> > > Other criteria are support for SVr4 package meta data. This may need
> to add
> > > support for specific SVr4 meta data that did not exist in 2010
> already. Note
> > > that I did enhance the SVr4 packaging for SchilliX-ON already and
> there will
> > > be further enhancements in the future. There is e.g. a plan to add
> some high
> > > level functions seen on IPS to be added to "pkgadm". There is also a
> plan to
> > > allow longer names and to add category based entries in the metadata.
> The
> > > latter is partially already in SchilliX-ON.
> > >
> > > We need an ABI definition for OpenSolaris.
> > >
> > > We should have an architecture commitee that should at least give a
> base for
> > > simple additions that do not cause incompatibilities. To make some
> examples
> > > from the SchilliX-ON development:
> > >
> > > -       grant the libraries to run e.g. star and the new enhanced
> Bourne Shell
> > >         to be present. This is e.g. /lib/libschily* /lib/libshedit*
> > >         /lib/libxtermcap*. These libraries are in
> SCHILYsystem-library-schily*
> > >         SCHILYsystem-library-schily-root and
> SCHILYsystem-library-schily are now
> > >         part of the basic system dependencies, so you cannot install a
> system
> > >         without it.
> > >
> > > -       Add POSIX enhancements like the %r printf format that I am
> currently
> > >         proposing for the next POSIX version. The first implementation
> already
> > >         exists and will appear soon on SchilliX-ON (after the
> discussion on
> > >         the standard commitee did settle).
> > >
> > > -       Add syscall enhancements like a planned method to allow a
> process to
> > >         aquire enhanced privileges without the need for a exec*() call.
> > >         Since 24 months, cdrtools may be installed non-suid-root
> without
> > >         the need for the current wrapper scripts. This is currently
> implemented
> > >         by a re-exec in cdrecord/cdda2wav/readcd, but this could be
> done by a
> > >         new function to the privsys() call to avoid a re-exec.
> > >
> > > I am sure that other ON development branches have own code too, that
> might be
> > > of general interest if it is not in conflict with a previous ABI.
> > >
> > >> I am inviting Alasdair, Peter Tribble, Jörg Schilling and Martin
> Bochnig to
> > >> discuss this and find the best way forward in creating this smaller
> circle
> > >> to create greater trust and more support from within the
> > >
> > > I tried this already several times in the past, but maybe it is better
> to have
> > > a moderator that is not involved in an own development branch.
> > >
> > > To be able to start, we need to talk about what we are doing and be
> open for
> > > the contraints that need to be met in order to permit a collaboration.
> > >
> > > e~A
> > > -------------------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20140220/4691f2e6/attachment-0005.html>