Thank you Peter. Your reply was very well put. I had refrained from replying but it seems sanity prevails. :-)
Sent from my iPhone > On Feb 18, 2014, at 12:48 PM, Peter Tribble <[email protected]> wrote: > >> On Sun, Feb 16, 2014 at 9:38 PM, David H <[email protected]> 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 >> <[email protected]> wrote: >> > seth Nimbosa <[email protected]> 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/ > illumos-discuss | Archives | Modify Your Subscription ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
