Closed approved in PSARC today.
Frank.
This case was timeout on this Monday. I see there is no more discussion
on it, so updated the case material to reflect the changes suggested.
Stability level of '/usr/bin/unison' was changed from 'Committed' to
'Uncommitted', new case material was saved as 'spec.txt' in the case
directory.
The
Roland Mainz ???:
>Yan Xue Yang wrote:
>
>
>>Roland Mainz:
>>
>>
>>>Yan Xue Yang wrote:
>>>
>>>
Roland Mainz :
>Yan Xue Yang wrote:
>
>
>>Roland Mainz :
>>
>>
>>>Yan Xue Yang wrote:
>>>
>>>
>>
Yan Xue Yang wrote:
> Roland Mainz:
> >Yan Xue Yang wrote:
> >>Roland Mainz :
> >>>Yan Xue Yang wrote:
> Roland Mainz :
> >Yan Xue Yang wrote:
> >>Roland Mainz :
> >Which locale did you use (my main interest is whether non-UTF-8
> >multibyte encodings as used for zh_CN.GB18030 w
Joseph Kowalski ??:
> So this appropriate ocaml compilers is captured beside the Unison
> sources?
Yes.
Considering that it's not of general purpose usage, it will not be
delivered to end user.
Frank.
Hi Joseph,
My comments are inline, thanks.
Regards,
Bill
- Original Message -
From: "Joseph Kowalski"
To: "Frank Che"
Cc: ; "yan xue yang"
Sent: Thursday, April 03, 2008 2:52 AM
Subject: Re: PSARC 2008/212 Integrate Unison into Solaris
> Frank Che
yan xue yang wrote:
> We don't integrate a binary delivery into the sfwnv, but integrate the
> source code into sfwnv.
Sorry, I must of misread something. (Or did this change in the **long**
thread?)
> The following is the detail how the compilation
> is done:
>
> We'll putback the source code of
Frank Che wrote:
> Hi All,
>
> Here is a summary of issues discovered by now, as well as proposals from
> project team on these issues. If I missed any pending issues, please
> point it out.
>
> Also, I'd like to extend the timer of this case to 04/07/2008.
>
> Issue 1: Unison doesn't support ACL
Hi All,
Here is a summary of issues discovered by now, as well as proposals from
project team on these issues. If I missed any pending issues, please
point it out.
Also, I'd like to extend the timer of this case to 04/07/2008.
Issue 1: Unison doesn't support ACL or extended file attributes.
Pro
Bart Smaalders wrote:
> Garrett D'Amore wrote:
> > Hang on a sec. I think what I'm hearing is that it is now OK to accept
> > architecturally inferior software into Solaris if it already exists on
> > Linux.
> > ...
> > Are we just abdicating all engineering responsibility here, so that
> > Solar
Roland Mainz wrote:
> ... maybe it would be usefull to have some kind of "standard form" for
> ARC cases which asks the following things (examples... AFAIK there are
> more things which should be asked):
At least 20 things :-)
http://opensolaris.org/os/community/arc/handbook/questionnaire/
Speci
"Garrett D'Amore" wrote:
> Joerg Schilling wrote:
> > It may be a good idea to classify the software on Solaris but this should
> > be done based only on the quality and not based on just the origin.
> >
>
> I agree wholeheartedly, and never meant to imply that all software
> written from S
Don Cragun wrote:
> We do it all the time. Have you forgotten that the cp, ln, and mv
> utilities are linked? There are currently 90 links to /usr/bin/ksh93
> on jurassic-x4600. I personally have hard links to several files under
> my home directory; they are not multi-gigabyte files, but the
>
Bart Smaalders wrote:
> You mean like an editor that won't work on terminals wider than
> 160 characters? (that was Sun's vi until S10)... you mean like a version
> of awk that breaks if the lines are longer than (gasp) 255 characters?
> Like a packaging system that cannot handle installing dep
"Garrett D'Amore" wrote:
> The fundamental problem I have with that, is that when software that is
> inferior (perhaps greatly so) is located in /usr/bin, the user has *no*
> way to distinguish between "first class" software developed at Sun's
> traditional quality standards, and various crapw
Roland Mainz:
>Yan Xue Yang wrote:
>
>
>>Roland Mainz :
>>
>>
>>>Yan Xue Yang wrote:
>>>
>>>
Roland Mainz :
>Yan Xue Yang wrote:
>
>
>>Roland Mainz :
>>
>>
>[snip]
>
>
>Which locale did you use (my main interest
>Do you have an "AT&T" Source to check? I did not see a single SVr3 installation
>without symlinks. They have however been unusable because there only was a
>symlink(1) command and the symlink(2) syscall instead of "ln -s" and with
>ls(1)
>you could only guess that there have been symlinks beca
Andrew Gabriel wrote:
> Joerg Schilling wrote:
> > Casper.Dik at sun.com wrote:
> >
> >> Symlinks didn't exist until SVR4 got them from BSD so I'm not sure what
> >> the point is (symlinks take a lot more diskspace)
> >
> > As I did already mention, this is definitely wrong.
> >
> > SVR3 did s
Please stop this completely offtopic conversation in the review of this
case. It is totally irrelevant to the ARC review of this project and
completely annoying.
--
Darren J Moffat
Casper.Dik at sun.com wrote:
> Symlinks didn't exist until SVR4 got them from BSD so I'm not sure what
> the point is (symlinks take a lot more diskspace)
As I did already mention, this is definitely wrong.
SVR3 did support symlinks, it did not have lstat()
J?rg
--
EMail:joerg at schily.
Joerg Schilling wrote:
> Casper.Dik at sun.com wrote:
>
>> Symlinks didn't exist until SVR4 got them from BSD so I'm not sure what
>> the point is (symlinks take a lot more diskspace)
>
> As I did already mention, this is definitely wrong.
>
> SVR3 did support symlinks, it did not have lstat()..
>Joseph Kowalski wrote:
>> Garrett D'Amore wrote:
>> >> 4.3.4 Unison does not understand hard links.
>> > That's pretty unfortunate. I guess the necessary consequence of this
>> > is that Unison my dramatically increase the bandwidth needs and
>> > storage needs on the remote side. Imagine synch
Joerg Schilling wrote:
> "Garrett D'Amore" wrote:
>
>
>> The fundamental problem I have with that, is that when software that is
>> inferior (perhaps greatly so) is located in /usr/bin, the user has *no*
>> way to distinguish between "first class" software developed at Sun's
>> traditional q
Joseph Kowalski wrote:
> Roland Mainz wrote:
> >
> > Huh ? Could you please give further details on the relationship between
> > AT&T and hardlinks ?
> >
> Just history. Pre-SVr4, there were no symlinks in the AT&T primortial
> UNIX. They
> came from the SunOS4.x/SVr3 merge.
You could crea
Joseph Kowalski wrote:
> Garrett D'Amore wrote:
> >> 4.3.4 Unison does not understand hard links.
> > That's pretty unfortunate. I guess the necessary consequence of this
> > is that Unison my dramatically increase the bandwidth needs and
> > storage needs on the remote side. Imagine synchronizin
On Thu, Mar 27, 2008 at 7:22 PM, Joseph Kowalski wrote:
> Shawn Walker wrote:
> > If I am given a tool to synchronise files, and not warned about its
> > deficiencies relative to Solaris support, I would be one very unhappy
> > customer when it didn't work as expected.
> >
> In general, I actu
On Thu, Mar 27, 2008 at 6:17 PM, Edward Pilatowicz
wrote:
> On Thu, Mar 27, 2008 at 05:01:29PM -0500, Shawn Walker wrote:
> > On Thu, Mar 27, 2008 at 3:01 PM, Joseph Kowalski wrote:
> > > 2) Go back to the original FOSS integration cases.
> > > There was significant discussion abou
Shawn Walker wrote:
> If, for example, Sun were to ship a utility (such as a utility to
> change file owner) that when run, might cause me to lose all
> permission or ACL information, I feel as though I would have a right
> to be angry even if it was documented. Why would Sun ship such a
> hypothet
>you categorization of unison as "inferior FOSS" is totally subjective
>and inappropriate. unison is a wonderful tool that does exactly what
>it was designed todo. i'm a huge fan of high-quality software (go read
>my bug reports if you don't believe me) and i've been using unison on
>a daily ba
On Thu, Mar 27, 2008 at 3:01 PM, Joseph Kowalski wrote:
> 2) Go back to the original FOSS integration cases.
> There was significant discussion about this. It was
> decided that Sun had no right to make quality
> judgments about the quality of FOSS contributions
>
On Thu, Mar 27, 2008 at 05:01:29PM -0500, Shawn Walker wrote:
> On Thu, Mar 27, 2008 at 3:01 PM, Joseph Kowalski wrote:
> > 2) Go back to the original FOSS integration cases.
> > There was significant discussion about this. It was
> > decided that Sun had no right to make qual
Yan Xue Yang wrote:
> Roland Mainz :
> >Yan Xue Yang wrote:
> >>Roland Mainz :
> >>>Yan Xue Yang wrote:
> Roland Mainz :
[snip]
> >>>Which locale did you use (my main interest is whether non-UTF-8
> >>>multibyte encodings as used for zh_CN.GB18030 will work or not...) ?
> >>
> >>I used zh_CN.UT
Roland Mainz wrote:
>
> Huh ? Could you please give further details on the relationship between
> AT&T and hardlinks ?
>
Just history. Pre-SVr4, there were no symlinks in the AT&T primortial
UNIX. They
came from the SunOS4.x/SVr3 merge.
- jek3
Shawn Walker wrote:
> On Thu, Mar 27, 2008 at 3:01 PM, Joseph Kowalski wrote:
>
>> 2) Go back to the original FOSS integration cases.
>> There was significant discussion about this. It was
>> decided that Sun had no right to make quality
>> judgments about the quali
It has been noted that...
> Joseph Kowalski wrote:
>
>> 3) Its my belief that some FOSS contributions far
>>Sun contributions.
>
> I think you missed one or two vital words in this sentence ... I
> *think* you meant sth akin to "are far superior to", but please
> elaborate.
Yep, that
Thank you!
- jek3
Edward Pilatowicz wrote:
> On Thu, Mar 27, 2008 at 08:50:50AM -0700, Garrett D'Amore wrote:
>
>> Nicolas Williams wrote:
>>
>>> On Tue, Mar 25, 2008 at 08:14:55AM -0400, James Carlson wrote:
>>>
>>>
I think the ARC would be derelict in its duty if it simply
On Thu, Mar 27, 2008 at 08:50:50AM -0700, Garrett D'Amore wrote:
> Nicolas Williams wrote:
> >On Tue, Mar 25, 2008 at 08:14:55AM -0400, James Carlson wrote:
> >
> >>I think the ARC would be derelict in its duty if it simply said "FOSS
> >>means no expectation of source change." That may be true of
Roland Mainz :
>Yan Xue Yang wrote:
>
>
>>Roland Mainz :
>>
>>
>>>Yan Xue Yang wrote:
>>>
>>>
Roland Mainz :
>[snip]
>
>
>What about filenames with multibyte characters (e.g. chinese characters
>using the zh_CN.GB18030 locale or japanese using the ja_JP.
Roland Mainz :
>Yan Xue Yang wrote:
>
>
>>Roland Mainz :
>>
>>
>>>[snip]
>>>
>>>
It's not documented in the manual. After testing, I confirm unison
doesn't support both ACL's and extended attributes. I think we need to
add this to man page.
>>>What about f
Garrett D'Amore wrote:
> How does the consumer (in this case the user) know whether unison is a
> "core OS feature", or some integration of perhaps lesser-quality or
> otherwise inferior FOSS?
>
>-- Garrett
OK, I'd still like this moved to another thread, but...
1) The Attributes section
Garrett D'Amore wrote:
> Hang on a sec. I think what I'm hearing is that it is now OK to accept
> architecturally inferior software into Solaris if it already exists on
> Linux.
> ...
> Are we just abdicating all engineering responsibility here, so that
> Solaris will ultimately become a mis
This is no longer about Unison. Its about whose opinion counts when
making integration decisions.
As per Plocher, this belongs on its own thread. If such a thread is
created, I'd be happy to contribute.
- jek3
Garrett D'Amore wrote:
> Joseph Kowalski wrote:
>>
>> OK, I've gotten a couple o
Nicolas Williams wrote:
> On Tue, Mar 25, 2008 at 08:14:55AM -0400, James Carlson wrote:
>
>> I think the ARC would be derelict in its duty if it simply said "FOSS
>> means no expectation of source change." That may be true of some
>> projects, but certainly not of others, and the ARC should no
Joseph Kowalski wrote:
>
> OK, I've gotten a couple of private messages about this. I was
> clearly unclear in what I said.
>
> My issue is that if this is "good enough" for the community (of Linux
> users), this is good enough to allow this to be integrated into
> Solaris. Sure, we have no id
Yan Xue Yang wrote:
> Roland Mainz :
> >Yan Xue Yang wrote:
> >>Roland Mainz :
[snip]
> >>>What about filenames with multibyte characters (e.g. chinese characters
> >>>using the zh_CN.GB18030 locale or japanese using the ja_JP.PCK locale) ?
> >>>How does "Unison" handle such things ?
> >>>
> >>>
>
Gary Winiger wrote:
> [Not architectural, but likely PAC advice]
> Doesn't being Committed and having no upstream "owner" in effect
> mean that the submitters management chain is signed up to maintain
> and fix bugs until EOF? Is the submitters management chain aware
>
Roland Mainz :
>[snip]
>
>
>>It's not documented in the manual. After testing, I confirm unison
>>doesn't support both ACL's and extended attributes. I think we need to
>>add this to man page.
>>
>>
>
>What about filenames with multibyte characters (e.g. chinese characters
>using the zh_CN.G
Gary Winiger ???:
>>>If there is a server, how is it administered, if at all?
>>>
>>>
>>Yes, the project adheres to the Secure By Default rule. It's up to the
>>user to choose which method is going to be used(ssh method, rsh method
>>or socket method) when user executes the command unison.
>
Gary Winiger ???:
>>No. Only a binary file and a man page will be delivered.
>>
>>
>
> I'm not sure what is meant here. Is it that a binary file
> will be integrated into some consolidation (such as SFW)
> that is prebuilt? What would the build environment be for
> Re
Alan Coopersmith ???:
>Yan Xue Yang wrote:
>
>
>>Alan Coopersmith ???:
>>
>>
>>>Frank Che wrote:
>>>
>>>
>>>
>>>
4.3.2 When synchronize between a single-user file system and a shared
Unix
server, by default, Unison will synchronize permissions verbatim,
which may
l
I did some work with unison a while back. Actually I had started
preparing a case like LSARC/2006/222 which would have brought unison
onto the system, but that project never got far enough (I believe
LSARC/2006/222 is the result of a successor project).
From that background some remarks, parti
Yan Xue Yang wrote:
> Roland Mainz :
> >[snip]
> >>It's not documented in the manual. After testing, I confirm unison
> >>doesn't support both ACL's and extended attributes. I think we need to
> >>add this to man page.
> >
> >What about filenames with multibyte characters (e.g. chinese characters
>
Yan Xue Yang wrote:
> Alan Coopersmith ?:
> >Yan Xue Yang wrote:
> >>Alan Coopersmith ?:
> >>>Frank Che wrote:
[snip]
> It's not documented in the manual. After testing, I confirm unison
> doesn't support both ACL's and extended attributes. I think we need to
> add this to man page.
> > If there is a server, how is it administered, if at all?
>
> Yes, the project adheres to the Secure By Default rule. It's up to the
> user to choose which method is going to be used(ssh method, rsh method
> or socket method) when user executes the command unison.
If I understand there
> No. Only a binary file and a man page will be delivered.
I'm not sure what is meant here. Is it that a binary file
will be integrated into some consolidation (such as SFW)
that is prebuilt? What would the build environment be for
Release Engineering (or OpenSola
Nicolas Williams wrote:
>>>4.5.2 Exported Interfaces
>>> +--+
>>> |NAME | PROPOSED| DESCRIPTION |
>>> | | STABILITY LABEL ||
>>> +-
Hi Alan,
My comments are inlines. Thanks.
Regards,
Bill
Alan Coopersmith ???:
>Frank Che wrote:
>
>
>>4.3.2 When synchronize between a single-user file system and a shared Unix
>>server, by default, Unison will synchronize permissions verbatim, which may
>>leave group-writable files on the ser
Hi Garrett,
My comments are inlines. Thanks
Regards,
Bill
Garrett D'Amore ???:
> Frank Che wrote:
>
>>
>> 4.2 Security concerns:
>> Security becomes a concern when synchronizing files across network.
>> Unison
>> provides two methods for communicating between the client and the
>> server:
>>
>>
No. Only a binary file and a man page will be delivered.
Frank.
Joep Vesseur wrote:
>As Unison is written in Occam, does this case propose to include some
>form of Occam compiler as well? The occaml compiler normally advertised to
>compile Unison with is distributed under the Q-license which mig
James Carlson wrote:
> Roland Mainz writes:
> > Sarcastic comment of the day: Yeah... I remember how it was done "right"
> > ([1]) in the case of /usr/bin/ksh ... =:-)
>
> You'll need to try harder to get a plonk. :-/
Erm... for the log: It wasn't my intention to offend anyone... I just
tried to
Roland Mainz wrote:
> Sarcastic comment of the day: Yeah... I remember how it was done "right"
> ([1]) in the case of /usr/bin/ksh ... =:-)
Be careful, some people here seem to believe that the ksh93 case was not done
right and like to unroll it ;-)
J?rg
--
EMail:joerg at schily.isdn.cs.tu-
James Carlson wrote:
> Roland Mainz writes:
> > > According to the message from the community web site, there is no active
> > > development on this product any more. While bug fixes, small
> > > improvements and contributed patches may come. So I suggested to use
> > > Committed level. If members
Joep Vesseur wrote:
> On 03/25/08 12:44, Roland Mainz wrote:
> >> The occaml compiler normally advertised to
> >> compile Unison with is distributed under the Q-license which might be
> >> a novum for OpenSolaris.
> >
> > What's the exact problem ? Occam may have some use for Niagara-class
> > mach
On 03/25/08 12:44, Roland Mainz wrote:
>> The occaml compiler normally advertised to
>> compile Unison with is distributed under the Q-license which might be
>> a novum for OpenSolaris.
>
> What's the exact problem ? Occam may have some use for Niagara-class
> machines...
I don't see a problem;
Joep Vesseur wrote:
>
> As Unison is written in Occam, does this case propose to include some
> form of Occam compiler as well?
Occam (I'm a bit suprised since I thought most of the legacy of the
Transputer stuff is long long gone (unfortunately)) ?
> The occaml compiler normally advertised to
>
Frank Che wrote:
> Nicolas Williams wrote:
[snip]
> >>I probably shouldn't repeat this, but I am again concerned about
> >>Committed for an application that seems to have a somewhat limited
> >>audience and may itself no longer be actively developed or maintained.
> >>(See http://www.cis.upenn.edu/
Gary Winiger writes:
> [Not architectural, but likely PAC advice]
> Doesn't being Committed and having no upstream "owner" in effect
> mean that the submitters management chain is signed up to maintain
> and fix bugs until EOF?
The questions just change in nature -- instead
Oh, never mind my comments.
On Tue, Mar 25, 2008 at 08:14:55AM -0400, James Carlson wrote:
> I think the ARC would be derelict in its duty if it simply said "FOSS
> means no expectation of source change." That may be true of some
> projects, but certainly not of others, and the ARC should not be
> presuming one magic answer
As Unison is written in Occam, does this case propose to include some
form of Occam compiler as well? The occaml compiler normally advertised to
compile Unison with is distributed under the Q-license which might be
a novum for OpenSolaris.
Joep
> > Erm..."devils advocate" question: If Unison is no longer maintained...
> > why should it be integrated into (Open)Solaris ? And how do other OSes
> > (like Linux) handle the support issue (e.g. no upstream where they can
> > send the bug reports to) ?
>
> No upstream change is (perversely eno
Roland Mainz writes:
> Sarcastic comment of the day: Yeah... I remember how it was done "right"
> ([1]) in the case of /usr/bin/ksh ... =:-)
You'll need to try harder to get a plonk. :-/
> > and don't have to worry so much about any costs due to
> > forking from or contributing to the upstream .
Roland Mainz wrote:
> Erm..."devils advocate" question: If Unison is no longer maintained...
> why should it be integrated into (Open)Solaris ? And how do other OSes
> (like Linux) handle the support issue (e.g. no upstream where they can
> send the bug reports to) ?
>
I see that there has been
Nicolas Williams writes:
> The ARC should want to make sure that Unison's shortcomings are properly
> documented. The ARC can't expect i-teams to fix the FOSS they are
> integrating -- only the how it is integrated.
Really?
I don't think that's true. I think it's right and proper for the ARC
to
Roland Mainz writes:
> > According to the message from the community web site, there is no active
> > development on this product any more. While bug fixes, small
> > improvements and contributed patches may come. So I suggested to use
> > Committed level. If members think this is not proper, pleas
John Plocher wrote:
> Joseph Kowalski wrote:
>> My issue is that if this is "good enough" for the community (of Linux
>> users), this is good enough to allow this to be integrated into Solaris.
>
> Uhm.
>
> If it is good enuf for Linux, it most certainly should be available
> for use on (O
Yan Xue Yang wrote:
> Alan Coopersmith ???:
>> Frank Che wrote:
>>
>>
>>> 4.3.2 When synchronize between a single-user file system and a shared
>>> Unix
>>> server, by default, Unison will synchronize permissions verbatim,
>>> which may
>>> leave group-writable files on the server that could be w
I'm sponsoring this fast-track case for Bill Yan. This case is to
integrate an open source file synchronizer 'unison' into Solaris.
A draft man page of this tool was put in the case directory.
The requested binding is patch/micro. The timer is set to 03/31/2008.
-Frank
4. Technical Description
Joseph Kowalski wrote:
> My issue is that if this is "good enough" for the community (of Linux
> users), this is good enough to allow this to be integrated into
> Solaris.
Uhm.
If it is good enuf for Linux, it most certainly should be available
for use on (Open)Solaris, but that is not
On Mon, Mar 24, 2008 at 09:35:20AM -0700, Garrett D'Amore wrote:
> >contents of your file system! The socket method is provided only for
> >expert users with specific needs; everyone else should use the remote
> >shell (ssh) method.
> I presume that if there is a server here, it is not
>Date: Mon, 24 Mar 2008 11:41:02 -1000
>From: Joseph Kowalski
>
>Garrett D'Amore wrote:
>>> 4.3.4 Unison does not understand hard links.
>>
>> That's pretty unfortunate. I guess the necessary consequence of this
>> is that Unison my dramatically increase the bandwidth needs and
>> storage needs
Garrett D'Amore wrote:
> Frank Che wrote:
>>
>> 4.2 Security concerns:
>> Security becomes a concern when synchronizing files across
>> network. Unison
>> provides two methods for communicating between the client and the
>> server:
>>
>> * Remote shell method: To use this method, you
OK, I've gotten a couple of private messages about this. I was clearly
unclear in what I said.
My issue is that if this is "good enough" for the community (of Linux
users), this is good enough to allow this to be integrated into
Solaris. Sure, we have no idea how much this will bother Solari
Garrett D'Amore wrote:
>> 4.3.4 Unison does not understand hard links.
>
> That's pretty unfortunate. I guess the necessary consequence of this
> is that Unison my dramatically increase the bandwidth needs and
> storage needs on the remote side. Imagine synchronizing a 4G ISO
> image, which al
Should this supersede LSARC/2006/222?
Danek
Frank Che wrote:
> 4.3.2 When synchronize between a single-user file system and a shared Unix
> server, by default, Unison will synchronize permissions verbatim, which may
> leave group-writable files on the server that could be written over by a
> lot of
> people.
Are permissions copied correctly
Frank Che wrote:
>
> 4.2 Security concerns:
> Security becomes a concern when synchronizing files across
> network. Unison
> provides two methods for communicating between the client and the
> server:
>
> * Remote shell method: To use this method, you must have some way of
> invok
87 matches
Mail list logo
