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

[Peter Tribble]

On Sun, Feb 16, 2014 at 9:38 PM, 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.
>

Do the work. Illumos itself has gone to a great deal of trouble
to maintain parity between x86 and SPARC - for little obvious
gain, given the overwhelming preponderance of x86 in the
user base. Attempts to encourage wider use of SPARC have
failed due to lack of interest.


> Forster Other Goals
> - Embedded appliance is something which should be encouraged (beyond
> storage-only appliances)
>

So build one. All the tools are available to you.

- Expansion into other architectures to offer embedded hosting
> opportunities (i.e. ARM, POWER, MIPS)
>

Seriously? There have been efforts to get ARM working, but a
platform port is a significant endeavour and I think we've already
noted that the available resources in the community are relatively
limited.


> - Revisit of embedded ZFS (tiny ZFS was a discussion back in the Sun days)
>

Again, if this is important, someone will step up and do the
work.

It's very darwinian, and that's the way it should be. Features
that matter survive, features that have nobody interested in them
(or where the interested people are unwilling to help) will wither
and die.

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)
>

It's still there. What's the problem?


>  > -       Keep support for a UFS root filesystem
>

Works just fine.


>  > -       Keep support for /usr being on a different FS than /
>

That's pretty much irrelevant, as it's largely a distro issue
as to how bits are partitioned. (The /usr split is also one of
those really odd architectural hangovers that no longer makes
much sense. It's more force of habit than solid architecture
that's keeping the separate /usr concept alive. I suspect there
are opportunities for significant change and improvement in
where we place the various bits.)

 > -       Allow it to be on a tiny system where you cannot afford the
> monster
> >         ksh93 to allocate several MBs on a tiny root FS.
>

Having worked extensively on both system minimization
and split-/usr configurations, ksh93 was never an important
part of the overall budget. If you're in a realm where single
megabytes matter (and I've been there) you're making
significant changes to the structure of the OS, and you
shouldn't expect a general-purpose operating system to
minimize that far without making changes that wouldn't be
advisable in other contexts.


> 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.
>

And the illumos bug ids are?


>  > 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.
>

Why be SVR4 specific? The IPS manifests contain metadata, which
can trivially be imported by any other packaging system.


> 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".
>

I suspect that pkgadm is entirely the wrong place, and that improving
packaging lives a level above. (Think yum vs rpm.)


> There is also a plan to
> > allow longer names
>

Ouch. 32 characters ought to be long enough. Just from the point
of readability, keeping them short ought to be encouraged, with long
forms in metadata.


> and to add category based entries in the metadata. The
> > latter is partially already in SchilliX-ON.
> >
> > We need an ABI definition for OpenSolaris.
>

Aside from the fact that OpenSolaris no longer exists, and thus
cannot have an ABI by definition, don't we actually have a stable
ABI already?


> > 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:
>

The first of which is simply you trying to ram your own personal
code down everybody else's throats, which I know I wouldn't accept.
The other examples are really a simple case of filing a bug, having
code review, and submitting an RTI. If you were actually interested
in collaboration rather than criticising the rest of the community for
failing to surrender to your every demand, you could do that today.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20140218/f1d8350a/attachment-0004.html>