[illumos-Developer] Closed-bin accords of the OpenSolaris conference... / was: Re: illumos_145 i386 build status

[Garrett D'Amore]

On Sun, 2010-08-08 at 21:15 +0200, Joerg Schilling wrote:
> "Matt Lewandowsky " <matt at greenviolet.net> wrote:
> 
> > Garrett, In all due respect, I think choosing FreeBSD's sed is not necessarily the wisest move at this point. Sun indicated that AST sed is their choice to replace the closed sed. I've not seen solid evidence that Oracle's changed that plan. (If there's been more than communications breakdowns, I'd be interested in links.) If/when Oracle actually replaces the closed sed, Illumos would then have to decide whether to ditch its FreeBSD sed (if you choose it), or whether to have a different sed from upstream. The former choice is a waste of time and effort, and the latter goes against "not forking for forking's sake". (Paraphrase, not actual quote.) Roland and Olga have put a lot of work into a project that's been approved by Illumos's upstream (Sun/Oracle), and w which has made many putbacks over its life, and is on a path to a tangible and worthwhile (if nothing more than an implementation detail to most people) goal. Right now, they may be having issues with communication with Oracle. But they're not the only ones; paying customers are too. In my opinion, choosing a different implementation than Sun/Oracle has already favored should be done only if you have good reason to believe that Roland and Olga's work will no longer be accepted by Oracle. I was under the impression that Illumos was going to try to remain as compatible as possible to upstream ON. The best indication given by upstream so far has been that AST sed would be "the" sed at some point. Bearing these two points in mind, this whole conversation seems silly and bordering upon barnshedding. --Matt Sent from my HTC Touch Pro2 on the Now Network from Sprint?.
> >
> 
> Matt, we had a proposal for testing from Roland, the software was tested and 
> it turned out there are bugs that prevent integration.

More than that; the sed work is basically done, by someone else, and I'm
ready to move forward with it.  The SED DECISION IS CLOSED FOR FURTHER
DEBATE UNLESS SOMEONE IS ABLE TO BRING COMPELLING NEW INFORMATION TO
JUSTIFY REOPENING IT.   Sorry to put my foot down on this, but further
discussion on this matter is no longer constructive.

> 
> We do not have any statement on a possible time-frame for fixing the bugs but 
> we at Illumos have the goal to replace closed source applications by OSS as 
> soon as possible.

Right.

> 
> For sed, we seem to have a replacement proposal to use sed from FreeBSD
> and for pax we have a replacement proposal to use star. Both programs have been
> tested and there are currently no known issues.

The question of "pax" from star vs. AST is an open issue.  Each team has
said that the other's implementation is defective.  I frankly am not
interested in getting into a flamewar about this, and that is where the
current conversations seem headed.

As an aside, I personally find it utterly insane that ksh93 would put
pax functionality into libast -- the ast library seems to be growing
functionality that has less and less to do with "core shell
functionality" and more to do with world domination of ksh93.  The end
result is that libast is bigger for all unrelated uses (such as printf)
because it has to carry baggage associated with pax, etc.  I do wonder
when libast is going to grow the functionality of a c compiler, emacs,
or X server.  IMO libast and ksh93 have lost sight of the "do one simple
thing and do it well" philosophy of UNIX.  But I digress...

Now that I've got *that* off my chest, I do think that if the code is
ready in AST, I'd assume that we can use their implementation for pax.
The question of readiness and comparison between star vs. AST for this
usage is something that apparently I will have to mediate by testing
myself and verifying claims, since apparently the teams behind each
cannot seem to agree even that claims are reproducible.

So I WILL MAKE THE FINAL DECISION ON pax.  And I will do my best to be
as entirely objective as I can.  I do not want to hear any more debate
on this particular issue -- I will be contacting the parties out of band
to collect implementation bits and test cases.  PLEASE TAKE ANY FURTHER
DISCUSSION OF PAX AND SED OUT OF BAND AND ADDRESS CONCERNS TO ME
DIRECTLY.  Further discussion here is disruptive, and so needs to cease.

As far as tar/cpio, it seems like star is the obvious choice, if the
code in ON already is either closed or otherwise unusable.

I do think we can integrate star as star in illumos.  We'll work to that
end soon, I think.

(Of course a bigger level 0 is whether or not any of these archivers
really belong in "ON" proper.  I'd argue that they all could, and
should, reside in the separate "Userland" consolidation.  But that's a
different matter to be tackled later.)

	-- Garrett
> 
> For FreeBSD sed, I would like to see a binary that allows testing on Solaris.
> If I could test a FreeBSD sed binary on Solaris without problems, I am willing 
> to give my OK for integration instantly.
> 
> For star, the Solaris ON integration is already available at:
> 
> 	ftp://ftp.berlios.de/pub/star/alpha/star-on.tar.xz
> 
> This archive does not replace anything, it only adds star.
> 
> BTW: star already implements most of Sun's extensions and the missing ones will
> follow soon after the integration happened. ast-pax currently does not support 
> any of the Sun extensions. If you like to replace /usr/bin/pax by star, you 
> just need to add a line to usr/src/cmd/star/Makefile to create a link between
> star and the name "pax".


> 
> I suspect that Oracle currently has no plan to replace the closed source bits 
> in OpenSolaris anytime soon. We need to avoid to get into a similar position as
> the OGB by waiting om soemthing that may not happen at all. It seems that we
> need to find a way for Illumos anyway. Could this be done by the simple rule:
> it needs to be available and it needs to be without known issues that may cause
> problems for existing users of the software.



> 
> 
> 
> Let me add a side note on the CPL (the license used by the ast code ). I know 
> that the license is not a result of a decision from David Korn but from AT&T. 
> The CPL however is a license that is indented to keep software projects 
> separate. There is permission to contribute to the original work:
> 
> See: http://www.osscc.net/en/licenses.html#compatibility
> http://www.osscc.net/en/cpl.html
> 
> but there is no permission to use parts from a CPLd work in other works.
> 
> 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
> 
> _______________________________________________
> Developer mailing list
> Developer at lists.illumos.org
> http://lists.illumos.org/m/listinfo/developer