<div dir="ltr">On Sun, Feb 16, 2014 at 9:38 PM, David H <span dir="ltr"><<a href="mailto:davidhalko@gmail.com" target="_blank">davidhalko@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Collaboration Criteria:<br>
- The original promise was for both Intel & SPARC in the community,<br>
that promise should be kept.<br></blockquote><div><br></div><div>Do the work. Illumos itself has gone to a great deal of trouble<br></div><div>to maintain parity between x86 and SPARC - for little obvious<br></div><div>gain, given the overwhelming preponderance of x86 in the<br>
user base. Attempts to encourage wider use of SPARC have<br>failed due to lack of interest.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Forster Other Goals<br>
- Embedded appliance is something which should be encouraged (beyond<br>
storage-only appliances)<br></blockquote><div><br></div><div>So build one. All the tools are available to you.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Expansion into other architectures to offer embedded hosting<br>
opportunities (i.e. ARM, POWER, MIPS)<br></blockquote><div><br></div><div>Seriously? There have been efforts to get ARM working, but a<br>platform port is a significant endeavour and I think we've already<br>noted that the available resources in the community are relatively<br>
limited.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Revisit of embedded ZFS (tiny ZFS was a discussion back in the Sun days)<br></blockquote><div><br></div><div>Again, if this is important, someone will step up and do the<br></div><div>work.<br><br></div><div>It's very darwinian, and that's the way it should be. Features<br>
</div><div>that matter survive, features that have nobody interested in them<br></div><div>(or where the interested people are unwilling to help) will wither<br>and die.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, Feb 13, 2014 at 5:35 AM, Joerg Schilling<br><div><div>
<<a href="mailto:Joerg.Schilling@fokus.fraunhofer.de" target="_blank">Joerg.Schilling@fokus.fraunhofer.de</a>> wrote:<br>
> seth Nimbosa <<a href="mailto:darth.serious@gmail.com" target="_blank">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></div></div></blockquote><div><br></div><div>It's still there. What's the problem?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>
> - Keep support for a UFS root filesystem<br></div></div></blockquote><div><br></div><div>Works just fine.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>
> - Keep support for /usr being on a different FS than /<br></div></div></blockquote><div><br></div><div>That's pretty much irrelevant, as it's largely a distro issue<br>as to how bits are partitioned. (The /usr split is also one of<br>
those really odd architectural hangovers that no longer makes<br></div><div>much sense. It's more force of habit than solid architecture<br></div><div>that's keeping the separate /usr concept alive. I suspect there<br>
</div><div>are opportunities for significant change and improvement in<br></div><div>where we place the various bits.)<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>
> - 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. </div></div></blockquote><div><br></div><div>Having worked extensively on both system minimization<br></div><div>and split-/usr configurations, ksh93 was never an important<br>
part of the overall budget. If you're in a realm where single<br>megabytes matter (and I've been there) you're making<br></div><div>significant changes to the structure of the OS, and you<br>shouldn't expect a general-purpose operating system to<br>
minimize that far without making changes that wouldn't be<br>advisable in other contexts.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>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></div></div></blockquote><div><br></div><div>And the illumos bug ids are?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>
> 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. </div></div></blockquote><div><br></div><div>Why be SVR4 specific? The IPS manifests contain metadata, which<br></div><div>can trivially be imported by any other packaging system.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>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".</div></div></blockquote><div><br></div><div>I suspect that pkgadm is entirely the wrong place, and that improving<br></div><div>packaging lives a level above. (Think yum vs rpm.)<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div> There is also a plan to<br>
> allow longer names </div></div></blockquote><div><br></div><div>Ouch. 32 characters ought to be long enough. Just from the point<br>of readability, keeping them short ought to be encouraged, with long<br>forms in metadata.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>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></div></div></blockquote><div><br></div><div>Aside from the fact that OpenSolaris no longer exists, and thus<br></div><div>cannot have an ABI by definition, don't we actually have a stable<br>
ABI already?<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
> 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></div></div></blockquote><div><br></div><div>The first of which is simply you trying to ram your own personal<br>code down everybody else's throats, which I know I wouldn't accept.<br>
</div><div>The other examples are really a simple case of filing a bug, having<br>code review, and submitting an RTI. If you were actually interested<br></div><div>in collaboration rather than criticising the rest of the community for<br>
</div><div>failing to surrender to your every demand, you could do that today.<br><br></div></div>-- <br>-Peter Tribble<br><a href="http://www.petertribble.co.uk/" target="_blank">http://www.petertribble.co.uk/</a> - <a href="http://ptribble.blogspot.com/" target="_blank">http://ptribble.blogspot.com/</a>
</div></div>