[oi-dev] oi_151a9 roadmap & planning

[Joerg Schilling]

Peter Tribble <peter.tribble at gmail.com> wrote:

> First, you need to stop saying "must" and attempting to
> dictate design and implementation decisions.

Well it would be great if some people at Illumos would not try to dictate 
things but signal that there is an interest for a collaboration. 

>
> > Well....
> >
> > -       IPS must not be the only packaging
> >
>
> It isn't. There are distros using SVR4, dpkg, rpm, IPS, pkgsrc,
> and/or no packaging at all.

Well, where is the SVr4 package meta data in Illumos?
Note that IPS meta data is limited compared to Svr4 package meta data and for 
this reason, there is no way to convert meta data correctly.


> > -       /sbin/sh may be a link to the Bourne Shell
> >
>
> Why is this relevant to collaboration?

Because for being able to collaborate, we need to have a common understanding 
of what is preventing collaboration. This results in avoiding changes that 
prevent collaboration.

> This is a good example of where collaboration matters. If this is
> important to you, and you want the system to behave correctly
> with an alternate /sbin/sh, then log bugs against illumos,
> preferably with fixes. However, as with all projects, if having
> it fixed matters to you, you have to do the work.

Illumos would need to verify first that Illumos is collaborative.
Currently we have the unfortunate state that Illumos did not include some 
software even though this was promised and a code review has been presented.
Colaboration of course also means that partners are trustworthy and implement 
promises.

Once Illumos turned into a trustworthy and collaborative entity, it makes of 
curse sense to file bugs against Illumos. 

> -       scripts need to be open for being able to mount /usr using
> >         the Bourne Shell.
> >
>
> We're off into the realms of distro-specific implementation artefacts.
> This sort of statement doesn't even make sense for some distros,
> and the concept it refers to isn't part of illumos at all.

I am sure whether you understand what collaboration is... if we like to share 
important scripts, we need to have a common understanding of what others are 
interested in. Specific changes at one side may prevent collaboration at 
certain points and this is such a point.

Being able to have native (SVr4 package based) zones on all distros would be 
another thing to look at.

In any case, collaboration means that one distro does not dictate constraints 
that affect other distros.

>
> > -       We need to find a way for versioned libraries to support
> >         as much binary compatibility as possible.
> >
>
> That's how shared libraries, versions, mapfiles, and filters
> work. But again, this is largely irrelevant - binary compatibility
> has often been out of fashion in many open source projects, so
> it's not a problem we can solve. And it's a much smaller part of
> the overall compatibility question - what versions of interpreters
> are present, what build options were chosen, where are applications
> installed?

If we like to collaborate, we need to decide whether there should be binary 
compatibility. I remember that in the late 1990s, Linux was so fragmented, that 
it was impossible to run a binary on distro a if it was compiled for distro b.
OpenSolaris has a much smaller community and I am not sure whether OpenSolaris 
will survive too much fragmentation.

Jörg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily