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

Garrett D'Amore garrett at damore.org
Sat Aug 7 16:59:46 PDT 2010


I am going to be VERY clear here.

Illumos has no goal of a single binary busybox like ksh93 system.  It isn't part of our core values.  If a distro wants to build such a system they are of course welcome to do so.

I don't put much faith in long term commitments made by vendors... the recent history with sun, oracle, and even apple tells me that any such promises should be taken with some skepticism unless backed by an iron clad contract.  Even the best intentions can be overruled by business realities.

That said, the team behind FreeBSD (and by extension Apple) are at least as credible to me as the AT&T team.  Maybe moreso since they actually still offer OS products.  The FreeBSD code is functional *and* portable.  And has been certified.

A decision to integrate an implementation is not irreversable.  We will always remain free to select a better implementation if just cause can be made, and any compatibility concerns addressed.

All parties here need to recognize that compromise means nobody gets everything they want.   If you view integration of your shell or archiver as the only reasonable choice, your not acting in a spirit of collaboration, and you'll ultimately be disappointed.  No one team has a monopoly on talent or excellent code.

The fbsd implementation that was presented to me was done before anyone even knew ast sed was in progress.

I hope the ast team does not really believe that integration of FreeBSD sed or even star pax invalidates all their other work for the past two years.

  -- Garrett, your hopefully benevolent dictator


Roland Mainz <roland.mainz at nrubsig.org> wrote:

>On Sat, Aug 7, 2010 at 10:01 PM, Garrett D'Amore <garrett at nexenta.com> wrote:
>> Roland Mainz <roland.mainz at nrubsig.org> wrote:
>>
>>>On Sat, Aug 7, 2010 at 4:59 PM, Garrett D'Amore <garrett at nexenta.com> wrote:
>>>> Joerg.Schilling at fokus.fraunhofer.de wrote:
>>>>>"Garrett D'Amore" <garrett at damore.org> wrote:
>>>>>> I'm planning on importing FreeBSD sed, if there is a reason I should NOT do this, I would like to hear it.
>>>>>
>>>>>Since the test I was interested in did already pass FreeBSD-sed,
>>>>>I know of no issue that could prevent this.
>>>>
>>>> Roland, Olga, any objections?
>>>
>>>Erm... I have a few objections:
>>>1. I am very unhappy about Joerg pushing something where people like
>>>Olga, me or the AT&T folks are currently busy with other things and
>>>have explicitly announced this. Instead of giving us some time it
>>>_feels_ like we're getting facts while the majority of other userland
>>>developers can't object fully or provide an alternative.
>>>
>>>2. I am concerned about the ongoing splintering of the user interface.
>>>Instead of having one more or less integrated user interface from one
>>>upstream we're pulling a giant jigsaw from multiple sources together.
>>>
>>>3. We already worked on getting AST "sed" closer to GNU sed without
>>>breaking POSIX/SUS conformance and getting it working as shell
>>>builtin. Picking another implementation technically kills that work
>>>
>>>4. As a _reminder_ for Joeg (this is the part where I am  ANGRY with
>>>Joerg for trying to break this): During the first OpenSolaris
>>>conference John Plocher invitet a couple of people, including me, John
>>>Sonnenschein and a few others (AFAIK Al Hopper was there, too) to
>>>discuss the issue of the closed source and getting rid of it as part
>>>of the emancipation project. At the end (basically creating an accord,
>>>to avoid double-work and a fight about responsibilities) we decided a
>>>CLEAR split who is responsible for getting which userland part out of
>>>the closed part. The split was:
>>>Joerg is getting /usr/bin/tar and /usr/bin/star
>>>I, David Korn, Glenn Fowler, Irek Szczesniak and others work on
>>>/usr/(bin|xpg[46]/bin)/(tail|tr|sed|od), /usr/bin/printf,
>>>/usr/xpg4/bin/sh, /usr/bin/ksh and /usr/bin/pax (this was done to get
>>>all POSIX/SUS things and related conformance testing from one upstream
>>>with an uniform API, testing and a long term maintaince (AT&T's plans
>>>for AST&co. are funded for more than the next decade (and likely
>>>beyond)) and commitment plan) from a _cooperative_ _team_)
>>>
>>>I'm really upset about [4] right now...
>>
>> The sed proposal I'm making comes not from Joerg.  I do not feel we need the universe to be ksh93.
>
>ksh93 is only a tiny part (e.g. "sed" as builtin to get better
>performance and move towards a busybox-like integrated userland to
>enable the use of OpenSolaris on embedded platforms).
>More major parts is:
>- Who is doing the long-term maintaince (as said AT&T has long-term
>maintaince plans for AST which go beyond Glenn&&David)
>- Who is doing standard conformance testing (as a side-note: The test
>binaries I've send are from AT&T AST "head" and come from a different
>alpha branch than the originally tested stable branch (I just didn't
>expect that "tr" and "sed" in the alpha branch had issues. This is
>beting fixed right now))
>- Who is doing the porting to new architectures (if required) ?
>- Who is doing the bugfixing (e.g. AT&T AST is a funded effort within
>AT&T to provide a cross-platform toolchain for their own
>infratructure) ? Who cooperates with Illumos to get the bugs fixed (as
>said long ago AT&T has always been cooperative and even continued
>working for OpenSolaris even Sun management was generating cross-fire)
>?
>
>> FreeBSD sed works, and is the basis for a certified implementation.  So I want to hear technical objections only.
>
>Erm... I had a few of those, too.
>
>> Also, illumos is not bound by any prior decisions that may no longer be relevant.
>
>Grumpf... does that mean we have to throw two years of work away ?
>Just like that, for nothing ?
>
>----
>
>Bye,
>Roland
>
>-- 
>  __ .  . __
> (o.\ \/ /.o) roland.mainz at nrubsig.org
>  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
>  /O /==\ O\  TEL +49 641 3992797
> (;O/ \/ \O;)


More information about the Developer mailing list