Collaboration Criteria: - The original promise was for both Intel & SPARC in the community, that promise should be kept.
Forster Other Goals - Embedded appliance is something which should be encouraged (beyond storage-only appliances) - Expansion into other architectures to offer embedded hosting opportunities (i.e. ARM, POWER, MIPS) - Revisit of embedded ZFS (tiny ZFS was a discussion back in the Sun days) (article on small solaris, small zfs, and embedded opportunities from 2011) http://netmgt.blogspot.com/2011/12/small-solaris.html 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 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) > > - 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 > ------------------------------------------- > illumos-discuss > Archives: https://www.listbox.com/member/archive/182180/=now > RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175845-b97465aa > Modify Your Subscription: https://www.listbox.com/member/?&; > Powered by Listbox: http://www.listbox.com ------------------------------------------- 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
