Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Shawn Walker]

On Feb 8, 2008 4:04 AM, Joerg Schilling
<[EMAIL PROTECTED]> wrote:
> Chris Linton-Ford <[EMAIL PROTECTED]> wrote:
> > I'm afraid I'm no POSIX expert, so I'm not clear on whether the
> > Bourne/Korn test below implies POSIX compatibility *only* if Korn-style
> > is returned; but if using a POSIXy shell for /sbin/sh will cause
> > widespread Windows Update-style brokenness then this should be a clear
>
> This test verifes no more than that there is no unique behavior with /bin/sh
> on other platforms (in contrary to what was claimed by Shawn).

I have made no such claim Joerg. You misunderstood me.
-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Casper . Dik]

>As the terrm "multi-command pipeline" is not defined, it is questionable what 
>this text should mean

It's a pipeline with more than one command as directly follows from the 
pipeline definition.

A pipeline is a sequence of one or more commands separated by
the control operator '|'.


>If it makes sense to define a "multi-command pipeline" at all, it needs to be 
>different from a simple pipeline.
>
>"cat from-file | read value" is doubtlessly a simple pipeline ;-)


I take your smiley to mean that we agree that both behaviors are POSIX 
compliant?


Casper

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

[EMAIL PROTECTED] wrote:

>
>
> >
> >You cannot look at too few claims from POSIX.
> >
> >the definitions for read say that read affects the shell execution 
> >environment
> >unless it is run on a sub shell.
> >
> >As in "cat from-file | read value" the read command is not run in a sub shell
> >environment, it needs to affect the environment.
>
>
> You should not have deleted the rest of my email which clearly quotes
> the standard saying:
>
>   Additionally, each command of a multi-command pipeline is in a subshell
>   environment; as an extension, however, any or all commands in a pipeline
>   may be executed in the current environment. All other commands shall be
>   executed in the current shell environment.

As the terrm "multi-command pipeline" is not defined, it is questionable what 
this text should mean

If it makes sense to define a "multi-command pipeline" at all, it needs to be 
different from a simple pipeline.

"cat from-file | read value" is doubtlessly a simple pipeline ;-)

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Casper . Dik]

>
>You cannot look at too few claims from POSIX.
>
>the definitions for read say that read affects the shell execution environment
>unless it is run on a sub shell.
>
>As in "cat from-file | read value" the read command is not run in a sub shell
>environment, it needs to affect the environment.


You should not have deleted the rest of my email which clearly quotes
the standard saying:

Additionally, each command of a multi-command pipeline is in a subshell
environment; as an extension, however, any or all commands in a pipeline
may be executed in the current environment. All other commands shall be
executed in the current shell environment.

 "read value" IS part of a *pipeline* and therefor it normally runs
 in a subshell but an implementation MAY chose to not run it in a subshell
AS AN EXTENSION.


There is no ambiguity.  Both Bourne, bash and ksh get this "right" because
there's no one right way of doing this.

Casper



___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Casper . Dik]

>[EMAIL PROTECTED] wrote:
>
>>
>>
>> >Cheers - I just wanted to check that Bourne-style => non-POSIX (rather
>> >than Korn-style <=> POSIX)
>>
>> That is actually unclear to me; certainly I would like to have chapter and 
>> verse quoted of the relevant POSIX standard.
>>
>> I certainly believe that this should work:
>>
>>  read value < from-file
>>
>> but I'm not sure that this should work:
>>
>>  cat from-file | read value
>
>Shell command language 2.9.2 defines that the shell shall wait for the last 
>command specified in the pipeline. This defines the last command as 
>"foreground"
>command and others as "background commands".


Your assertion "This defines " has no basis; the shell document does 
not contain a definition of "foreground command" and therefor it is 
difficult to see where you get the implication.  The only mention of
foreground command is in the case of signal handling.

Section 2.9.2 says:

 2.9.2 Pipelines

A pipeline is a sequence of one or more commands separated by the control 
operator '|'. The standard output of all but the last command shall be 
connected to the standard input of the next command.

The format for a pipeline is:

[!] command1 [ | command2 ...]

The standard output of command1 shall be connected to the standard input of 
command2. The standard input, standard output, or both of a command shall be 
considered to be assigned by the pipeline before any redirection specified by 
redirection operators that are part of the command (see Redirection).

If the pipeline is not in the background (see Asynchronous Lists), the shell 
shall wait for the last command specified in the pipeline to complete, and may 
also wait for all commands to complete.



[ end ]

So all it really says is that:
- the shell needs to wait until at least the last command is
  executed (this is required by the mere fact that it needs to
  return the status of the last command)


Now if we look at section 2.10 it says:

(About  command substituations, (cmd), cmd & being in subshells
Additionally, each command of a multi-command pipeline is in a subshell
environment; as an extension, however, any or all commands in a pipeline
may be executed in the current environment. All other commands shall be
executed in the current shell environment.


This states clearly and unambiguously that in the following case:

foo="POSIX-conformant"; echo POSIX-conformant-too | read foo; echo $foo


it's legal to echo BOTH "POSIX-conformant" and "POSIX-conformant-too"

The wording is clear:

echo something | read foo

may be implemented equivalent to:

(echo something) | (read foo)
or even
(echo something | read foo)

The Korn shell's behaviour is clearly noted as an extension.

Casper






___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

[EMAIL PROTECTED] wrote:

>
> >[EMAIL PROTECTED] wrote:
> >
> >>
> >>
> >> >Cheers - I just wanted to check that Bourne-style => non-POSIX (rather
> >> >than Korn-style <=> POSIX)
> >>
> >> That is actually unclear to me; certainly I would like to have chapter and 
> >> verse quoted of the relevant POSIX standard.
> >>
> >> I certainly believe that this should work:
> >>
> >>read value < from-file
> >>
> >> but I'm not sure that this should work:
> >>
> >>cat from-file | read value
> >
> >Shell command language 2.9.2 defines that the shell shall wait for the last 
> >command specified in the pipeline. This defines the last command as 
> >"foreground"
> >command and others as "background commands".
>
>
> Your assertion "This defines " has no basis; the shell document does 
> not contain a definition of "foreground command" and therefor it is 
> difficult to see where you get the implication.  The only mention of
> foreground command is in the case of signal handling.
>

You cannot look at too few claims from POSIX.

the definitions for read say that read affects the shell execution environment
unless it is run on a sub shell.

As in "cat from-file | read value" the read command is not run in a sub shell
environment, it needs to affect the environment.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Chris Linton-Ford]

stty erase ^h  
> 
> Not followed the whole discussion but above does not work?

It does - that's just made my Friday - cheers. Now for tab completion
and editable command history.. :)

Chris

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

[EMAIL PROTECTED] wrote:

>
>
> >Cheers - I just wanted to check that Bourne-style => non-POSIX (rather
> >than Korn-style <=> POSIX)
>
> That is actually unclear to me; certainly I would like to have chapter and 
> verse quoted of the relevant POSIX standard.
>
> I certainly believe that this should work:
>
>   read value < from-file
>
> but I'm not sure that this should work:
>
>   cat from-file | read value

Shell command language 2.9.2 defines that the shell shall wait for the last 
command specified in the pipeline. This defines the last command as "foreground"
command and others as "background commands".

As I did already mention the way our test command works depends on which
command in a pipeline is the foreground command and which is a background 
commans.

BTW: shall == must


Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Ken Gunderson]

On Fri, 08 Feb 2008 11:00:57 +
Chris Linton-Ford <[EMAIL PROTECTED]> wrote:

> > This test _only_ checks for one small and single aspect of POSIX vs. Bourne
> > compatibility. If you find a program like pdksh that intends to be POSIX
> > compatible to return "Bourne" with this test, it only proves that this
> > shell needs a major rewrite to become POSIX compliant.
> 
> But the consensus seems to be that if we use a POSIX compliant shell
> here we break backwards compatibility, so the lesser of the two evils is
> to leave standards-compliance to the guys in /usr/xpg4/bin and to add
> some timely updates to /sbin/sh.
> 
> 
> > Note that the test in question checks how the commandline parser and the
> > execution interpreter are written. It justs verifies that the pdksh 
> > parser/interpreter are not written in a POSIX compliant way because 
> > parsing/execution is done in the opposite order to what POSIX defines.
> 
> Cheers - I just wanted to check that Bourne-style => non-POSIX (rather
> than Korn-style <=> POSIX)
> 
> > The best way to deal with this bug is to use "rxvt" or "gnome terminal" 
> > instead 
> > of "xterm". Both programs map the key position code from the BS key to DEL 
> > before sending the event to the speudo tty. 
> 
> None of my servers run X - it's console usability I'm looking for. Are
> there any workarounds for a straight tty environment?

stty erase ^h  

Not followed the whole discussion but above does not work?

-- 
Best regards,

Ken Gunderson

Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

Chris Linton-Ford <[EMAIL PROTECTED]> wrote:

> > The best way to deal with this bug is to use "rxvt" or "gnome terminal" 
> > instead 
> > of "xterm". Both programs map the key position code from the BS key to DEL 
> > before sending the event to the speudo tty. 
>
> None of my servers run X - it's console usability I'm looking for. Are
> there any workarounds for a straight tty environment?

Workarounds need to be done at the place where the problem is introduced.

If you do not run X, you most likely do not have a keyboard connected 
directly to the servers. If you have, change the keyboard translation table
in the kernel.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Casper . Dik]

>Cheers - I just wanted to check that Bourne-style => non-POSIX (rather
>than Korn-style <=> POSIX)

That is actually unclear to me; certainly I would like to have chapter and 
verse quoted of the relevant POSIX standard.

I certainly believe that this should work:

read value < from-file

but I'm not sure that this should work:

cat from-file | read value


Casper

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Chris Linton-Ford]

> This test _only_ checks for one small and single aspect of POSIX vs. Bourne
> compatibility. If you find a program like pdksh that intends to be POSIX
> compatible to return "Bourne" with this test, it only proves that this
> shell needs a major rewrite to become POSIX compliant.

But the consensus seems to be that if we use a POSIX compliant shell
here we break backwards compatibility, so the lesser of the two evils is
to leave standards-compliance to the guys in /usr/xpg4/bin and to add
some timely updates to /sbin/sh.


> Note that the test in question checks how the commandline parser and the
> execution interpreter are written. It justs verifies that the pdksh 
> parser/interpreter are not written in a POSIX compliant way because 
> parsing/execution is done in the opposite order to what POSIX defines.

Cheers - I just wanted to check that Bourne-style => non-POSIX (rather
than Korn-style <=> POSIX)

> The best way to deal with this bug is to use "rxvt" or "gnome terminal" 
> instead 
> of "xterm". Both programs map the key position code from the BS key to DEL 
> before sending the event to the speudo tty. 

None of my servers run X - it's console usability I'm looking for. Are
there any workarounds for a straight tty environment?

Chris

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

Chris Linton-Ford <[EMAIL PROTECTED]> wrote:

> > > It's actually pdksh, wh/was +/- based off of ksh88, w/Korn's blessings,
> > > from back in day when ATT was less amenable to open source licenses.
> > 
> > On Solaris /bin/ksh is ksh88+
> > 
>
> If pdksh is compatible with the existing /sbin/sh, why not use that as
> its replacement? I've been using OpenBSD for a couple of years now and
> find it a perfectly usable shell.

This test _only_ checks for one small and single aspect of POSIX vs. Bourne
compatibility. If you find a program like pdksh that intends to be POSIX
compatible to return "Bourne" with this test, it only proves that this
shell needs a major rewrite to become POSIX compliant.

Note that the test in question checks how the commandline parser and the
execution interpreter are written. It justs verifies that the pdksh 
parser/interpreter are not written in a POSIX compliant way because 
parsing/execution is done in the opposite order to what POSIX defines.

Fixing such a conceptional problem is not simple.

> I'm afraid I'm no POSIX expert, so I'm not clear on whether the
> Bourne/Korn test below implies POSIX compatibility *only* if Korn-style
> is returned; but if using a POSIXy shell for /sbin/sh will cause
> widespread Windows Update-style brokenness then this should be a clear

This test verifes no more than that there is no unique behavior with /bin/sh
on other platforms (in contrary to what was claimed by Shawn).


> no-go. I'm just after a working backspace key (sorry JÃ?rg - IBM
> keyboards may be ill-designed but I'm not seeing many other types in my
> server room or workshop), an editable command history, tab completion
> and possibly $(cmd) expansion.

One of the mistakes in the IBM keyboard (there are _many_ others - like the
position of the "ALT-GR" key" that make it non ergonomic) is to have the 
backspace key at the position where the DEL key is expected to be.

The best way to deal with this bug is to use "rxvt" or "gnome terminal" instead 
of "xterm". Both programs map the key position code from the BS key to DEL 
before sending the event to the speudo tty. 

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Chris Linton-Ford]

> > It's actually pdksh, wh/was +/- based off of ksh88, w/Korn's blessings,
> > from back in day when ATT was less amenable to open source licenses.
> 
> On Solaris /bin/ksh is ksh88+
> 

If pdksh is compatible with the existing /sbin/sh, why not use that as
its replacement? I've been using OpenBSD for a couple of years now and
find it a perfectly usable shell.

I'm afraid I'm no POSIX expert, so I'm not clear on whether the
Bourne/Korn test below implies POSIX compatibility *only* if Korn-style
is returned; but if using a POSIXy shell for /sbin/sh will cause
widespread Windows Update-style brokenness then this should be a clear
no-go. I'm just after a working backspace key (sorry Jörg - IBM
keyboards may be ill-designed but I'm not seeing many other types in my
server room or workshop), an editable command history, tab completion
and possibly $(cmd) expansion.

I think it would remove some of the "Gah!" factor for people coming to
the operating system to have these usability features out-of-the-box.

Chris

> 
> 
> Now let us do a simple POSIX check that does _not_ rely on PATH
> but starts up the way POSIX requires it:
> 
> Linux:
> getconf PATH
> /bin:/usr/bin
> bash-3.2$ PATH=`getconf PATH`
> bash-3.2$ sh
> sh-3.2$ sh -c 'foo=Bourne-style; echo Korn-style | read foo; eval echo $foo'
> Bourne-style
> 
> Solaris:
> getconf PATH
> /usr/xpg4/bin:/usr/ccs/bin:/usr/bin:/opt/SUNWspro/bin
> $ PATH=`getconf PATH`
> $ sh 
> $ sh -c 'foo=Bourne-style; echo Korn-style | read foo; eval echo $foo'
> Korn-style
> 



___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

Ken Gunderson <[EMAIL PROTECTED]> wrote:

> > ># /bin/sh -c 'foo=a; echo b | read foo; echo $foo'  
> > >a
> > ># /bin/ksh -c 'foo=a; echo b | read foo; echo $foo'
> > >a
> > >
> > >( FAO Mr Carlson :) )
> > 
> > It's ksh but not as we know it, Jim.
> > 
> > /bin/ksh93 -c 'foo=a; echo b | read foo; echo $foo'
> > 
> > (I.e., it's the same shell but it doesn't behave like ksh does)
> > 
> > Casper
> > 
>
> It's actually pdksh, wh/was +/- based off of ksh88, w/Korn's blessings,
> from back in day when ATT was less amenable to open source licenses.

On Solaris /bin/ksh is ksh88+

It returns: 

/bin/ksh -c 'foo=Bourne-style; echo Korn-style | read foo; eval echo $foo' 
Korn-style

bash is _bourne_ again shell and started as Bourne Shell project.

It returns:

/bin/bash -c 'foo=Bourne-style; echo Korn-style | read foo; eval echo $foo' 
Bourne-style

...although bash now claims to be POSIX!

I have no idea about the roots of pdksh...



Now let us do a simple POSIX check that does _not_ rely on PATH
but starts up the way POSIX requires it:

Linux:
getconf PATH
/bin:/usr/bin
bash-3.2$ PATH=`getconf PATH`
bash-3.2$ sh
sh-3.2$ sh -c 'foo=Bourne-style; echo Korn-style | read foo; eval echo $foo'
Bourne-style

Solaris:
getconf PATH
/usr/xpg4/bin:/usr/ccs/bin:/usr/bin:/opt/SUNWspro/bin
$ PATH=`getconf PATH`
$ sh 
$ sh -c 'foo=Bourne-style; echo Korn-style | read foo; eval echo $foo'
Korn-style



The main lesson we get is that there is no unique behavior on other platforms.
Solaris already behaves POSIXly correct, Linux does not.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Ken Gunderson]

On Thu, 07 Feb 2008 12:54:20 +0100
[EMAIL PROTECTED] wrote:

> 
> 
> >furthermore:
> >
> ># /bin/sh -c 'foo=a; echo b | read foo; echo $foo'  
> >a
> ># /bin/ksh -c 'foo=a; echo b | read foo; echo $foo'
> >a
> >
> >( FAO Mr Carlson :) )
> 
> It's ksh but not as we know it, Jim.
> 
> /bin/ksh93 -c 'foo=a; echo b | read foo; echo $foo'
> 
> (I.e., it's the same shell but it doesn't behave like ksh does)
> 
> Casper
> 

It's actually pdksh, wh/was +/- based off of ksh88, w/Korn's blessings,
from back in day when ATT was less amenable to open source licenses.

 -- 
Best regards,

Ken Gunderson

Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

[EMAIL PROTECTED] wrote:

> >furthermore:
> >
> ># /bin/sh -c 'foo=a; echo b | read foo; echo $foo'  
> >a
> ># /bin/ksh -c 'foo=a; echo b | read foo; echo $foo'
> >a
> >
> >( FAO Mr Carlson :) )
>
> It's ksh but not as we know it, Jim.
>
> /bin/ksh93 -c 'foo=a; echo b | read foo; echo $foo'
>
> (I.e., it's the same shell but it doesn't behave like ksh does)

Maybe, we should use a new test line:

sh -c 'foo=Bourne; echo Korn | read foo; echo $foo'

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Casper . Dik]

>furthermore:
>
># /bin/sh -c 'foo=a; echo b | read foo; echo $foo'  
>a
># /bin/ksh -c 'foo=a; echo b | read foo; echo $foo'
>a
>
>( FAO Mr Carlson :) )

It's ksh but not as we know it, Jim.

/bin/ksh93 -c 'foo=a; echo b | read foo; echo $foo'

(I.e., it's the same shell but it doesn't behave like ksh does)

Casper

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Chris Linton-Ford]

> fwiw;
> 
> # uname -s
> OpenBSD
> # crontab -l|grep -i shell
> SHELL=/bin/sh
> # grep ^root /etc/passwd |cut -d : -f 1,7
> root:/bin/ksh

# uname -a 
OpenBSD wiggum.firebox.com 4.2 GENERIC#375 i386
# md5 /bin/sh 
MD5 (/bin/sh) = 266304e942a721b73f0c226681a3209d
# md5 /bin/ksh 
MD5 (/bin/ksh) = 266304e942a721b73f0c226681a3209d

furthermore:

# /bin/sh -c 'foo=a; echo b | read foo; echo $foo'  
a
# /bin/ksh -c 'foo=a; echo b | read foo; echo $foo'
a

( FAO Mr Carlson :) )

They are the same shell.

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[UNIX admin]

> Solaris still exists because it still has an own
> identity. If you give this
> up in favor of Linux, people will just use Linux and
> you are lost.

Right. No point in using a copycat OS, even if it is a very expensive copy. 
Might as well go for the original in that case, and just use Linux.

Absolutely agree with you, Solaris needs to stay true to himself, and not try 
to copy technology from a copycat OS - Linux.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

[EMAIL PROTECTED] wrote:

> >POSIX does not deal with path names and thus does not require that
> >/bin/sh is POSIX compliant.
> >
> >Backwards compatibility requiers that /bin/sh remains the Bourne Shel=
> >l.
>
> But we're free to change root's shell to /bin/ksh93

Of course ;-)

My proposal is to give two choices:

1)  use /bin/ksh93 as root shell

2)  use the sh version that I enhanced to support command line history
editing and file name completion to give a less outdated view on the
Bourne Shell. This works even better if you put the (undocumented):

set -m 

into /.profile to switch on Job Control for /bin/sh

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

"Bruno Jargot" <[EMAIL PROTECTED]> wrote:

> Every reasonable Unix platform (except S(ch)illyX maybe) has started
> to move it's implementation of /bin/sh towards the POSIX standard. How
> long can Opensolaris ignore this?

1)  What is reasonable?

2)  If you believe /bin/sh is affected by the POSIX standard, you would
need to re-read the POSIX standard.

3)  Can OpenSolaris ignore it's most important users just for the hope
to get new incorrect educated new users?

4)  The Bourne shell is available as /bin/sh since UNIX version 6, this 
is more than 30 years. You are only free to replace it if the new
program is compatible.

5)  ksh is not compatible to /bin/sh as it is based on a completely 
different concept in the parser and interpreter.

Solaris still exists because it still has an own identity. If you give this
up in favor of Linux, people will just use Linux and you are lost.


Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Ian Collins]

Ken Gunderson wrote:
>
> Interesting that you should mention OpenBSD.  A buddy of mine (very
> experienced Unix grey-beard) just did exactly that.  Happy as a clam,
> that he did.  What's not on OBSD, bigger iron needs, he's running AIX.
>
> He spent a lot of time trying to convince me that Solaris would be a bad
> move.  Nevertheless, after some weeks of discussion and playing around a
> bit, I decided to buck his advice and at least employ as development
> platform for next upcoming project, and see how things went for
> there.  I could be wrong, but recent discussions here are giving a
> lot of second thoughts stemming the distinct impression that
> Open/Solaris is trying to morph into another Linux-esque system in
> efforts to be popular. Well, hey, I could have been really, really
> popular in high school if I would have been doing a lot of drugs, but
> that still didn't make it a good idea.  
>
>   
There's a big difference between what's under the hood (the kernel) and
what goes on in userland.  These waste of bandwidth threads pop up here
from time to time, but if you want to see what's really going on, have a
look at the more specialised lists.

Ian
 

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Ken Gunderson]

On Wed, 06 Feb 2008 20:44:26 PST
"Dr. Robert Pasken" <[EMAIL PROTECTED]> wrote:

> To make sure you understand. I started with a PDP-11/45, an rm-03, a tu-66 
> and Unix V7. My current home computer is a Sun Ultra-24 which has  SUSE-10, 
> Ubuntu Hardy-Heron and Solaris-10 installed.  I don't care for Ubuntu's "we 
> know more than you do" installation and packaging system.I don't care if the 
> installation process looks pretty or is "easy", I should only install just 
> once. The packaging system shouldn't force me to do a bare metal install 
> because patching one package results in every other package breaking. I don't 
> care for the community flame wars over "eye-candy". I do not care if this 
> weeks newest webcam works or if I can play music from iTunes. What I do care 
> about is if I can find away to shave another 10 minutes off  WRF and MM5 
> model run times with 4 cores and 8gb of memory. Can I get HYSPLIT_4 to 
> generate explosion plumes while WRF is running at the same time. Can I volume 
> render HYSPLIT_4 output on a laptop. While Linux is more stable Windows, 
> Linux has be
 en
>   and is moving in the direction of "eye-candy" and reduced stability. This 
> based on real-world experience. I cann't afford more file-system failures or 
> kernel crashes while WRF/HYSPLIT/DRAS is running. I will abandon Solaris and 
> move to OpenBSD if Solaris moves to the Linux model.
>  

Interesting that you should mention OpenBSD.  A buddy of mine (very
experienced Unix grey-beard) just did exactly that.  Happy as a clam,
that he did.  What's not on OBSD, bigger iron needs, he's running AIX.

He spent a lot of time trying to convince me that Solaris would be a bad
move.  Nevertheless, after some weeks of discussion and playing around a
bit, I decided to buck his advice and at least employ as development
platform for next upcoming project, and see how things went for
there.  I could be wrong, but recent discussions here are giving a
lot of second thoughts stemming the distinct impression that
Open/Solaris is trying to morph into another Linux-esque system in
efforts to be popular. Well, hey, I could have been really, really
popular in high school if I would have been doing a lot of drugs, but
that still didn't make it a good idea.  

-- 
Best regards,

Ken Gunderson

Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Dr. Robert Pasken]

To make sure you understand. I started with a PDP-11/45, an rm-03, a tu-66 and 
Unix V7. My current home computer is a Sun Ultra-24 which has  SUSE-10, Ubuntu 
Hardy-Heron and Solaris-10 installed.  I don't care for Ubuntu's "we know more 
than you do" installation and packaging system.I don't care if the installation 
process looks pretty or is "easy", I should only install just once. The 
packaging system shouldn't force me to do a bare metal install because patching 
one package results in every other package breaking. I don't care for the 
community flame wars over "eye-candy". I do not care if this weeks newest 
webcam works or if I can play music from iTunes. What I do care about is if I 
can find away to shave another 10 minutes off  WRF and MM5 model run times with 
4 cores and 8gb of memory. Can I get HYSPLIT_4 to generate explosion plumes 
while WRF is running at the same time. Can I volume render HYSPLIT_4 output on 
a laptop. While Linux is more stable Windows, Linux has been
  and is moving in the direction of "eye-candy" and reduced stability. This 
based on real-world experience. I cann't afford more file-system failures or 
kernel crashes while WRF/HYSPLIT/DRAS is running. I will abandon Solaris and 
move to OpenBSD if Solaris moves to the Linux model.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

"Shawn Walker" <[EMAIL PROTECTED]> wrote:

> On Feb 6, 2008 2:57 PM, Joerg Schilling
> <[EMAIL PROTECTED]> wrote:
> > "Shawn Walker" <[EMAIL PROTECTED]> wrote:
> >
> > > >
> > > > (Or you need to proof that there are no /bin/sh scripts in use on 
> > > > Solaris
> > > > which execute differently under ksh/ksh93)
> > >
> > > ...ksh93 can be modified to provide backwards compatibility where 
> > > possible.
> >
> >
> > This is not true, at least not if you limit the effort to reasonable 
> > values...
> >
> > Your wild guess seems to be a result of not knowing why e.g. these commands
>
> It isn't a wild guess. If I'm not mistaken, Roland has been doing some
> testing and work in the area of shell compatibility.

Please read the rest of the mail you replied to and you understand why it would 
not work.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[a b]

> >  And you don't have to be; that'll change all by itself as you gain
> > engineering experience under your belt.
> 
> Such a statement incorrectly assumes that I do not have such experience.

If you did actually posess the necessary experience, we wouldn't be having this 
discussion right now.

Just as I don't need to discuss certain things with Casper. Or Joerg. Or James.


_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Shawn Walker]

On Feb 6, 2008 2:57 PM, Joerg Schilling
<[EMAIL PROTECTED]> wrote:
> "Shawn Walker" <[EMAIL PROTECTED]> wrote:
>
> > >
> > > (Or you need to proof that there are no /bin/sh scripts in use on Solaris
> > > which execute differently under ksh/ksh93)
> >
> > ...ksh93 can be modified to provide backwards compatibility where possible.
>
>
> This is not true, at least not if you limit the effort to reasonable values...
>
> Your wild guess seems to be a result of not knowing why e.g. these commands

It isn't a wild guess. If I'm not mistaken, Roland has been doing some
testing and work in the area of shell compatibility.

As I said before, where possible.

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

"Shawn Walker" <[EMAIL PROTECTED]> wrote:

> >
> > (Or you need to proof that there are no /bin/sh scripts in use on Solaris
> > which execute differently under ksh/ksh93)
>
> ...ksh93 can be modified to provide backwards compatibility where possible.


This is not true, at least not if you limit the effort to reasonable values...

Your wild guess seems to be a result of not knowing why e.g. these commands

$ /sbin/sh -c 'foo=a; echo b | read foo; echo $foo'
a
$ /usr/bin/ksh93 -c 'foo=a; echo b | read foo; echo $foo'
b

give different results.

It is a result of different concepts in the parser and interpreter for
the shell syntax.

sh executes pipes from left to right while ksh executes them from right to left,
which results in "read foo" to be the foreground process on ksh and the 
background process with sh.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Ken Gunderson]

On Wed, 06 Feb 2008 20:02:37 +0100
[EMAIL PROTECTED] wrote:

> 
> >"Shawn Walker" <[EMAIL PROTECTED]> wrote:
> >
> >> Ultimately, /sbin/sh is an unacceptable shell in a modern environme=
> >nt
> >> for a variety of reasons.
> >>
> >> It isn't even POSIX compliant, and the base system shell should be.
> >
> >POSIX does not deal with path names and thus does not require that
> >/bin/sh is POSIX compliant.
> >
> >Backwards compatibility requiers that /bin/sh remains the Bourne Shel=
> >l.
> 
> But we're free to change root's shell to /bin/ksh93

fwiw;

# uname -s
OpenBSD
# crontab -l|grep -i shell
SHELL=/bin/sh
# grep ^root /etc/passwd |cut -d : -f 1,7
root:/bin/ksh


-- 
Best regards,

Ken Gunderson

Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Shawn Walker]

On Feb 6, 2008 1:05 PM,  <[EMAIL PROTECTED]> wrote:
>
> >> POSIX does not deal with path names and thus does not require that
> >> /bin/sh is POSIX compliant.
> >
> >What do path names have to do with the shell command language?
>
> I think Joerg means "the base system shell need not be /bin/sh".
>
> (I.e., the pathname to the base system shell is not defined and neither
> is the path to the standard shell in POSIX)
>
> >http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
> >
> >> Backwards compatibility requiers that /bin/sh remains the Bourne Shell.
> >
> >I don't agree.
>
> We have shown that sh and ksh93 are not compatible; in order to avoid
> ANY breakage you would need to not change it.  I think there is no
> denying that fact.
>
> (Or you need to proof that there are no /bin/sh scripts in use on Solaris
> which execute differently under ksh/ksh93)

...ksh93 can be modified to provide backwards compatibility where possible.

Which is why I said I don't agree.

While it may be that 100% backwards compatibility cannot be maintained
(it is difficult to tell until all of the cases are dealt with), 99%
may be good enough.

In the end, it may be worth not keeping backwards compatibility with
such a broken shell.

But that isn't for me to decide, even though I hope it happens.

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Casper . Dik]

>> POSIX does not deal with path names and thus does not require that
>> /bin/sh is POSIX compliant.
>
>What do path names have to do with the shell command language?

I think Joerg means "the base system shell need not be /bin/sh".

(I.e., the pathname to the base system shell is not defined and neither
is the path to the standard shell in POSIX)

>http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
>
>> Backwards compatibility requiers that /bin/sh remains the Bourne Shell.
>
>I don't agree.

We have shown that sh and ksh93 are not compatible; in order to avoid
ANY breakage you would need to not change it.  I think there is no
denying that fact.

(Or you need to proof that there are no /bin/sh scripts in use on Solaris
which execute differently under ksh/ksh93)

Casper

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Casper . Dik]

>"Shawn Walker" <[EMAIL PROTECTED]> wrote:
>
>> Ultimately, /sbin/sh is an unacceptable shell in a modern environme=
>nt
>> for a variety of reasons.
>>
>> It isn't even POSIX compliant, and the base system shell should be.
>
>POSIX does not deal with path names and thus does not require that
>/bin/sh is POSIX compliant.
>
>Backwards compatibility requiers that /bin/sh remains the Bourne Shel=
>l.

But we're free to change root's shell to /bin/ksh93

Casper

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Bruno Jargot]

On 2/6/08, Joerg Schilling <[EMAIL PROTECTED]> wrote:
> "Shawn Walker" <[EMAIL PROTECTED]> wrote:
>
> > Ultimately, /sbin/sh is an unacceptable shell in a modern environment
> > for a variety of reasons.
> >
> > It isn't even POSIX compliant, and the base system shell should be.
>
> POSIX does not deal with path names and thus does not require that
> /bin/sh is POSIX compliant.

Every reasonable Unix platform (except S(ch)illyX maybe) has started
to move it's implementation of /bin/sh towards the POSIX standard. How
long can Opensolaris ignore this?

Bruno
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

"Shawn Walker" <[EMAIL PROTECTED]> wrote:

> On Feb 6, 2008 11:08 AM, Joerg Schilling
> <[EMAIL PROTECTED]> wrote:
> > "Shawn Walker" <[EMAIL PROTECTED]> wrote:
> >
> > > Ultimately, /sbin/sh is an unacceptable shell in a modern environment
> > > for a variety of reasons.
> > >
> > > It isn't even POSIX compliant, and the base system shell should be.
> >
> > POSIX does not deal with path names and thus does not require that
> > /bin/sh is POSIX compliant.
>
> What do path names have to do with the shell command language?

Please try to understand how POSIX works

POSIX requires a POSIX compliant shell to be available if ou type "sh"
after you typed: "PATH=`getconf PATH`"

POSIX does _not_ deal with PATH names and thus does not say anything about
/bin/sh.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Shawn Walker]

On Feb 6, 2008 11:08 AM, Joerg Schilling
<[EMAIL PROTECTED]> wrote:
> "Shawn Walker" <[EMAIL PROTECTED]> wrote:
>
> > Ultimately, /sbin/sh is an unacceptable shell in a modern environment
> > for a variety of reasons.
> >
> > It isn't even POSIX compliant, and the base system shell should be.
>
> POSIX does not deal with path names and thus does not require that
> /bin/sh is POSIX compliant.

What do path names have to do with the shell command language?

http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html

> Backwards compatibility requiers that /bin/sh remains the Bourne Shell.

I don't agree.

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

"Shawn Walker" <[EMAIL PROTECTED]> wrote:

> Ultimately, /sbin/sh is an unacceptable shell in a modern environment
> for a variety of reasons.
>
> It isn't even POSIX compliant, and the base system shell should be.

POSIX does not deal with path names and thus does not require that
/bin/sh is POSIX compliant.

Backwards compatibility requiers that /bin/sh remains the Bourne Shell.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Shawn Walker]

On Feb 6, 2008 10:30 AM, Chris Linton-Ford <[EMAIL PROTECTED]> wrote:
> > Chris Linton-Ford writes:
> > > It might be helpful to consider the shells' dual nature as a) a
> > > scripting medium and b) an interactive environment. Surely there is no
> > > engineering reason why a shell could not be coded to have only a strict
> > > superset of /sbin/sh's commands, thus making scripts compatible.
> >
> > What's the superset of this?
> >
> > $ /sbin/sh -c 'foo=a; echo b | read foo; echo $foo'
> > a
> > $ /usr/bin/ksh93 -c 'foo=a; echo b | read foo; echo $foo'
> > b
> >
>
> If ksh93 is incompatible with the existing sh *by design*, then nothing
> can be done that will not step on someones toes somewhere. This pretty

I don't believe that is the case yet, and quite frankly, hanging to
dear life to such a shell that hasn't been updated in years seems
silly at best.

Quite frankly, I'm tired of hearing people complain about /sbin/sh.

People either need to:

1) Propose and to the work necessary to get bsh integrated as /sbin/sh

2) Fix whatever deficiencies they perceive are there

The main issue is that even if you fix the few issues that Joerg has
fixed, that doesn't solve most of the problems with /sbin/sh.

Ultimately, /sbin/sh is an unacceptable shell in a modern environment
for a variety of reasons.

It isn't even POSIX compliant, and the base system shell should be.

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Shawn Walker]

On Feb 6, 2008 9:38 AM, James Carlson <[EMAIL PROTECTED]> wrote:
> Shawn Walker writes:
> > I still do not believe that something cannot be done to address the issue.
>
> At least in some cases, the "something" would have to be an assumption
> that the unresolvable differences are simply unimportant and will
> either have no effect on users or will have effects that we just don't
> care about.

While that is a possible conclusion, I haven't seen the people
involved coming to that conclusion so far.

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Chris Linton-Ford]

> Chris Linton-Ford writes:
> > It might be helpful to consider the shells' dual nature as a) a
> > scripting medium and b) an interactive environment. Surely there is no
> > engineering reason why a shell could not be coded to have only a strict
> > superset of /sbin/sh's commands, thus making scripts compatible. 
> 
> What's the superset of this?
> 
> $ /sbin/sh -c 'foo=a; echo b | read foo; echo $foo'
> a
> $ /usr/bin/ksh93 -c 'foo=a; echo b | read foo; echo $foo'
> b
> 

If ksh93 is incompatible with the existing sh *by design*, then nothing
can be done that will not step on someones toes somewhere. This pretty
much invalidates it as a candidate for a sh replacement. So unless
there's a shell out there which does the strict command supersetting and
also has the improved interactive usability we're looking at new code.
The question is where to put it? Do we fork the /sbin/sh code for
Indiana and call it something else, or campaign for features to be
included in the "official" Sun sh release?

IMHO what Jorg has done with the linking to bsh code to extend sh seems
like an eminently sensible way to walk the line between usability and
compatibility.

Chris

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[James Carlson]

Chris Linton-Ford writes:
> It might be helpful to consider the shells' dual nature as a) a
> scripting medium and b) an interactive environment. Surely there is no
> engineering reason why a shell could not be coded to have only a strict
> superset of /sbin/sh's commands, thus making scripts compatible. 

What's the superset of this?

$ /sbin/sh -c 'foo=a; echo b | read foo; echo $foo'
a
$ /usr/bin/ksh93 -c 'foo=a; echo b | read foo; echo $foo'
b

Shawn Walker writes:
> I still do not believe that something cannot be done to address the issue.

At least in some cases, the "something" would have to be an assumption
that the unresolvable differences are simply unimportant and will
either have no effect on users or will have effects that we just don't
care about.

-- 
James Carlson, Solaris Networking  <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

"Shawn Walker" <[EMAIL PROTECTED]> wrote:

> On Feb 6, 2008 5:32 AM, Joerg Schilling
> <[EMAIL PROTECTED]> wrote:
> > "Shawn Walker" <[EMAIL PROTECTED]> wrote:
> >
> > > Yes, but Nexenta is clearly trying to compete; they produce a
> > > commercial product.
> > >
> > > Thus, I stand by the claim that Nexenta, at the very least, is a fork.
> >
> > The fact whether or not a project is commercial cannot be an indication
> > for a fork.
>
> I was responding to another poster's implication that, to be a fork, a
> project has to compete, and Nexenta is definitely competing (I
> consider that a good thing).

competing is not a reason for calling something a "fork".

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

Chris Linton-Ford <[EMAIL PROTECTED]> wrote:

> It might be helpful to consider the shells' dual nature as a) a
> scripting medium and b) an interactive environment. Surely there is no
> engineering reason why a shell could not be coded to have only a strict
> superset of /sbin/sh's commands, thus making scripts compatible. 
>
> The interactive usability features are somewhat orthogonal to the
> scripting capabilities and compatibility - I'm thinking that what most
> people want, and certainly what I want, is improvement to former, rather
> than incompatible extensions to the latter.

This is what I did on SchilliX-0.6.1 ;-)

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Shawn Walker]

On Feb 6, 2008 5:32 AM, Joerg Schilling
<[EMAIL PROTECTED]> wrote:
> "Shawn Walker" <[EMAIL PROTECTED]> wrote:
>
> > Yes, but Nexenta is clearly trying to compete; they produce a
> > commercial product.
> >
> > Thus, I stand by the claim that Nexenta, at the very least, is a fork.
>
> The fact whether or not a project is commercial cannot be an indication
> for a fork.

I was responding to another poster's implication that, to be a fork, a
project has to compete, and Nexenta is definitely competing (I
consider that a good thing).

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Shawn Walker]

On Feb 6, 2008 3:57 AM, a b <[EMAIL PROTECTED]> wrote:
>
>  > > (And while we can fix our scripts to work fine with ksh/ksh93,
> > > customer scripts breakage will be different)
> >
> > I'm not convinced of that yet.
>
>  And you don't have to be; that'll change all by itself as you gain
> engineering experience under your belt.

Such a statement incorrectly assumes that I do not have such experience.

I still do not believe that something cannot be done to address the issue.

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Chris Linton-Ford]

On Tue, 2008-02-05 at 15:35 +0100, Joerg Schilling wrote:
> "Shawn Walker" <[EMAIL PROTECTED]> wrote:
> 
> > > There is a plan to create complatibility to /bin/ksh which is based on 
> > > ksh88.
> > >
> > > /bin/sh is something different, it is not a Korn Shell but a Bourne Shell.
> >
> > I know that; but the version we have is also very limited.
> >
> > I know Roland believes that ksh93 can replace /sbin/sh.
> 
> It may be that he believes so, but there have been many people with 
> objections.
> 
> I don't believe it makes sense to make shell scripts from users to fail 
> because
> /bin/sh does no longer behave like the Bourne Shell.
> 
> Jörg

It might be helpful to consider the shells' dual nature as a) a
scripting medium and b) an interactive environment. Surely there is no
engineering reason why a shell could not be coded to have only a strict
superset of /sbin/sh's commands, thus making scripts compatible. 

The interactive usability features are somewhat orthogonal to the
scripting capabilities and compatibility - I'm thinking that what most
people want, and certainly what I want, is improvement to former, rather
than incompatible extensions to the latter.

Chris

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

"Shawn Walker" <[EMAIL PROTECTED]> wrote:

> Yes, but Nexenta is clearly trying to compete; they produce a
> commercial product.
>
> Thus, I stand by the claim that Nexenta, at the very least, is a fork.

The fact whether or not a project is commercial cannot be an indication
for a fork.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

Alan Coopersmith <[EMAIL PROTECTED]> wrote:

> Joerg Schilling wrote:
> > Good question, but I don't know. The problem I see with Xscreensaver is that
> > it is installed suid root on SXCE and thus is unable to read ~/.Xauthority
> > from NFS mounted home directories. Removing the suid root did fix the 
> > problem 
> > for me.
>
> And broke the ability for it to read /etc/shadow for locally-defined
> users to be able to unlock the screen.We don't make things suid-root
> without a damn good reason.

A cannot call this a "solution" as it does not work for me the way it is 
delivered
in SXCE-77.

If you do make things suid root for "good reason", you should also modify the 
source to try again with euid == uid after the attempt to read ~/.Xauthority 
failed.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[a b]

> > (And while we can fix our scripts to work fine with ksh/ksh93,> > customer 
> > scripts breakage will be different)> > I'm not convinced of that yet.
And you don't have to be; that'll change all by itself as you gain engineering 
experience under your belt.
 
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[a b]

> I'm not sure what we could learn in terms of developer accessibility> or 
> approachability from dead or dormant platforms.HP-UX ain't dead yet, in fact 
> 11iv3 came out relatively recently. It's just closed and not easily 
> accessible, and therefore not transparent, so the general public doesn't get 
> to see the innovation happening. IRIX may be dead, but if we consider that 
> IRIX, even though it is dead, still has in it technology that is light years 
> ahead of anything currently available on the market, you ought to sit down 
> and really rethink the statement you made above. Especially if we consider 
> that IRIX still has technology that puts "the most advanced operating system 
> on the planet" to shame, one really ought to rethink statements like the one 
> you made above. The point here is, regardless of whether an OS is dead or 
> not, Solaris should *always* look up to the best solutions, and not to 
> solutions which are currently in fashion.
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Ken Gunderson]

On Tue, 05 Feb 2008 13:56:22 PST
Tom Keiser <[EMAIL PROTECTED]> wrote:

> > On Feb 4, 2008 7:30 PM, Ken Gunderson
> > <[EMAIL PROTECTED]> wrote:
> [snip]
> > > Linux => GPL license.  Linux kernel bundled into
> > assorted "distros" with
> > > various GNU tools (Gnu's Not Unix, proclaimed loud
> > and proud on their
> > > homepage) and disparate userlands, etc., the
> > components of which are
> > > far from standardized.  Dependency nightmares
> > during installs and
> > > upgrades. When several _hundred_ RH boxes are
> > borked because of sloppy
> > > merges, etc., who cares that it's commercially
> > "supported", you still
> > > have one hell of a lot of unhappy customers yelling
> > at you. Granted,
> > > Linux has improved over the years, but still not
> > without it's warts.
> > 
> > I fail to see what this has to do with anything that
> > is being done
> > with Project Indiana or OpenSOlaris in general.
> > 
> > Regardless of the problems that these platforms have,
> > right now, they
> > are the ones leading the market.
> > 
> 
> I'm dubious of the strategy implied by this remark.  Trying to gain market 
> share by emulating a market leader is generally an exercise in futility.  
> People don't make large-scale platform migrations unless there is a 
> significant comparative advantage.  Do you really think the GNU userland 
> provides Linux with such a comparative advantage?  I sincerely doubt it -- 
> most people use bash due to inertia, not because it is inherently "better" 
> than ksh93.
> 
> If you want compelling reasons to run Linux, look no further than a broad 
> range of device drivers and sane package management.  Both of these are being 
> addressed without any dependency on moving towards a GNU userspace.  I think 
> a large part of the argument for a GNU userland revolves around the false 
> premise that "approachability" and "ease of platform migration" are 
> synonymous.  
> 
> 
> > > Which brings us to Solaris. Can Solaris provide
> > integrated, cohesive
> > > kernel and true unix userland in a stable and well
> > performing package
> > > that is freely available, and hence able to compete
> > on it's own
> > > technical merits with the freely available *BSD's
> > and Linuxes?  I hope
> > 
> > I find the phrase "true unix userland" to be rather
> > funny. Solaris
> > ships with several flavours of "userland" utilities,
> > many of which
> > aren't even in the default path configuration.
> > 
> > Most of the utilities in the default path (such as
> > grep, etc.) are
> > widely panned for the lack of modern functionality,
> > updates, and
> > numerous bugs.
> > 
> > While I personally I am very grateful for the xpg4,
> > xpg6, and other
> > standards compliant environments that are available;
> > there is no
> > reason that the default userland has to resemble the
> > olden days of the
> > pdp-11 :) (joking)
> > 
> 
> If you consider the standards to be outdated, then the appropriate course of 
> action is to push for ratification of new revisions to the standards.  
> Adoption of the GNU toolchain simply perpetuates the widely-held belief that 
> standards-driven development is dead.  That's hardly the sort of example a 
> project which purports to be best-of-breed should be setting.
> 
> 
> > While I wish that there were better options than GNU
> > userland in terms
> > of functionality, the reality is that the majority of
> > the open source
> > world has chosen the GNU toolset, for better or
> > worse, as their
> > toolset of choice.
> > 
> 
> I vehemently disagree with the notion that popularity should dictate product 
> engineering.  Users are fickle.  Popularity can be quite fleeting.  Strategic 
> decisions should not be based on the current direction of the wind.  There 
> are many cases where emancipation will take longer, but prove strategically 
> beneficial.
> 
> 
> > Wasting precious resources on attempting to reinvent
> > the GNU wheel,
> > all in the name of (mostly) pride and arrogance,
> > isn't going to win
> > any battles.
> > 
> 
> Pride and arrogance have absolutely nothing to do with the large-scale 
> opposition to adoption of the GNU userland.  Unless by 'arrogance', you mean 
> the belief that software should be engineered instead of written in an ad-hoc 
> "organic" manner.  I'm far more concerned by this (frankly inexplicable) 
> haste to get to the promised land of an approachable desktop-oriented Solaris 
> distribution, than I am about the actual implementation details.  There is a 
> broad perception that the core design principles which have served to 
> differentiate Solaris from linux and its ilk seem to have largely been 
> forgotten.  I cannot stress enough that this perception is largely fueled by 
> the fervor with which a few individuals promote change purely for the sake of 
> change.
> 
> I have absolutely no problem with the project Indiana concept.  To the 
> contrary, I'm quite happy that such an endeavour is being undertaken.  
> However, 

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Tom Keiser]

> On Feb 4, 2008 7:30 PM, Ken Gunderson
> <[EMAIL PROTECTED]> wrote:
[snip]
> > Linux => GPL license.  Linux kernel bundled into
> assorted "distros" with
> > various GNU tools (Gnu's Not Unix, proclaimed loud
> and proud on their
> > homepage) and disparate userlands, etc., the
> components of which are
> > far from standardized.  Dependency nightmares
> during installs and
> > upgrades. When several _hundred_ RH boxes are
> borked because of sloppy
> > merges, etc., who cares that it's commercially
> "supported", you still
> > have one hell of a lot of unhappy customers yelling
> at you. Granted,
> > Linux has improved over the years, but still not
> without it's warts.
> 
> I fail to see what this has to do with anything that
> is being done
> with Project Indiana or OpenSOlaris in general.
> 
> Regardless of the problems that these platforms have,
> right now, they
> are the ones leading the market.
> 

I'm dubious of the strategy implied by this remark.  Trying to gain market 
share by emulating a market leader is generally an exercise in futility.  
People don't make large-scale platform migrations unless there is a significant 
comparative advantage.  Do you really think the GNU userland provides Linux 
with such a comparative advantage?  I sincerely doubt it -- most people use 
bash due to inertia, not because it is inherently "better" than ksh93.

If you want compelling reasons to run Linux, look no further than a broad range 
of device drivers and sane package management.  Both of these are being 
addressed without any dependency on moving towards a GNU userspace.  I think a 
large part of the argument for a GNU userland revolves around the false premise 
that "approachability" and "ease of platform migration" are synonymous.  


> > Which brings us to Solaris. Can Solaris provide
> integrated, cohesive
> > kernel and true unix userland in a stable and well
> performing package
> > that is freely available, and hence able to compete
> on it's own
> > technical merits with the freely available *BSD's
> and Linuxes?  I hope
> 
> I find the phrase "true unix userland" to be rather
> funny. Solaris
> ships with several flavours of "userland" utilities,
> many of which
> aren't even in the default path configuration.
> 
> Most of the utilities in the default path (such as
> grep, etc.) are
> widely panned for the lack of modern functionality,
> updates, and
> numerous bugs.
> 
> While I personally I am very grateful for the xpg4,
> xpg6, and other
> standards compliant environments that are available;
> there is no
> reason that the default userland has to resemble the
> olden days of the
> pdp-11 :) (joking)
> 

If you consider the standards to be outdated, then the appropriate course of 
action is to push for ratification of new revisions to the standards.  Adoption 
of the GNU toolchain simply perpetuates the widely-held belief that 
standards-driven development is dead.  That's hardly the sort of example a 
project which purports to be best-of-breed should be setting.


> While I wish that there were better options than GNU
> userland in terms
> of functionality, the reality is that the majority of
> the open source
> world has chosen the GNU toolset, for better or
> worse, as their
> toolset of choice.
> 

I vehemently disagree with the notion that popularity should dictate product 
engineering.  Users are fickle.  Popularity can be quite fleeting.  Strategic 
decisions should not be based on the current direction of the wind.  There are 
many cases where emancipation will take longer, but prove strategically 
beneficial.


> Wasting precious resources on attempting to reinvent
> the GNU wheel,
> all in the name of (mostly) pride and arrogance,
> isn't going to win
> any battles.
> 

Pride and arrogance have absolutely nothing to do with the large-scale 
opposition to adoption of the GNU userland.  Unless by 'arrogance', you mean 
the belief that software should be engineered instead of written in an ad-hoc 
"organic" manner.  I'm far more concerned by this (frankly inexplicable) haste 
to get to the promised land of an approachable desktop-oriented Solaris 
distribution, than I am about the actual implementation details.  There is a 
broad perception that the core design principles which have served to 
differentiate Solaris from linux and its ilk seem to have largely been 
forgotten.  I cannot stress enough that this perception is largely fueled by 
the fervor with which a few individuals promote change purely for the sake of 
change.

I have absolutely no problem with the project Indiana concept.  To the 
contrary, I'm quite happy that such an endeavour is being undertaken.  However, 
the strategy of supplanting vast amounts of code with the GNU toolchain is a 
suboptimal path of least resistance.  Emancipation is hard.  GNU user 
re-education is hard.  So what?  Hard in and of itself should never serve as 
justification for not doing something.


> Ivory tower attitudes will keep that tower s

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Kyle McDonald]

Alan Coopersmith wrote:
> Kyle McDonald wrote:
>> Another example, is Xscreensaver. I always used to be able install 
>> that with only X11 installed. Now not only does GNOME have to be 
>> installed too, So does large portions of Evolution!! What on earth 
>> does Evolution have to do with a ScreenSaver?
>
> In order to support users who need accessibility helpers to unlock their
> screens, Sun modified xscreensaver to use a GTK-based unlock dialog and
> the GNOME accessibility framework.   It should only depend on the GNOME
> base libraries - I have no idea why there would be any linkage to
> Evolution unless the GNOME base libraries or accessibility packages 
> brings
> them in - the package dependencies in xscreensaver's package (SUNWxwsvr)
> don't specify them.
>
It's good to enable accessibility. Though even that should be optional I 
feel (I'd opt for it but I don't know if everyone would.)

You're correct, that XscreenSaver only directly requires a few packages. 
It's the packages those packages require, and so on that become the problem.

Is anyone a fan of installing systems that have unsatisfied package 
dependencies?

Will the libs Xscreensaver needs work even if the dependencies of the 
packages they come in aren't met?

Will Xscreensaver work without the accessibility features if the library 
packages are left out?


  -Kyle

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Shawn Walker]

On Feb 5, 2008 1:21 PM, Ken Gunderson <[EMAIL PROTECTED]> wrote:
> On Tue, 5 Feb 2008 11:08:40 -0600
> "Shawn Walker" <[EMAIL PROTECTED]> wrote:
>
> > On Feb 5, 2008 9:42 AM, UNIX admin <[EMAIL PROTECTED]> wrote:
> > > > It just so happens that GNU/Linux is one of those
> > > > platforms from which
> > > > certain evaluations are drawn.
> > >
> > > Yeah well, I can tell you that it would have been much more useful to 
> > > draw from operating systems which got things right, like HP-UX, and IRIX 
> > > in particular! Even FreeBSD has features that would be desireable in 
> > > OpenSolaris.
> > >
> >
> > I'm not sure what we could learn in terms of developer accessibility
> > or approachability from dead or dormant platforms.
>
> FreeBSD is far from "dead or dormant" platform.  And quite frankly, the

I'm talking about HP-UX and IRIX; not FreeBSD, sorry I missed that you
mentioned that one.

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Ken Gunderson]

On Tue, 5 Feb 2008 11:08:40 -0600
"Shawn Walker" <[EMAIL PROTECTED]> wrote:

> On Feb 5, 2008 9:42 AM, UNIX admin <[EMAIL PROTECTED]> wrote:
> > > It just so happens that GNU/Linux is one of those
> > > platforms from which
> > > certain evaluations are drawn.
> >
> > Yeah well, I can tell you that it would have been much more useful to draw 
> > from operating systems which got things right, like HP-UX, and IRIX in 
> > particular! Even FreeBSD has features that would be desireable in 
> > OpenSolaris.
> >
> 
> I'm not sure what we could learn in terms of developer accessibility
> or approachability from dead or dormant platforms.

FreeBSD is far from "dead or dormant" platform.  And quite frankly, the
more Sun fan-boy posts I read in this thread, the less psyched I am
becoming about Open/Solaris. I dedicated quite a bit of time reading
various docs, etc. before I spent much time following the lists, but
now that I have, my current impression is rapidly becoming more along
the lines of; "my god, what a mess".  A week ago I had 99.9%
decided to use Open/Solaris as platform for our next project.  Now I'm
99.9% decided that a more prudent approach may well be to "give it
another year and see what shakes out in the wash".  I don't have a
problem investing months gaining the requisite Solaris expertise.  But
I do have a problem _if_ that time subsequently becomes wasted effort 
because Open/Solaris becomes a Linux-esqe hodge-podge of buggy code.

Thank you and have a  nice day:)

-- 
Best regards,

Ken Gunderson

Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Erast Benson]

On Tue, 2008-02-05 at 12:44 -0600, Shawn Walker wrote:
> Thus, I stand by the claim that Nexenta, at the very least, is a fork.

You deeply mistaken here. As far as OpenSolaris is concerned - Nexenta
is NOT a fork. We share the same code base. The integration part of
userland IS a bit different, but than again, even Solaris 10 Update4
userland parts are differ from Solaris 10 GA, not even comparing to
Nevada builds... And Nexenta provides switchable SUN/GNU personality,
which allows as to run native Solaris applications and scripts when
required.

So, please be careful with your "analysis".. :-)

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Shawn Walker]

On Feb 5, 2008 12:26 PM, Ken Gunderson <[EMAIL PROTECTED]> wrote:
> On Tue, 5 Feb 2008 11:08:02 -0600
> "Shawn Walker" <[EMAIL PROTECTED]> wrote:
>
> > On Feb 5, 2008 9:37 AM, UNIX admin <[EMAIL PROTECTED]> wrote:
> > > > I'd be very surprised if someone rewrote history to
> > > > declare Indiana
> > > > the cause of the first OpenSolaris fork, given that
> > > > we've already
> > > > got Nexenta, Schillix, Belenix and Martux.
> > >
> > > Those aren't forks, since they sync up with the main OpenSolaris codebase 
> > > on a regular basis.
> > >
> > > A fork is a codebase that no longer syncs with its ancestor, but is 
> > > instead worked on independently, in parallel. A fork might import some 
> > > desired functionality down the road, or might not, or might even prohibit 
> > > importing anything from a particular codebase.
> >
> > That doesn't sound like any accepted definition of fork I've seen, the
> > definition here:
> >
> > http://en.wikipedia.org/wiki/Software_fork
> >
> > ...basically says that taking a copy of source code and doing
> > independent development qualifies.
> >
> > Well, all three of those distributions took a copy of the source code
> > (it says nothing about continuing to update that copy) and performed
> > independent development.
> >
> > Meaning, all of them had changes that are or were not integrated back
> > into ON, etc.
> >
> > As a result, they are *different* from the originals in certain areas,
> > and therefore are not a straight copy and qualify as a fork in my
> > mind.
> >
> > Are they harmful forks? I doubt it; but to me, they are forks.
>
> Wikipeida is far from the last word on anything.  For example, see
> below:
>
> "A fork is a competing project based on a version of the pre-existing
> project's source code. All OSS/FS projects can be "forked"; the ability
> to create a fork is fundamental to the definition of OSS/FS.
>
> Simply creating or releasing a variant of a project's code does not
> normally create a fork unless there's an intent to create a competing
> project. Indeed, releasing variants for experimentation is considered

One could argue that all of these projects compete in some way;
Nexenta certainly does since they release a commercial product.

> normal in a typical OSS/FS development process. Many OSS/FS projects
> (such as the Linux kernel development project) intentionally have
> "fly-offs" (also called "bake-offs") where different developers
> implement different competing approaches; the results are compared and
> the approach that produces the best results (the "winner") is accepted
> by the project. These "fly-offs" are often discussed in evolutionary
> terms, e.g., the "winning mutation" is accepted into the project and
> the alternatives are abandoned as "evolutionary dead ends". Since all
> parties intend for the "best" approach to accepted by the project, and
> for the other approaches to be abandoned, these are not forks.

Right, which is why I pointed out that these distributions had changes
that were not integrated back either now or in the past.

Some of them have changes that are not intended to be integrated back.

> What is different about a fork is intent. In a fork, the person(s)
> creating the fork intend for the fork to replace or compete with the
> original project they are forking."
>
> 
>
> The first and last paragraphs above, in particular, sum up my
> historical understanding of the term.  Yes, there are specialized
> cases/exceptions, as exemplified in paragraph 2.  But the general
> meaning as a stand alone term would be closer to that in para's 1 & 3.

Yes, but Nexenta is clearly trying to compete; they produce a
commercial product.

Thus, I stand by the claim that Nexenta, at the very least, is a fork.

Though I don't currently see it as a harmful one.

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Ken Gunderson]

On Tue, 5 Feb 2008 11:08:02 -0600
"Shawn Walker" <[EMAIL PROTECTED]> wrote:

> On Feb 5, 2008 9:37 AM, UNIX admin <[EMAIL PROTECTED]> wrote:
> > > I'd be very surprised if someone rewrote history to
> > > declare Indiana
> > > the cause of the first OpenSolaris fork, given that
> > > we've already
> > > got Nexenta, Schillix, Belenix and Martux.
> >
> > Those aren't forks, since they sync up with the main OpenSolaris codebase 
> > on a regular basis.
> >
> > A fork is a codebase that no longer syncs with its ancestor, but is instead 
> > worked on independently, in parallel. A fork might import some desired 
> > functionality down the road, or might not, or might even prohibit importing 
> > anything from a particular codebase.
> 
> That doesn't sound like any accepted definition of fork I've seen, the
> definition here:
> 
> http://en.wikipedia.org/wiki/Software_fork
> 
> ...basically says that taking a copy of source code and doing
> independent development qualifies.
> 
> Well, all three of those distributions took a copy of the source code
> (it says nothing about continuing to update that copy) and performed
> independent development.
> 
> Meaning, all of them had changes that are or were not integrated back
> into ON, etc.
> 
> As a result, they are *different* from the originals in certain areas,
> and therefore are not a straight copy and qualify as a fork in my
> mind.
> 
> Are they harmful forks? I doubt it; but to me, they are forks.

Wikipeida is far from the last word on anything.  For example, see
below:

"A fork is a competing project based on a version of the pre-existing
project’s source code. All OSS/FS projects can be “forked”; the ability
to create a fork is fundamental to the definition of OSS/FS.

Simply creating or releasing a variant of a project’s code does not
normally create a fork unless there’s an intent to create a competing
project. Indeed, releasing variants for experimentation is considered
normal in a typical OSS/FS development process. Many OSS/FS projects
(such as the Linux kernel development project) intentionally have
“fly-offs” (also called “bake-offs”) where different developers
implement different competing approaches; the results are compared and
the approach that produces the best results (the “winner”) is accepted
by the project. These “fly-offs” are often discussed in evolutionary
terms, e.g., the “winning mutation” is accepted into the project and
the alternatives are abandoned as “evolutionary dead ends”. Since all
parties intend for the “best” approach to accepted by the project, and
for the other approaches to be abandoned, these are not forks.

What is different about a fork is intent. In a fork, the person(s)
creating the fork intend for the fork to replace or compete with the
original project they are forking."



The first and last paragraphs above, in particular, sum up my
historical understanding of the term.  Yes, there are specialized
cases/exceptions, as exemplified in paragraph 2.  But the general
meaning as a stand alone term would be closer to that in para's 1 & 3.

Thank you and have a nice day:)

-- 
Best regards,

Ken Gunderson

Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Alan Coopersmith]

Joerg Schilling wrote:
> Good question, but I don't know. The problem I see with Xscreensaver is that
> it is installed suid root on SXCE and thus is unable to read ~/.Xauthority
> from NFS mounted home directories. Removing the suid root did fix the problem 
> for me.

And broke the ability for it to read /etc/shadow for locally-defined
users to be able to unlock the screen.We don't make things suid-root
without a damn good reason.

-- 
-Alan Coopersmith-   [EMAIL PROTECTED]
 Sun Microsystems, Inc. - X Window System Engineering

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

Kyle McDonald <[EMAIL PROTECTED]> wrote:

> For instance, I understand that in the linux world 'DBUS' and 'HAL' have 
> come from the same (or closely connected) community that GNOME comes 
> from. So I don't see a problem with the GNOME team at sun being 
> responsible for integrating them into Solaris.

I see a problem from  the fact that ON now depends on GNOME.

If someone likes to create a GPL-free base OS (e.g. to run on embedded
hardware), things become hard to manage. I believe we need a rule set like
the FreeBSD people have that grants a functional base OS with code that
onlce uses a "free enough" license to allow embedded devices.


> But when the program that manages automatically mounting removable media 
> was integrated and required these API's, libraries, and daemons, I think 
> it should have been obvious to move them to some other more 'system 
> level' package and not allowed to stay in large GNOME packages that have 
> a multitude of other package dpenedencies. Right now you can't install a 
> headless machine without GNOME that will still mount a CD when it's 
> inserted.

See above ;-), we need some general rules for what may be integrated under which
constraints.

> Another example, is Xscreensaver. I always used to be able install that 
> with only X11 installed. Now not only does GNOME have to be installed 
> too, So does large portions of Evolution!! What on earth does Evolution 
> have to do with a ScreenSaver?

Good question, but I don't know. The problem I see with Xscreensaver is that
it is installed suid root on SXCE and thus is unable to read ~/.Xauthority
from NFS mounted home directories. Removing the suid root did fix the problem 
for me.

> So, If attention is paid to dependencies, and the likely use-cases when 
> the files are divided among packages, I don't have much problem with 
> this additional software. But today it's already too much like linux for 
> me. The situtation described above about upgrading one piece, and being 
> forced to upgrade half the machine is for me here already. I can't 
> remove a large number of pacakgeswithout removing ones I want. I can't 
> add ones I want without adding a huge number of pacakge I don't want.

The more complex the relations between different packages become, the harder it 
is to "correctly" deal with the relateed problems.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

"Shawn Walker" <[EMAIL PROTECTED]> wrote:

> > There is of course a better choice: foster the UNIX tools instead of merely
> > leaving them alone for more than 10 years.
>
> The past cannot be changed Joerg. Arguing about the past is fruitless.

If you like to define the future, you cannot ignore the past.



> > I am not sure what you are talking about: GNU tools in many cases reinvent 
> > the
> > wheel - even if you are talking about free implementations (star is 4 years
> > older than GNU tar and smake is 5 years older than GNU make, I am sure there
> > are a lot more similar examples).
>
> I wasn't talking about reinventing other wheels; only the GNU wheel.

Which "GNU wheel"?

> I didn't say that all tools should replace what Solaris has. The GNU
> userland is an appropriate choice in many cases though for developer
> familiarity.

I believe that people who like the GNU tools could use them but people who 
prefer the UNIX tools should have the opportunity to do so.


> > If Sun publishes a new developer version ov ON_NV, nobody expects that the
> > people who did cause the changes in this release aproach me and help me to
> > integrate their changes into a e.g. new SchilliX release. They just publish
> > the source code and make it available for me to take.
>
> I don't follow. Why does Sun need to contact you about anything?

I was trying to explain that we need a reality oriented way of dealing with 
each other.


> > If I take some free code (from where ever), e.g. even from unmaintained 
> > parts
> > of ON_NV. If I then fix bugs and add new features, people are waiting for 
> > since
> > some time and if I than just publish my fixed/enhanced sources, these 
> > sources
> > are available to be taken by interested people even from inside Sun. These
> > people may integrate my fixes and enhancements into the official Sun source,
> > but they cannot expect that I will spend my time on this integration as I
> > cannot expect that Sun people integrate their changes into my projects (like
> > e.g. SchilliX). They may ask me for help, but I will not stalk behind them.
>
> Nor should you expect them to take those fixes or enhancements unless
> someone is willing to take the time to integrate them.

But I don't like to read people from Sun whining that I don't integrate things.


> If Sun wants them, they can get them, as you point out. If the
> community wants them, they can spend the necessary effort to get them
> integrated.

Here you seem to confuse things. The use of the word "community" is 
inapropriate in this context. It is currently impossible for the community to 
add things to ONNV. This can only be done by Sun employees.


> I haven't seen complaints from Sun employees about "why hasn't Joerg
> integrated star yet?"

It seems that you missed complaints. Note that I did not introduce "star" 
hereso let me remove your star paragraph...


> > Things may be a bit different in case that the people who do the work may 
> > also
> > decide on integration and get write access to the official Sun Source
> > This is (at least curently) not the case and for this reason, Sun needs to 
> > hold
> > enough people to be able to integrate available fixes/changes or people from
> > the OpenSolaris community may lose interest.
>
> Under the current model, I agree with that. Though I suspect this will
> change (hopefully) soon.

This will only work if we replace ARC with something that apropriately fits the 
needs of a OSS and community based development.


> > You either need to collaborate with the people who do the work or you need 
> > to
> > do the work yourself.
>
> That part I'll agree on with the understanding that collaboration
> doesn't mean community members telling Sun what they must or must not
> do.

As long as noone from Sun is whining about things not done by community 
members..

> I would expect Sun's actions to be driven by their business needs; not
> community ultimatums.

Some actions not yet done by Sun people definitely should be done because there 
is a need for the results. The problem is that some people complain that people 
from the community don't do things they cannot yet do.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Shawn Walker]

On Feb 5, 2008 9:42 AM, UNIX admin <[EMAIL PROTECTED]> wrote:
> > It just so happens that GNU/Linux is one of those
> > platforms from which
> > certain evaluations are drawn.
>
> Yeah well, I can tell you that it would have been much more useful to draw 
> from operating systems which got things right, like HP-UX, and IRIX in 
> particular! Even FreeBSD has features that would be desireable in OpenSolaris.
>

I'm not sure what we could learn in terms of developer accessibility
or approachability from dead or dormant platforms.

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Shawn Walker]

On Feb 5, 2008 9:37 AM, UNIX admin <[EMAIL PROTECTED]> wrote:
> > I'd be very surprised if someone rewrote history to
> > declare Indiana
> > the cause of the first OpenSolaris fork, given that
> > we've already
> > got Nexenta, Schillix, Belenix and Martux.
>
> Those aren't forks, since they sync up with the main OpenSolaris codebase on 
> a regular basis.
>
> A fork is a codebase that no longer syncs with its ancestor, but is instead 
> worked on independently, in parallel. A fork might import some desired 
> functionality down the road, or might not, or might even prohibit importing 
> anything from a particular codebase.

That doesn't sound like any accepted definition of fork I've seen, the
definition here:

http://en.wikipedia.org/wiki/Software_fork

...basically says that taking a copy of source code and doing
independent development qualifies.

Well, all three of those distributions took a copy of the source code
(it says nothing about continuing to update that copy) and performed
independent development.

Meaning, all of them had changes that are or were not integrated back
into ON, etc.

As a result, they are *different* from the originals in certain areas,
and therefore are not a straight copy and qualify as a fork in my
mind.

Are they harmful forks? I doubt it; but to me, they are forks.

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[UNIX admin]

> It just so happens that GNU/Linux is one of those
> platforms from which
> certain evaluations are drawn.

Yeah well, I can tell you that it would have been much more useful to draw from 
operating systems which got things right, like HP-UX, and IRIX in particular! 
Even FreeBSD has features that would be desireable in OpenSolaris.

Apart from being all hype, Linux brings nothing worthwhile to assimilate. 
Linux's software already runs on Solaris, so there's nothing worthwile from 
Linux there. No technology in Linux is worth copying.

It's basically all GNU. And GNU is not UNIX. If I had wanted GNU, I would be 
running Linux, not Solaris and HP-UX.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[UNIX admin]

> I'd be very surprised if someone rewrote history to
> declare Indiana
> the cause of the first OpenSolaris fork, given that
> we've already
> got Nexenta, Schillix, Belenix and Martux.

Those aren't forks, since they sync up with the main OpenSolaris codebase on a 
regular basis.

A fork is a codebase that no longer syncs with its ancestor, but is instead 
worked on independently, in parallel. A fork might import some desired 
functionality down the road, or might not, or might even prohibit importing 
anything from a particular codebase.

So in that sense, none of the distros you mentioned above are forks. They are 
all based on OpenSolaris, and draw from it on a regular basis.

It is, on the other hand, highly questionable whether syncing up with "Indiana" 
would be desirable if it came to a true OpenSolaris fork. In my belief, such an 
action would be highly undesirable, hence the fork!
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Alan Coopersmith]

Kyle McDonald wrote:
> Another example, is Xscreensaver. I always used to be able install that 
> with only X11 installed. Now not only does GNOME have to be installed 
> too, So does large portions of Evolution!! What on earth does Evolution 
> have to do with a ScreenSaver?

In order to support users who need accessibility helpers to unlock their
screens, Sun modified xscreensaver to use a GTK-based unlock dialog and
the GNOME accessibility framework.   It should only depend on the GNOME
base libraries - I have no idea why there would be any linkage to
Evolution unless the GNOME base libraries or accessibility packages brings
them in - the package dependencies in xscreensaver's package (SUNWxwsvr)
don't specify them.


-- 
-Alan Coopersmith-   [EMAIL PROTECTED]
 Sun Microsystems, Inc. - X Window System Engineering
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[ken mays]

On Mon, 4 Feb 2008 21:49:04 -0600
"Shawn Walker" <[EMAIL PROTECTED]> wrote:

> On Feb 4, 2008 7:30 PM, Ken Gunderson
<[EMAIL PROTECTED]> wrote:
> > On Sun, 3 Feb 2008 12:27:41 -0600
> > "Shawn Walker" <[EMAIL PROTECTED]> wrote:
> >
> > > On Feb 3, 2008 12:14 PM, Ken Gunderson
<[EMAIL PROTECTED]>
 wrote:
> > > > On Sun, 03 Feb 2008 07:01:18 PST
> > > > "Dr. Robert Pasken" <[EMAIL PROTECTED]>
wrote:
> > > >
> > > > > I thought it was a mistake to bring any sort
of linux
 flavoring into Solaris and I won't deal with anything
that has to do with
 Indiana or any other attempt to make Solaris look/act
like linux. I use
 Solaris because it is Unix, is stable and meets some
minimum standards for
 useability. Linux is a train wreck that hasn't come
to a complete stop
 yet. Compared to windows, linux is a paragon of
stability, compared to
 Solaris it makes me think of windows
> > > > >
> > > >
> > > > +1
> > >
> > > Except, as was later discovered, this isn't
about making things
 "like
> > > Linux"; it's about making the OS more accessible
to users and
> > > developers.
> > >
> > > It just so happens that GNU/Linux is one of
those platforms from
 which
> > > certain evaluations are drawn.


The issue that was faced many years ago and started
causing grief was porting 'FOSS' to Sun Solaris 8.
Many companies went with Linux based on personnel
trained from academia. I'd think it is easy to figure
out the rest.

Around the turn of Y2000, many Solaris admins wanted
to use Solaris in similar ways they were trained on
using Linux. This was a costly venture for many
Solaris developers or admins as the tools were not
ported back then or known to the general Solaris
community. This was known as the 'dark ages' of FOSS
development and GNU userland tools on Sun Solaris
platforms. Many of us had Linux or *BSD as guides to
what we needed to do to bring more application
developers, users, and sysadmins to Solaris. Even for
ISVs using Linux and *BSD as backend servers, the need
was there but the toolsets were not. That all needed
to change and we needed a model to go by. Well, what
free UNIX-based OSes were leading the market and had a
lot of open source software developers in academia
using it for corporate solutions?!?

So, let us not backhand Linux (or any other OS) for
the wrong reasons.

The OpenSolaris community and the ported packages have
almost caught up to the largest Linux distro provider
- Debian (4 DVDs strong and growing as of 01/2008).
This is something that other commercial UNIX OS
providers attempted many years ago, but never fully
achieved to completion or properly maintained for
several years. This is not so much 'to be just like
Linux' but to help businesses and academia migrate
*FULLY* FROM the Linux kernel - if needed or
requested. Cross platform application development and
portability needs in the commercial marketplace
outweight the "who's on first" mindsets.

This goes from development firms running massive
renderfarms, supercomputers, visualization and movie
studios, ISV/IHV, ISP/ASP, and many more companies.
All of those businesses might currently be using Linux
(or MS Windows) on the backend only because of
academic reasoning or skilled employment lacking
Solaris OS training, advanced knowledge, or
development.

~ Ken Mays
"... Son, we live in a world that has walls. And those
walls have to be guarded by men with guns. Who's gonna
do it? You? - Jessep (Movie: A Few Good Men)"


  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Shawn Walker]

On Feb 5, 2008 8:33 AM,  <[EMAIL PROTECTED]> wrote:
>
> >On Feb 5, 2008 4:50 AM,  <[EMAIL PROTECTED]> wrote:
> >>
> >> >/bin/sh is something different, it is not a Korn Shell but a Bourne S=
> >> >hell.
> >>
> >> And it cannoit really be made compatible without breaking ksh.
> >>
> >> (And while we can fix our scripts to work fine with ksh/ksh93,
> >> customer scripts breakage will be different)
> >
> >I'm not convinced of that yet.
>
>
> It's trivial to write a script which behaves different under ksh93
> than it would under /bin/sh and which contains valid "sh" syntax.

I know that, but I'm not convinced that there is no solution to that
problem yet.

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Shawn Walker]

On Feb 5, 2008 6:15 AM, Joerg Schilling
<[EMAIL PROTECTED]> wrote:
> "Shawn Walker" <[EMAIL PROTECTED]> wrote:
>
> > While I wish that there were better options than GNU userland in terms
> > of functionality, the reality is that the majority of the open source
> > world has chosen the GNU toolset, for better or worse, as their
> > toolset of choice.
>
> There is of course a better choice: foster the UNIX tools instead of merely
> leaving them alone for more than 10 years.

The past cannot be changed Joerg. Arguing about the past is fruitless.

The point is where we are at now.

> > Wasting precious resources on attempting to reinvent the GNU wheel,
> > all in the name of (mostly) pride and arrogance, isn't going to win
> > any battles.
>
> I am not sure what you are talking about: GNU tools in many cases reinvent the
> wheel - even if you are talking about free implementations (star is 4 years
> older than GNU tar and smake is 5 years older than GNU make, I am sure there
> are a lot more similar examples).

I wasn't talking about reinventing other wheels; only the GNU wheel.


> But even switching to a "GNU userland" is not the solution for an unattended
> UNIX userland. Switching to software that is maintained by other people still
> only works for a short period of time if you do not like to spend the time for
> dealing with upstream enhancements/fixes.
>
> And last but not least: a few years ago, there was a discussion on c.u.s about
> "slow Solaris sort(1)" and it turned out that GNU sort did not support to sort
> e.g Japanese text. After GNU sort was enhanced, it was much slower than
> GNU sort and the GNU sort maintainer (Paul Eggert) asked Sun to put sort under
> an OSS license. You seee, other people are interested in UNIX tools!

I didn't say that all tools should replace what Solaris has. The GNU
userland is an appropriate choice in many cases though for developer
familiarity.

> Finally (you have been warned already), I need to explain how OSS works with
> respect to integrating new features:

Warned? I wasn't aware there were rules.

> If Sun publishes a new developer version ov ON_NV, nobody expects that the
> people who did cause the changes in this release aproach me and help me to
> integrate their changes into a e.g. new SchilliX release. They just publish
> the source code and make it available for me to take.

I don't follow. Why does Sun need to contact you about anything?

> If I take some free code (from where ever), e.g. even from unmaintained parts
> of ON_NV. If I then fix bugs and add new features, people are waiting for 
> since
> some time and if I than just publish my fixed/enhanced sources, these sources
> are available to be taken by interested people even from inside Sun. These
> people may integrate my fixes and enhancements into the official Sun source,
> but they cannot expect that I will spend my time on this integration as I
> cannot expect that Sun people integrate their changes into my projects (like
> e.g. SchilliX). They may ask me for help, but I will not stalk behind them.

Nor should you expect them to take those fixes or enhancements unless
someone is willing to take the time to integrate them.

If Sun wants them, they can get them, as you point out. If the
community wants them, they can spend the necessary effort to get them
integrated.

I haven't seen complaints from Sun employees about "why hasn't Joerg
integrated star yet?"

Instead, I've only seen complaints from others about why Sun hasn't done it yet.

The only thing I have seen Sun employees do is point out that star, or
anything else, requires the efforts of a member of the community for
them to be integrated.

We should not expect Sun to do everything.

> Things may be a bit different in case that the people who do the work may also
> decide on integration and get write access to the official Sun Source
> This is (at least curently) not the case and for this reason, Sun needs to 
> hold
> enough people to be able to integrate available fixes/changes or people from
> the OpenSolaris community may lose interest.

Under the current model, I agree with that. Though I suspect this will
change (hopefully) soon.

> You either need to collaborate with the people who do the work or you need to
> do the work yourself.

That part I'll agree on with the understanding that collaboration
doesn't mean community members telling Sun what they must or must not
do.

I would expect Sun's actions to be driven by their business needs; not
community ultimatums.

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

"Shawn Walker" <[EMAIL PROTECTED]> wrote:

> On Feb 5, 2008 4:50 AM,  <[EMAIL PROTECTED]> wrote:
> >
> > >/bin/sh is something different, it is not a Korn Shell but a Bourne S=
> > >hell.
> >
> > And it cannoit really be made compatible without breaking ksh.
> >
> > (And while we can fix our scripts to work fine with ksh/ksh93,
> > customer scripts breakage will be different)
>
> I'm not convinced of that yet.

Stability works the other way round... you would need to convince us 
that there is no problem.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

"Shawn Walker" <[EMAIL PROTECTED]> wrote:

> > There is a plan to create complatibility to /bin/ksh which is based on 
> > ksh88.
> >
> > /bin/sh is something different, it is not a Korn Shell but a Bourne Shell.
>
> I know that; but the version we have is also very limited.
>
> I know Roland believes that ksh93 can replace /sbin/sh.

It may be that he believes so, but there have been many people with objections.

I don't believe it makes sense to make shell scripts from users to fail because
/bin/sh does no longer behave like the Bourne Shell.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Casper . Dik]

>On Feb 5, 2008 4:50 AM,  <[EMAIL PROTECTED]> wrote:
>>
>> >/bin/sh is something different, it is not a Korn Shell but a Bourne S=
>> >hell.
>>
>> And it cannoit really be made compatible without breaking ksh.
>>
>> (And while we can fix our scripts to work fine with ksh/ksh93,
>> customer scripts breakage will be different)
>
>I'm not convinced of that yet.


It's trivial to write a script which behaves different under ksh93
than it would under /bin/sh and which contains valid "sh" syntax.

Casper

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Kyle McDonald]

Joerg Schilling wrote:
> I still cannot understand why a Sun controlled login (via PAM) depends on 
> Mozilla's  /usr/lib/mps/libssl3.so but /usr/sbin/pkgadd depends on 
> /usr/sfw/lib/libssl.so.0.9.8
>
>   
This is the problem I'm more concerned about than including the 'Linux 
Suite' of software.

I'm more concerned about Solaris *depending* on this mulittude of 
libraries and binaries strewn all across the filesystem and more 
importantly the packages.

I'm still of the belief that having the 'linux suite' is nice to have 
for people looking for it, I don't have a problem with installing it by 
default even, but it should be optional, and easily removed.I think we 
should all think hard and set some hard and fast rules for what and how 
other parts of solaris can depend on them.

I'm happy to see new things in Solaris, and the work on the packing 
system software is welcome. I just think that the way pieces of solaris 
are allowed to depend on other things, and the way the files are divided 
into packages is a much bigger problem than the technology available to 
install and remove, and manage these packages.

For instance, I understand that in the linux world 'DBUS' and 'HAL' have 
come from the same (or closely connected) community that GNOME comes 
from. So I don't see a problem with the GNOME team at sun being 
responsible for integrating them into Solaris.

But when the program that manages automatically mounting removable media 
was integrated and required these API's, libraries, and daemons, I think 
it should have been obvious to move them to some other more 'system 
level' package and not allowed to stay in large GNOME packages that have 
a multitude of other package dpenedencies. Right now you can't install a 
headless machine without GNOME that will still mount a CD when it's 
inserted.

Another example, is Xscreensaver. I always used to be able install that 
with only X11 installed. Now not only does GNOME have to be installed 
too, So does large portions of Evolution!! What on earth does Evolution 
have to do with a ScreenSaver?

So, If attention is paid to dependencies, and the likely use-cases when 
the files are divided among packages, I don't have much problem with 
this additional software. But today it's already too much like linux for 
me. The situtation described above about upgrading one piece, and being 
forced to upgrade half the machine is for me here already. I can't 
remove a large number of pacakgeswithout removing ones I want. I can't 
add ones I want without adding a huge number of pacakge I don't want.

And I don't accept the argument that 'Disk is cheap - Install it all!'

   -Kyle

The
> Jörg
>
>   

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Shawn Walker]

On Feb 5, 2008 4:50 AM,  <[EMAIL PROTECTED]> wrote:
>
> >/bin/sh is something different, it is not a Korn Shell but a Bourne S=
> >hell.
>
> And it cannoit really be made compatible without breaking ksh.
>
> (And while we can fix our scripts to work fine with ksh/ksh93,
> customer scripts breakage will be different)

I'm not convinced of that yet.

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Shawn Walker]

On Feb 5, 2008 4:42 AM, Joerg Schilling
<[EMAIL PROTECTED]> wrote:
> "Shawn Walker" <[EMAIL PROTECTED]> wrote:
>
> > On Feb 4, 2008 11:40 AM, Joerg Schilling
> > <[EMAIL PROTECTED]> wrote:
> > > "Shawn Walker" <[EMAIL PROTECTED]> wrote:
> > >
> > > > > If someone at Sun is interested to take the current code, he is 
> > > > > welcome!
> > > > > I am currently working on fixing bugs in "sh" and making it portable 
> > > > > enough
> > > > > to allow it to be included in the "schily consolidation"
> > > >
> > > > Joerg, pardon, but Roland and many others did all of the work to get
> > > > /sbin/sh to be replaced by ksh93.
> > >
> > > AFAIK, there is no decision to replace /bin/sh by ksh93.
> >
> > I believe there is a plan to do that though, and that it will eventually 
> > happen.
>
> Please join the ksh93 project and read the mail archives.

I have and do.

> There is a plan to create complatibility to /bin/ksh which is based on ksh88.
>
> /bin/sh is something different, it is not a Korn Shell but a Bourne Shell.

I know that; but the version we have is also very limited.

I know Roland believes that ksh93 can replace /sbin/sh.

I believe it can be done too.

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[James Carlson]

Joerg Schilling writes:
> I am in fear that Solaris cannot
> 
> In the past years, Solaris stability rules have not been followed as usual 
> and 
> it seems this has been done because of lack of payed time inside Sun.

Please stop passing around FUD.

If you can cite any point in which we haven't followed the rules, then
name it explicitly.  Otherwise, I would greatly appreciate it if you
could stop bad-mouthing Solaris and OpenSolaris on these lists.  For
someone who claims to care about this project (and who participates in
a lot of its mailing lists), you seem to spend a terrific amount of
your time trying to tear it down.

> I still cannot understand why a Sun controlled login (via PAM) depends on 
> Mozilla's  /usr/lib/mps/libssl3.so but /usr/sbin/pkgadd depends on 
> /usr/sfw/lib/libssl.so.0.9.8

What on Earth does that have to do with stability rules?

Is it impossible to consider that separate project teams might
possibly have different technical or marketing contraints on their
projects that could lead them to make different implementation
choices?  Or that they may have been designed at different times when
certain options were not available?

Or is there really One True SSL Implementation?

If you've got a concern here, then please do contact the relevant
community groups (they'd be security-discuss and install-discuss,
respectively) or file a bug.

Making wild claims and accusations against Sun's ability to follow its
own rules is at least unhelpful, and probably also a waste of your
time if you're expecting anyone to take these complaints seriously.

-- 
James Carlson, Solaris Networking  <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

James Carlson <[EMAIL PROTECTED]> wrote:

> Joerg Schilling writes:
> > I am in fear that Solaris cannot
> > 
> > In the past years, Solaris stability rules have not been followed as usual 
> > and 
> > it seems this has been done because of lack of payed time inside Sun.
>
> Please stop passing around FUD.

It would be really nice if you did try to expose yourself with my text instead 
of sendig FUD.

I did explain my objections and unless you are willing to comment this in a way
that shows interest in my statements, please just don't post

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

"Shawn Walker" <[EMAIL PROTECTED]> wrote:

> While I wish that there were better options than GNU userland in terms
> of functionality, the reality is that the majority of the open source
> world has chosen the GNU toolset, for better or worse, as their
> toolset of choice.

There is of course a better choice: foster the UNIX tools instead of merely
leaving them alone for more than 10 years.

> Wasting precious resources on attempting to reinvent the GNU wheel,
> all in the name of (mostly) pride and arrogance, isn't going to win
> any battles.

I am not sure what you are talking about: GNU tools in many cases reinvent the 
wheel - even if you are talking about free implementations (star is 4 years 
older than GNU tar and smake is 5 years older than GNU make, I am sure there 
are a lot more similar examples).


But even switching to a "GNU userland" is not the solution for an unattended
UNIX userland. Switching to software that is maintained by other people still 
only works for a short period of time if you do not like to spend the time for 
dealing with upstream enhancements/fixes.

And last but not least: a few years ago, there was a discussion on c.u.s about
"slow Solaris sort(1)" and it turned out that GNU sort did not support to sort
e.g Japanese text. After GNU sort was enhanced, it was much slower than 
GNU sort and the GNU sort maintainer (Paul Eggert) asked Sun to put sort under 
an OSS license. You seee, other people are interested in UNIX tools!



Finally (you have been warned already), I need to explain how OSS works with 
respect to integrating new features:

If Sun publishes a new developer version ov ON_NV, nobody expects that the 
people who did cause the changes in this release aproach me and help me to 
integrate their changes into a e.g. new SchilliX release. They just publish 
the source code and make it available for me to take.

If I take some free code (from where ever), e.g. even from unmaintained parts 
of ON_NV. If I then fix bugs and add new features, people are waiting for since 
some time and if I than just publish my fixed/enhanced sources, these sources
are available to be taken by interested people even from inside Sun. These 
people may integrate my fixes and enhancements into the official Sun source, 
but they cannot expect that I will spend my time on this integration as I 
cannot expect that Sun people integrate their changes into my projects (like 
e.g. SchilliX). They may ask me for help, but I will not stalk behind them.


Things may be a bit different in case that the people who do the work may also
decide on integration and get write access to the official Sun Source
This is (at least curently) not the case and for this reason, Sun needs to hold 
enough people to be able to integrate available fixes/changes or people from 
the OpenSolaris community may lose interest. 

In any case: you don't get an evolving OS for free!

You either need to collaborate with the people who do the work or you need to 
do the work yourself.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

Ken Gunderson <[EMAIL PROTECTED]> wrote:

> Which brings us to Solaris. Can Solaris provide integrated, cohesive
> kernel and true unix userland in a stable and well performing package
> that is freely available, and hence able to compete on it's own
> technical merits with the freely available *BSD's and Linuxes?  I hope
> so. That's why I'm looking at it in the first place.  As a professional
> unix sysadmin I'm not too interested in yet another "Linux distro
> of the month" to play with nights and weekends because I have no other
> life. So what's the Solaris target market going to be, professionals or
> hobbyists? There's lots more of the latter if you're objective is
> mindshare with the pc hobbyist rags, etc., wh/may do quite well at
> raising visibility.  But I don't think these folks buy support
> contracts, nor are they likely to upgrade to Sun "big iron" sparc
> machines.

I am in fear that Solaris cannot

In the past years, Solaris stability rules have not been followed as usual and 
it seems this has been done because of lack of payed time inside Sun.

I believe that with Solaris there is currently a badly planned piling up of 
OSS projects. I call it badly planned because the rules change frequently and
every change pulls a train of tracks that stay for "compatibility reasons"

If we like to keep the legend of a well planned and stable Solaris, we need to
go back to the roots. 

Not following the latest trends may be a good idea if it helps to avoid 
mistakes.

Adding a software packet is only useful is there is enough manpower to follow
upstream ehancements.



I know that a clean environment is hard to build if you depend on decisions of 
upstream OSS authors. Look at ssl implementations on SXCD:

  10172  144 -rwxr-xr-x   1 root bin   131816 Nov  2 13:52 
/usr/lib/amd64/libgnutls-openssl.so.13.3.0
   5873  128 -rwxr-xr-x   1 root bin   121584 Nov  5 04:12 
/usr/lib/security/amd64/kmf_openssl.so.1
   2829  120 -rwxr-xr-x   1 root bin   108484 Nov  5 04:12 
/usr/lib/security/kmf_openssl.so.1
  20333   25 -rwxr-xr-x   1 root bin24752 Nov  2 14:15 
/usr/lib/python2.4/lib-dynload/64/_ssl.so
  20386   18 -rwxr-xr-x   1 root bin18232 Nov  2 14:15 
/usr/lib/python2.4/lib-dynload/_ssl.so
  31067  352 -rwxr-xr-x   1 root bin   350976 May 29  2007 
/usr/lib/mps/amd64/libssl3.so
  31075  288 -rwxr-xr-x   1 root bin   284616 May 29  2007 
/usr/lib/mps/libssl3.so
  10176  112 -rwxr-xr-x   1 root bin   103472 Nov  2 13:52 
/usr/lib/libgnutls-openssl.so.13.3.0
 3738814 -rwxr-xr-x   1 root bin 4056 Oct 23 00:23 
/usr/lib/purple-2/ssl-gnutls.so
 373882   11 -rwxr-xr-x   1 root bin10672 Oct 23 00:23 
/usr/lib/purple-2/ssl-nss.so
 3738836 -rwxr-xr-x   1 root bin 5188 Oct 23 00:23 
/usr/lib/purple-2/ssl.so
   6369  432 -rwxr-xr-x   1 root bin   428632 Nov  5 05:23 
/usr/sfw/lib/amd64/libssl.so.0.9.8
   6373  344 -rwxr-xr-x   1 root bin   339156 Nov  5 05:23 
/usr/sfw/lib/libssl.so.0.9.8
  22512  216 -r-xr-xr-x   1 root bin   204912 Nov  1 23:44 
/usr/apache/libexec/libssl.so
 117796  192 -r-xr-xr-x   1 root bin   187612 Nov  2 00:27 
/usr/apache2/libexec/mod_ssl.so
 249539   16 -r-xr-xr-x   1 root bin15376 Nov  2 01:08 
/usr/postgres/8.2/lib/sslinfo.so
 250666  112 -rwxr-xr-x   1 root bin99636 Nov  2 01:29 
/usr/php5/5.2.4/modules/openssl.so

I still cannot understand why a Sun controlled login (via PAM) depends on 
Mozilla's  /usr/lib/mps/libssl3.so but /usr/sbin/pkgadd depends on 
/usr/sfw/lib/libssl.so.0.9.8

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Casper . Dik]

>/bin/sh is something different, it is not a Korn Shell but a Bourne S=
>hell.

And it cannoit really be made compatible without breaking ksh.

(And while we can fix our scripts to work fine with ksh/ksh93,
customer scripts breakage will be different)

Casper

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

"Shawn Walker" <[EMAIL PROTECTED]> wrote:

> On Feb 4, 2008 11:40 AM, Joerg Schilling
> <[EMAIL PROTECTED]> wrote:
> > "Shawn Walker" <[EMAIL PROTECTED]> wrote:
> >
> > > > If someone at Sun is interested to take the current code, he is welcome!
> > > > I am currently working on fixing bugs in "sh" and making it portable 
> > > > enough
> > > > to allow it to be included in the "schily consolidation"
> > >
> > > Joerg, pardon, but Roland and many others did all of the work to get
> > > /sbin/sh to be replaced by ksh93.
> >
> > AFAIK, there is no decision to replace /bin/sh by ksh93.
>
> I believe there is a plan to do that though, and that it will eventually 
> happen.

Please join the ksh93 project and read the mail archives.

There is a plan to create complatibility to /bin/ksh which is based on ksh88.

/bin/sh is something different, it is not a Korn Shell but a Bourne Shell.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Ken Gunderson]

On Mon, 4 Feb 2008 21:49:04 -0600
"Shawn Walker" <[EMAIL PROTECTED]> wrote:

> On Feb 4, 2008 7:30 PM, Ken Gunderson <[EMAIL PROTECTED]> wrote:
> > On Sun, 3 Feb 2008 12:27:41 -0600
> > "Shawn Walker" <[EMAIL PROTECTED]> wrote:
> >
> > > On Feb 3, 2008 12:14 PM, Ken Gunderson <[EMAIL PROTECTED]> wrote:
> > > > On Sun, 03 Feb 2008 07:01:18 PST
> > > > "Dr. Robert Pasken" <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > I thought it was a mistake to bring any sort of linux flavoring into 
> > > > > Solaris and I won't deal with anything that has to do with Indiana or 
> > > > > any other attempt to make Solaris look/act like linux. I use Solaris 
> > > > > because it is Unix, is stable and meets some minimum standards for 
> > > > > useability. Linux is a train wreck that hasn't come to a complete 
> > > > > stop yet. Compared to windows, linux is a paragon of stability, 
> > > > > compared to Solaris it makes me think of windows
> > > > >
> > > >
> > > > +1
> > >
> > > Except, as was later discovered, this isn't about making things "like
> > > Linux"; it's about making the OS more accessible to users and
> > > developers.
> > >
> > > It just so happens that GNU/Linux is one of those platforms from which
> > > certain evaluations are drawn.
> > >
> > > If you'll note past discussions, FreeBSD has been in those evaluations 
> > > too.
> > >
> > > The user base of other operating systems is significantly larger; good
> > > products adapt to market expectations where possible and reasonable to
> > > do so.
> >
> > You're comparing apples and oranges here:
> 
> No, not really. For the purposes of this discussion, I wasn't
> comparing things at all. I was merely pointing out reference points
> that I believe have been used in making changes that will hopefully
> make OpenSolaris more approachable to users.
> 
> > Linux => GPL license.  Linux kernel bundled into assorted "distros" with
> > various GNU tools (Gnu's Not Unix, proclaimed loud and proud on their
> > homepage) and disparate userlands, etc., the components of which are
> > far from standardized.  Dependency nightmares during installs and
> > upgrades. When several _hundred_ RH boxes are borked because of sloppy
> > merges, etc., who cares that it's commercially "supported", you still
> > have one hell of a lot of unhappy customers yelling at you. Granted,
> > Linux has improved over the years, but still not without it's warts.
> 
> I fail to see what this has to do with anything that is being done
> with Project Indiana or OpenSOlaris in general.
> 
> Regardless of the problems that these platforms have, right now, they
> are the ones leading the market.

Oh really?  How sure are you about that, and by what criteria are you
defining "leading" and "market"?  EBay started out as a bunch of Linux
boxes. Then migrated to some HP stuff.  Then under Carly management HP
support headed downhill into the kitty-litter so badly that they
migrated to Sun. Yeah, there's still a bunch of white-box linux
webservers on front end, but what' running the back end?  How about
wikipedia? H... last I looked more and more nodes are running
clustered Sun iron to power backend DB. Amazon.com...  Hmmm... basic
story repeats again... How about Google. hmm.. bunches of
white-box linux machines but trialing Solaris.  Yahoo, used to be a
bunch of FreeBSD boxes, but in more recent years supplemented by
clustered Sun to run db backends.  Why might this be?  What itch is
Solaris doing such a good job of scratching here that it's supplanting
*BSD and Linux boxes.  I could be wrong, but here's my short list - it
scales, it clusters, it's stable, it's supported, and it apparently
does these things more reliably in these environments than the "market
leaders" it's replacing. Granted, it's a far cry from it's glory days
of the past, but it seems to me that the glass is still half full.

> > Which brings us to Solaris. Can Solaris provide integrated, cohesive
> > kernel and true unix userland in a stable and well performing package
> > that is freely available, and hence able to compete on it's own
> > technical merits with the freely available *BSD's and Linuxes?  I hope
> 
> I find the phrase "true unix userland" to be rather funny. Solaris
> ships with several flavours of "userland" utilities, many of which
> aren't even in the default path configuration.

Yeah, this was probably poor choice of words, as *BSD's include many
Gnu tools.  The point I wanted to make was that they releases were
cohesive whole, and updates released as cohesive whole.  So you get
much more stable experience overall w.r.t. the upgrade path.  No Linux
upgrade incongruencies that bork your system.  Anyone who's been around
Linux for any length of time and used it in production environment knows
what I'm talking about. 

> Most of the utilities in the default path (such as grep, etc.) are
> widely panned for the lack of modern functionality, updates, and
> numerous bugs.
> 
> While I personally I am very gratefu

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Shawn Walker]

On Feb 4, 2008 7:30 PM, Ken Gunderson <[EMAIL PROTECTED]> wrote:
> On Sun, 3 Feb 2008 12:27:41 -0600
> "Shawn Walker" <[EMAIL PROTECTED]> wrote:
>
> > On Feb 3, 2008 12:14 PM, Ken Gunderson <[EMAIL PROTECTED]> wrote:
> > > On Sun, 03 Feb 2008 07:01:18 PST
> > > "Dr. Robert Pasken" <[EMAIL PROTECTED]> wrote:
> > >
> > > > I thought it was a mistake to bring any sort of linux flavoring into 
> > > > Solaris and I won't deal with anything that has to do with Indiana or 
> > > > any other attempt to make Solaris look/act like linux. I use Solaris 
> > > > because it is Unix, is stable and meets some minimum standards for 
> > > > useability. Linux is a train wreck that hasn't come to a complete stop 
> > > > yet. Compared to windows, linux is a paragon of stability, compared to 
> > > > Solaris it makes me think of windows
> > > >
> > >
> > > +1
> >
> > Except, as was later discovered, this isn't about making things "like
> > Linux"; it's about making the OS more accessible to users and
> > developers.
> >
> > It just so happens that GNU/Linux is one of those platforms from which
> > certain evaluations are drawn.
> >
> > If you'll note past discussions, FreeBSD has been in those evaluations too.
> >
> > The user base of other operating systems is significantly larger; good
> > products adapt to market expectations where possible and reasonable to
> > do so.
>
> You're comparing apples and oranges here:

No, not really. For the purposes of this discussion, I wasn't
comparing things at all. I was merely pointing out reference points
that I believe have been used in making changes that will hopefully
make OpenSolaris more approachable to users.

> Linux => GPL license.  Linux kernel bundled into assorted "distros" with
> various GNU tools (Gnu's Not Unix, proclaimed loud and proud on their
> homepage) and disparate userlands, etc., the components of which are
> far from standardized.  Dependency nightmares during installs and
> upgrades. When several _hundred_ RH boxes are borked because of sloppy
> merges, etc., who cares that it's commercially "supported", you still
> have one hell of a lot of unhappy customers yelling at you. Granted,
> Linux has improved over the years, but still not without it's warts.

I fail to see what this has to do with anything that is being done
with Project Indiana or OpenSOlaris in general.

Regardless of the problems that these platforms have, right now, they
are the ones leading the market.

> Which brings us to Solaris. Can Solaris provide integrated, cohesive
> kernel and true unix userland in a stable and well performing package
> that is freely available, and hence able to compete on it's own
> technical merits with the freely available *BSD's and Linuxes?  I hope

I find the phrase "true unix userland" to be rather funny. Solaris
ships with several flavours of "userland" utilities, many of which
aren't even in the default path configuration.

Most of the utilities in the default path (such as grep, etc.) are
widely panned for the lack of modern functionality, updates, and
numerous bugs.

While I personally I am very grateful for the xpg4, xpg6, and other
standards compliant environments that are available; there is no
reason that the default userland has to resemble the olden days of the
pdp-11 :) (joking)

While I wish that there were better options than GNU userland in terms
of functionality, the reality is that the majority of the open source
world has chosen the GNU toolset, for better or worse, as their
toolset of choice.

Wasting precious resources on attempting to reinvent the GNU wheel,
all in the name of (mostly) pride and arrogance, isn't going to win
any battles.

Ivory tower attitudes will keep that tower sparkling white, so that
future generations may remember it fondly as they migrate to systems
that actually meet their needs.

> so. That's why I'm looking at it in the first place.  As a professional
> unix sysadmin I'm not too interested in yet another "Linux distro
> of the month" to play with nights and weekends because I have no other
> life. So what's the Solaris target market going to be, professionals or
> hobbyists? There's lots more of the latter if you're objective is
> mindshare with the pc hobbyist rags, etc., wh/may do quite well at
> raising visibility.  But I don't think these folks buy support
> contracts, nor are they likely to upgrade to Sun "big iron" sparc
> machines.

I'm not interested in a yet another "Linux distro of the month"
either; that's why I'm excited about things like: IPS, the
Distribution Constructor, Caiman, and others. All of these projects
are taking fairly different approaches to the same problems others
have tried to solve before. IPS, notably, stands out the most as being
widely divergent in its approach to packaging.

I would encourage you to approach the efforts of this community with
an open mind.

I do not believe for one moment that the engineers at Sun will replace
anything in Solaris without careful consideration a

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Ken Gunderson]

On Sun, 3 Feb 2008 12:27:41 -0600
"Shawn Walker" <[EMAIL PROTECTED]> wrote:

> On Feb 3, 2008 12:14 PM, Ken Gunderson <[EMAIL PROTECTED]> wrote:
> > On Sun, 03 Feb 2008 07:01:18 PST
> > "Dr. Robert Pasken" <[EMAIL PROTECTED]> wrote:
> >
> > > I thought it was a mistake to bring any sort of linux flavoring into 
> > > Solaris and I won't deal with anything that has to do with Indiana or any 
> > > other attempt to make Solaris look/act like linux. I use Solaris because 
> > > it is Unix, is stable and meets some minimum standards for useability. 
> > > Linux is a train wreck that hasn't come to a complete stop yet. Compared 
> > > to windows, linux is a paragon of stability, compared to Solaris it makes 
> > > me think of windows
> > >
> >
> > +1
> 
> Except, as was later discovered, this isn't about making things "like
> Linux"; it's about making the OS more accessible to users and
> developers.
> 
> It just so happens that GNU/Linux is one of those platforms from which
> certain evaluations are drawn.
> 
> If you'll note past discussions, FreeBSD has been in those evaluations too.
> 
> The user base of other operating systems is significantly larger; good
> products adapt to market expectations where possible and reasonable to
> do so.

You're comparing apples and oranges here:

FreeBSD => BSD license, BSD historic code base, integrated kernel and
unix userland.  The cohesiveness thereby gained resulted in significant
advantages in stability.  FBSD also out preformed Linux in many
scenarios up until major re-architecting decisions and 5.x resulted in
slow and buggy, 6.x got mostly stable but still slow, and 7.x promises
return to speed.  But.. the "linuxization" of FBSD and loss of key core
members have taken their toll so lot's of FBSD'ers are checking their
options.

Linux => GPL license.  Linux kernel bundled into assorted "distros" with
various GNU tools (Gnu's Not Unix, proclaimed loud and proud on their
homepage) and disparate userlands, etc., the components of which are
far from standardized.  Dependency nightmares during installs and
upgrades. When several _hundred_ RH boxes are borked because of sloppy
merges, etc., who cares that it's commercially "supported", you still
have one hell of a lot of unhappy customers yelling at you. Granted,
Linux has improved over the years, but still not without it's warts. 

Which brings us to Solaris. Can Solaris provide integrated, cohesive
kernel and true unix userland in a stable and well performing package
that is freely available, and hence able to compete on it's own
technical merits with the freely available *BSD's and Linuxes?  I hope
so. That's why I'm looking at it in the first place.  As a professional
unix sysadmin I'm not too interested in yet another "Linux distro
of the month" to play with nights and weekends because I have no other
life. So what's the Solaris target market going to be, professionals or
hobbyists? There's lots more of the latter if you're objective is
mindshare with the pc hobbyist rags, etc., wh/may do quite well at
raising visibility.  But I don't think these folks buy support
contracts, nor are they likely to upgrade to Sun "big iron" sparc
machines.

My $0.02.

-- 
Best regards,

Ken Gunderson

Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Shawn Walker]

On Feb 4, 2008 11:40 AM, Joerg Schilling
<[EMAIL PROTECTED]> wrote:
> "Shawn Walker" <[EMAIL PROTECTED]> wrote:
>
> > > If someone at Sun is interested to take the current code, he is welcome!
> > > I am currently working on fixing bugs in "sh" and making it portable 
> > > enough
> > > to allow it to be included in the "schily consolidation"
> >
> > Joerg, pardon, but Roland and many others did all of the work to get
> > /sbin/sh to be replaced by ksh93.
>
> AFAIK, there is no decision to replace /bin/sh by ksh93.

I believe there is a plan to do that though, and that it will eventually happen.

> And BTW: there are a few places where sh differs from ksh93 by definition.
> How do you like to deal with this problem?

>From what I can remember, the ksh93-integration team is working on the issue.

They have ways to deal with the few differences that currently exist.

I encourage you to join ksh93-integration-discuss, or to read the
mailing list archives there.

I think you'll be surprised at just how much has been done.

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

"Shawn Walker" <[EMAIL PROTECTED]> wrote:

> > If someone at Sun is interested to take the current code, he is welcome!
> > I am currently working on fixing bugs in "sh" and making it portable enough
> > to allow it to be included in the "schily consolidation"
>
> Joerg, pardon, but Roland and many others did all of the work to get
> /sbin/sh to be replaced by ksh93.

AFAIK, there is no decision to replace /bin/sh by ksh93.

And BTW: there are a few places where sh differs from ksh93 by definition.
How do you like to deal with this problem?

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Shawn Walker]

On Feb 4, 2008 10:58 AM, Joerg Schilling
<[EMAIL PROTECTED]> wrote:
> UNIX admin <[EMAIL PROTECTED]> wrote:
>
> > > So much of this reminds me of all the BSD-SVR4
> > > religion of 20 years ago.
> > > SunOS changed then to build something better, and
> > >  my view is that's to
> > > fair extent similar to what we're doing with
> > >  Indiana.
> >
> > Back then, Sun didn't "change". What was done is that Sun synced up with 
> > AT&T's code. Again. After all, AT&T's System V release 3 was the 
> > authoritative source of UNIX. So much so, that all the important BSD / Bill 
> > Joy's changes made it into SVR4, and not the other way around.
>
> When Indiana makes /sbin/sh /usr/bin/ksh93, this breaks compatibility.

There are only a few small cases where it does or might break
compatibility as far as the ksh93-integration team is aware of.

They intend to fix all of them as possible.

If you find a place where they are broken; please let them know.

They have worked very hard to ensure that it does not cause problems.

In the meantime, keeping the current /sbin/sh is foolish when there is
a better alternative and since there are OpenSolaris community members
already doing the necessary work.

> A compatible change that allows people to still have file name completion
> and a cursor editable history with /bin/sh is what I published with
> Schillix-0.6.1.
>
> If someone at Sun is interested to take the current code, he is welcome!
> I am currently working on fixing bugs in "sh" and making it portable enough
> to allow it to be included in the "schily consolidation"

Joerg, pardon, but Roland and many others did all of the work to get
/sbin/sh to be replaced by ksh93.

If you want do that that work for bsh; then go ahead.

Otherwise, please don't complain needlessly about ksh93.

Thanks,
-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Joerg Schilling]

UNIX admin <[EMAIL PROTECTED]> wrote:

> > So much of this reminds me of all the BSD-SVR4
> > religion of 20 years ago. 
> > SunOS changed then to build something better, and
> >  my view is that's to 
> > fair extent similar to what we're doing with
> >  Indiana.
>
> Back then, Sun didn't "change". What was done is that Sun synced up with 
> AT&T's code. Again. After all, AT&T's System V release 3 was the 
> authoritative source of UNIX. So much so, that all the important BSD / Bill 
> Joy's changes made it into SVR4, and not the other way around.

When Indiana makes /sbin/sh /usr/bin/ksh93, this breaks compatibility.

A compatible change that allows people to still have file name completion
and a cursor editable history with /bin/sh is what I published with 
Schillix-0.6.1.

If someone at Sun is interested to take the current code, he is welcome!
I am currently working on fixing bugs in "sh" and making it portable enough
to allow it to be included in the "schily consolidation"

ftp://ftp.berlios.de/pub/schily/

But the intermediate source is of course available to interested people.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Casper . Dik]

>Totally agree - this is exactly what happened recently on a Linux server
>I know of. But to say that the implementation is poor is to ignore the
>prime motivation for such a system - many admins are too busy to compile
>all their software from source, follow dependencies and finesse
>implementation quirks. The various Linux packaging/installation/update
>systems have been hacked, modified, recoded and reworked to fit the
>various goals of the distro creators and coders (c.f. the two "official"
>versions of RPM currently available). Is it not possible that the
>engineering expertise and coherent cooperative work that made the
>Solaris OE so stable, powerful and dependable could go further towards
>the goal of simple, reliable software administration than any of the
>various Linux efforts?


I think he's worried about the risk and the other point of not
having a single repository for all packages (that would be a utopian
vision).

The bit where this will likely breakdown first is the way to express
dependencies.  The proper way to express dependencies, IMHO, is:

- what level of functionality does this application need?
- which known bugs do affect his application and need to be
  addressed for it to run properly?

On Solaris, the first one is typically expressed as "Solaris X Y/Z" and
the second as "plus patch foo".

But on Linux this is typically addressed with "needs version X of package 
Y".

Unfortunately, there is no motivation at all in the latter case to look
for the smallest X possible; it's generally "current X as installed on the
developer's system".

Now, Solaris tries to strive for excellent compatibility between releases
and well-defined functional boundaries, so it stands to reason that we
can do better.

But it does not mean that such a packaging system does not at least carry 
the risk of going wrong.

If it's independent of Sun, you'll get the Blastwave effect (too much 
duplication with later OS releases).

A Sun maintained repository would be goodness, though I have yet to hear 
how this will pan out with out "patches are part of the $$ in our business 
model".  And it still doesn't quite explain to me how we will deal
with Acroread, flashplayer, Oracle, Veritas and other applications which 
will likely not be in Sun's repository, if only for variations of
"you can sell, distribute this, but not for resale or redistribution" 
license

>Having half of your software administered automatically is better than
>nothing. And package dependency resolution is an area where rigorous
>central administration can really set a package management system head
>and shoulders above the others. To say that to do it well is difficult
>does not mean it should not be attempted.

"Centrally" doesn't work unless it's also "Open" for everybody to put their
favorite software in.

Casper

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Chris Linton-Ford]

> I think he may want that, bu the claims he is NOT getting that from
> Linux; specifically the fact that installing one package causes half the
> system to be upgraded and parts to be crippled.
> 

Totally agree - this is exactly what happened recently on a Linux server
I know of. But to say that the implementation is poor is to ignore the
prime motivation for such a system - many admins are too busy to compile
all their software from source, follow dependencies and finesse
implementation quirks. The various Linux packaging/installation/update
systems have been hacked, modified, recoded and reworked to fit the
various goals of the distro creators and coders (c.f. the two "official"
versions of RPM currently available). Is it not possible that the
engineering expertise and coherent cooperative work that made the
Solaris OE so stable, powerful and dependable could go further towards
the goal of simple, reliable software administration than any of the
various Linux efforts?

> Such as system may work fine if all the software you ever use is in the
> repository (it generally isn't) and that if package "X"'s depenency 
> declaration of "X needs Y version A or later" is factual which requires
> proper backward compatibility for Y.

Having half of your software administered automatically is better than
nothing. And package dependency resolution is an area where rigorous
central administration can really set a package management system head
and shoulders above the others. To say that to do it well is difficult
does not mean it should not be attempted.

That was a bit more of a rant than I intended, but I really see big
potential for growth here.

Chris

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Casper . Dik]

>Can I just be clear on this - you don't want simplified, unified and
>tested software installation; you don't want easier access to the core
>OS software; and you don't want help from an extended community of
>peers?


I think he may want that, bu the claims he is NOT getting that from
Linux; specifically the fact that installing one package causes half the
system to be upgraded and parts to be crippled.

Such as system may work fine if all the software you ever use is in the
repository (it generally isn't) and that if package "X"'s depenency 
declaration of "X needs Y version A or later" is factual which requires
proper backward compatibility for Y.

And his story is one of many were this turns out not to be the case.

Casper

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Chris Linton-Ford]

On Sun, 2008-02-03 at 13:51 -0800, Dr. Robert Pasken wrote:
> >From the Project Indiana description on sun's web site
> Planned as an open source binary distribution of OpenSolaris, Project Indiana 
> is expected to create a user base and grow mindshare for OpenSolaris by 
> combining [b]what people like about Linux--the distribution model, community, 
> and packaging technology--[/b]with the unique technological features of the 
> Solaris OS.
> 
> Unfortunately these "features" are what's wrong with Linux. I [b]really[/b] 
> don't want a Ubuntu like packaging/installation system. I don't want a 
> "community" like linux. Try  installing a package like netperf and watch what 
> happens. I found it easier just to wipe the disk and install yet another 
> "distro". Or maybe the Ubuntu install system, which doesn't allow for root 
> access without jumping through hoops some of which aren't possible unless you 
> are root
>  

Can I just be clear on this - you don't want simplified, unified and
tested software installation; you don't want easier access to the core
OS software; and you don't want help from an extended community of
peers?

For great server OSes with these features:
http://www.microsoft.com/servers/os.mspx

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Dr. Robert Pasken]

>From the Project Indiana description on sun's web site
Planned as an open source binary distribution of OpenSolaris, Project Indiana 
is expected to create a user base and grow mindshare for OpenSolaris by 
combining [b]what people like about Linux--the distribution model, community, 
and packaging technology--[/b]with the unique technological features of the 
Solaris OS.

Unfortunately these "features" are what's wrong with Linux. I [b]really[/b] 
don't want a Ubuntu like packaging/installation system. I don't want a 
"community" like linux. Try  installing a package like netperf and watch what 
happens. I found it easier just to wipe the disk and install yet another 
"distro". Or maybe the Ubuntu install system, which doesn't allow for root 
access without jumping through hoops some of which aren't possible unless you 
are root
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Shawn Walker]

On Feb 3, 2008 12:14 PM, Ken Gunderson <[EMAIL PROTECTED]> wrote:
> On Sun, 03 Feb 2008 07:01:18 PST
> "Dr. Robert Pasken" <[EMAIL PROTECTED]> wrote:
>
> > I thought it was a mistake to bring any sort of linux flavoring into 
> > Solaris and I won't deal with anything that has to do with Indiana or any 
> > other attempt to make Solaris look/act like linux. I use Solaris because it 
> > is Unix, is stable and meets some minimum standards for useability. Linux 
> > is a train wreck that hasn't come to a complete stop yet. Compared to 
> > windows, linux is a paragon of stability, compared to Solaris it makes me 
> > think of windows
> >
>
> +1

Except, as was later discovered, this isn't about making things "like
Linux"; it's about making the OS more accessible to users and
developers.

It just so happens that GNU/Linux is one of those platforms from which
certain evaluations are drawn.

If you'll note past discussions, FreeBSD has been in those evaluations too.

The user base of other operating systems is significantly larger; good
products adapt to market expectations where possible and reasonable to
do so.

-- 
Shawn Walker, Software and Systems Analyst
http://binarycrusader.blogspot.com/

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Ken Gunderson]

On Sun, 03 Feb 2008 07:01:18 PST
"Dr. Robert Pasken" <[EMAIL PROTECTED]> wrote:

> I thought it was a mistake to bring any sort of linux flavoring into Solaris 
> and I won't deal with anything that has to do with Indiana or any other 
> attempt to make Solaris look/act like linux. I use Solaris because it is 
> Unix, is stable and meets some minimum standards for useability. Linux is a 
> train wreck that hasn't come to a complete stop yet. Compared to windows, 
> linux is a paragon of stability, compared to Solaris it makes me think of 
> windows
>  

+1 

-- 
Best regards,

Ken Gunderson

Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Dr. Robert Pasken]

I thought it was a mistake to bring any sort of linux flavoring into Solaris 
and I won't deal with anything that has to do with Indiana or any other attempt 
to make Solaris look/act like linux. I use Solaris because it is Unix, is 
stable and meets some minimum standards for useability. Linux is a train wreck 
that hasn't come to a complete stop yet. Compared to windows, linux is a 
paragon of stability, compared to Solaris it makes me think of windows
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[W. Wayne Liauh]

> Please do not tell me my
> attention on SXCE releases should be devoted to
> anything else until it is ready to help me.
> 
> Andrew Hettinger

The comment I made was actually intended for my own consumption.  There are a 
non-trivial number of us who religiously download and install each and every 
release of SXCE (used to be called SXCR).

IMNSHO, b/c the SXCE iso's are updated at such a high frequency (& this is not 
a Ubuntu, but a full-blown OS), unless every one of Sun's developers is a 
superman/superwowan, we shouldn't put too much expectation on the consistency 
of its quality.  Doing so would defeat its main purpose, i.e., to implement and 
test new features, and put too much uncalled-for pressure on its developers.  
Again, this is only my opinion, YMMV.

Indiana/"OpenSolaris", OTOH, offers a different mechanism for updates.  IIRC, 
it will allow a package-by-package update.  Of course, no one should be forced 
to like this idea.  But as Jordan mentioned, for those who are crazy enough to 
so frequently update their (or should I say, "our") SXCE, perhaps it is a good 
idea to be reminded once a while to also divert some of our vigors to it.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[MC]

John Weekley wrote:
> Someone from Sun told me a few years ago (ca. 2000 or
> so) that it cost Sun $17.00 per download, I don't recall how many
> successful downloads there were, but about the only money that flowed
> was from Sun to it's ISP's.

Bringing that up is FUD IMHO.  Internet economics were totally different back 
then.  Reality today is closer to "bandwidth is free".  

Not to mention the value they receive from inundating downloaders with Sun 
Microsystems branding and product advertisements, I expect Sun is paying less 
than a penny to serve a 4GB file.
 
 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[Tim Spriggs]

John Weekley wrote:
> Tim Spriggs wrote:
>   
>> John Weekley wrote:
>> 
>>> Someone from Sun told me a few years ago (ca. 2000 or
>>> so) that it cost Sun $17.00 per download, I don't recall how many
>>> successful downloads there were, but about the only money that flowed
>>> was from Sun to it's ISP's.
>>>   
>>>   
>> That is an amazing amount per download. I'm curious as to how that
>> figure was calculated and how relevant it is today.
>> 
> I can't say how it was calculated since I've never worked for Sin, and
> the  figure may not be relevant today.  But there's still a cost per
> download which new users may or may not choose to subsidize by buying
> Sun products and services.  My point was that new users should not b;e
> considered revenue. Potential revenue, yes, but not "money in the bank."
>   
I think we agree, my point is that not considering potential money is fatal.


___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] [osol-announce] No update on SXCE Build 79

[John Weekley]

Tim Spriggs wrote:
> John Weekley wrote:
>> Someone from Sun told me a few years ago (ca. 2000 or
>> so) that it cost Sun $17.00 per download, I don't recall how many
>> successful downloads there were, but about the only money that flowed
>> was from Sun to it's ISP's.
>>   
> That is an amazing amount per download. I'm curious as to how that
> figure was calculated and how relevant it is today.
I can't say how it was calculated since I've never worked for Sin, and
the  figure may not be relevant today.  But there's still a cost per
download which new users may or may not choose to subsidize by buying
Sun products and services.  My point was that new users should not b;e
considered revenue. Potential revenue, yes, but not "money in the bank."

John


___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org