<div dir="ltr">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.<br>
<br>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.<br>
<br><br>on Mon, Feb 17, 2014 at 5:38 AM, David H <<a href="mailto:davidhalko@gmail.com" target="_blank">davidhalko@gmail.com</a>> wrote:<br>><br>> Collaboration Criteria:<br>> - The original promise was for both Intel & SPARC in the community,<br>
> that promise should be kept.<br><br>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.<br>
<br>> Collaboration should be to pool resources to expand the ecosystem -<br>> not pool all available resources in order to keep the ecosystem<br>> limited in overall scope.<br>><br>> Thanks, Dave<br>
<br>AMEN to that.<br><br><br>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.<br>
<br>To quote Joerg Schilling <<a href="mailto:Joerg.Schilling@fokus.fraunhofer.de" target="_blank">Joerg.Schilling@fokus.fraunhofer.de</a>><br>at another instance (Wed, 12 Feb 2014 14:28:47 +0100):<br>> <br>> "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.<br>
> <br>> I am open for a collaboration for OpenSolaris as long as there is room for different goals in the different distros."<br><br>Joerg Schilling <<a href="mailto:Joerg.Schilling@fokus.fraunhofer.de" target="_blank">Joerg.Schilling@fokus.fraunhofer.de</a>><br>
(Thu, Feb 13, 2014 at 5:35 PM):<br>> <br>> 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.<br>
> <br><div class="gmail_default" style="font-size:large;display:inline"></div>> 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.<br>
> <br>> <br>> Jörg<br><br>We must put this to practice.<br>I believe the best is yet to come for free OpenSolaris-based systems.<br><br><br><div class="gmail_default" style="font-size:large">
Sincerely yours,<br><br></div><div class="gmail_default" style="font-size:large">Seth Nimbosa,<br>
</div><div class="gmail_default" style="font-size:large;display:inline"></div><font size="1"><a href="http://twitter.com/nimbosa" target="_blank">http://twitter.com/nimbosa</a><br>
<a href="http://FB.com/nimbosa" target="_blank">FB.com/nimbosa</a><br><br><br></font><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
___________________________________________<br>> On Thu, Feb 13, 2014 at 5:35 AM, Joerg Schilling<br>> <<a href="mailto:Joerg.Schilling@fokus.fraunhofer.de">Joerg.Schilling@fokus.fraunhofer.de</a>> wrote:<br>
> > seth Nimbosa <<a href="mailto:darth.serious@gmail.com">darth.serious@gmail.com</a>> wrote:<br>
> ><br>> >> I think the general idea is to get to a minimum criteria as basis for wider<br>> >> collaboration. We have to start small and manageable and agreeable. Then<br>> >> others will follow if they see the benefits of that working together for a<br>
> >> healthier code and healthier community guidelines, then there will be lower<br>> >> barriers for participation, more consensus-building and pooling together<br>> >> the best solutions out there.<br>
> ><br>> > It is more than a minimum criteria, we need (as mentioned yesterday) an opening<br>> > towards OpenSolaris goals that do not prevent collaboration because of<br>> > artificial limitations in a single development branch.<br>
> ><br>> > For me, it is important that OpenSolaris keeps the ability to be ported to<br>> > embedded systems. This reqires some decisions made by Sun and others made by<br>> > Illumos to be reverted. So the following requirements are important:<br>
> ><br>> > - Keep support for 32 bit kernels (at least for one CPU target)<br>> ><br>> > - Keep support for a UFS root filesystem<br>> ><br>> > - Keep support for /usr being on a different FS than /<br>
> ><br>> > - Allow it to be on a tiny system where you cannot afford the monster<br>> > ksh93 to allocate several MBs on a tiny root FS. This requires support<br>> > for the Bourne Shell for all scripts that need to be run before /usr<br>
> > is mounted, which means to fix 6 shell scripts modified by Sun in<br>> > spring 2010.<br>> ><br>> > Other criteria are support for SVr4 package meta data. This may need to add<br>
> > support for specific SVr4 meta data that did not exist in 2010 already. Note<br>> > that I did enhance the SVr4 packaging for SchilliX-ON already and there will<br>> > be further enhancements in the future. There is e.g. a plan to add some high<br>
> > level functions seen on IPS to be added to "pkgadm". There is also a plan to<br>> > allow longer names and to add category based entries in the metadata. The<br>> > latter is partially already in SchilliX-ON.<br>
> ><br>> > We need an ABI definition for OpenSolaris.<br>> ><br>> > We should have an architecture commitee that should at least give a base for<br>> > simple additions that do not cause incompatibilities. To make some examples<br>
> > from the SchilliX-ON development:<br>> ><br>> > - grant the libraries to run e.g. star and the new enhanced Bourne Shell<br>> > to be present. This is e.g. /lib/libschily* /lib/libshedit*<br>
> > /lib/libxtermcap*. These libraries are in SCHILYsystem-library-schily*<br>> > SCHILYsystem-library-schily-root and SCHILYsystem-library-schily are now<br>> > part of the basic system dependencies, so you cannot install a system<br>
> > without it.<br>> ><br>> > - Add POSIX enhancements like the %r printf format that I am currently<br>> > proposing for the next POSIX version. The first implementation already<br>
> > exists and will appear soon on SchilliX-ON (after the discussion on<br>> > the standard commitee did settle).<br>> ><br>> > - Add syscall enhancements like a planned method to allow a process to<br>
> > aquire enhanced privileges without the need for a exec*() call.<br>> > Since 24 months, cdrtools may be installed non-suid-root without<br>> > the need for the current wrapper scripts. This is currently implemented<br>
> > by a re-exec in cdrecord/cdda2wav/readcd, but this could be done by a<br>> > new function to the privsys() call to avoid a re-exec.<br>> ><br>> > I am sure that other ON development branches have own code too, that might be<br>
> > of general interest if it is not in conflict with a previous ABI.<br>> ><br>> >> I am inviting Alasdair, Peter Tribble, Jörg Schilling and Martin Bochnig to<br>> >> discuss this and find the best way forward in creating this smaller circle<br>
> >> to create greater trust and more support from within the<br>> ><br>> > I tried this already several times in the past, but maybe it is better to have<br>> > a moderator that is not involved in an own development branch.<br>
> ><br>> > To be able to start, we need to talk about what we are doing and be open for<br>> > the contraints that need to be met in order to permit a collaboration.<br>> ><br>> > e~A<br>> > -------------------------------------------<br>
</blockquote></div><br></div></div>