Sage-3.0.5 Solaris-x86-sse3 binary

[mabshoff]

Hello folks,

since Sage on Solaris is more than a little tricky to build at the
moment I packaged up a 3.0.5 build at

http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.5/sage-3.0.5-sse3-i86pc-SunOS_BETA.tar.gz

Notice that it still has some serious bugs in it (41 doctests fail),
but it is self contained and as long as you have Solaris 10 and SSE3
it should be good enough to play around with. If there is interest I
can also provide a Sparc binary. Please provide some feedback in case
you care about Sage on Solaris.

I am in the process of adding more details on the known bug to

http://wiki.sagemath.org/solaris

Cheers,

Michael

[vbef...@gmail.com]

Hi,

Tried to answer earlier, but for some reason my answer didn't go
through ... Anyway, if it's not too much trouble to you, I am greatly
interested in a solaris9-sparc version, and I'm sure I'm not the only
one (even though potentially interested people might not subscribe to
this particular list).

I tried to build the thing myself, and was able to patch things up all
the way to ATLAS, where I had to give up. Along the way, I was
wondering: exactly how many of the packages are needed in order to
reach the sage: prompt ? Even if 'make' does not go smoothly, some
functionality is better than nothing I guess ... and sage as a package
manager for its packages would still be extremely useful even if some
of them don't build out of the box.

BTW, do you have building instructions written somewhere ? I am
willing to experiment, but I would need a starting point ...

Thanks for all your work in any case !

/vincent

[mabshoff]

On Jul 15, 7:29 am, "vbeffara...@gmail.com" <vbeff...@gmail.com>
wrote:
> Hi,

Hi Vincent

> Tried to answer earlier, but for some reason my answer didn't go
> through ...

Yeah, some times Google groups is a little funny in that regard.

> Anyway, if it's not too much trouble to you, I am greatly
> interested in a solaris9-sparc version, and I'm sure I'm not the only
> one (even though potentially interested people might not subscribe to
> this particular list).

I have had Solaris 9/Sparc builds in the past. Since clisp does not
compile properly on any Sparc box I ever tried I have moved to Solaris
10/Intel for now as primary port platform. Once we switch from clisp
to ecl a Solaris 9/Sparc port should be doable. There was some trouble
in Givaro due to them using fenv.h which is not present on Solaris
before and including Solaris 10, but IIRC that code has been removed.
So in short: It is likely that by mid to late August I can provide you
with such a binary, but not at the moment.

> I tried to build the thing myself, and was able to patch things up all
> the way to ATLAS, where I had to give up.

Which gcc did you use? I used a gcc 4.3.0 with GNU binutils 2.18 and
did not hit any trouble.

> Along the way, I was
> wondering: exactly how many of the packages are needed in order to
> reach the sage: prompt ? Even if 'make' does not go smoothly, some
> functionality is better than nothing I guess ... and sage as a package
> manager for its packages would still be extremely useful even if some
> of them don't build out of the box.

This is tricky and you do not to get past the Sage library stage. Then
you need Maxima, GAP and pyprocessing and Sage should start up.

> BTW, do you have building instructions written somewhere ? I am
> willing to experiment, but I would need a starting point ...

I have a bunch of rather cryptic notes which has fixes that should
mostly go into Sage 3.0.6.alpha0 which should happen in the next 24 to
48 hours. My main focus in the next two to three months are the
Solaris, native Windows and OSX 64 bit port (in order of priority :)).
As I mentioned the 3.0.5 binary works better than any other Sage
release on Solaris in the last 15 months and I tracked down a number
of issues to numpy doing bad things. At the moment 41 doctests fail of
which about 20 are trivial failures that are caused by maybe 2, 3
bugs. So things are looking up.

> Thanks for all your work in any case !

No problem. The more people play with the Solaris binary the better. I
can also offer an SSE2 Opteron build, but my access to that box will
cease while I am on the road starting in two days until I get back.

>     /vincent

Cheers,

Michael

[mabshoff]

On Jul 15, 8:30 am, mabshoff <mabsh...@googlemail.com> wrote:
> On Jul 15, 7:29 am, "vbeffara...@gmail.com" <vbeff...@gmail.com>
> wrote:
>
> > Hi,
>
> Hi Vincent

Sorry for the noise, I hit send by accident before rereading the email
and I need to correct some things:

> > Tried to answer earlier, but for some reason my answer didn't go
> > through ...
>
> Yeah, some times Google groups is a little funny in that regard.
>
> > Anyway, if it's not too much trouble to you, I am greatly
> > interested in a solaris9-sparc version, and I'm sure I'm not the only
> > one (even though potentially interested people might not subscribe to
> > this particular list).
>
> I have had Solaris 9/Sparc builds in the past. Since clisp does not
> compile properly on any Sparc box I ever tried I have moved to Solaris
> 10/Intel for now as primary port platform. Once we switch from clisp
> to ecl a Solaris 9/Sparc port should be doable. There was some trouble
> in Givaro due to them using fenv.h which is not present on Solaris
> before and including Solaris 10, but IIRC that code has been removed.

before and including *Solaris 9*

> So in short: It is likely that by mid to late August I can provide you
> with such a binary, but not at the moment.
>
> > I tried to build the thing myself, and was able to patch things up all
> > the way to ATLAS, where I had to give up.
>
> Which gcc did you use? I used a gcc 4.3.0 with GNU binutils 2.18 and
> did not hit any trouble.
>
> > Along the way, I was
> > wondering: exactly how many of the packages are needed in order to
> > reach the sage: prompt ? Even if 'make' does not go smoothly, some
> > functionality is better than nothing I guess ... and sage as a package
> > manager for its packages would still be extremely useful even if some
> > of them don't build out of the box.
>
> This is tricky and you do not to get past the Sage library stage. Then

This is tricky and you do *have* to get past the Sage library stage.

> you need Maxima, GAP and pyprocessing and Sage should start up.
>
> > BTW, do you have building instructions written somewhere ? I am
> > willing to experiment, but I would need a starting point ...
>
> I have a bunch of rather cryptic notes which has fixes that should
> mostly go into Sage 3.0.6.alpha0 which should happen in the next 24 to
> 48 hours. My main focus in the next two to three months are the
> Solaris, native Windows and OSX 64 bit port (in order of priority :)).
> As I mentioned the 3.0.5 binary works better than any other Sage
> release on Solaris in the last 15 months and I tracked down a number
> of issues to numpy doing bad things. At the moment 41 doctests fail of
> which about 20 are trivial failures that are caused by maybe 2, 3
> bugs. So things are looking up.
>
> > Thanks for all your work in any case !
>
> No problem. The more people play with the Solaris binary the better. I
> can also offer an SSE2 Opteron build, but my access to that box will
> cease while I am on the road starting in two days until I get back.
>
> >     /vincent
>
> Cheers,
>
> Michael

Sorry for the noise again.

Cheers,

Michael

[Dr. David Kirkby]

On 14 Jul, 23:25, mabshoff <mabsh...@googlemail.com> wrote:
> Hello folks,
>
> since Sage on Solaris is more than a little tricky to build at the
> moment I packaged up a 3.0.5 build at
>

> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.5/sa...

>
> Notice that it still has some serious bugs in it (41 doctests fail),

I'm just downloaded your binary to my laptop (Sony Vaio VGN-SZ4XWN/C
Core 2 Duo 2.0 GHz, 2 GB RAM), but gnu tar thinks the file is too
corrupt.

$ gtar xfz sage-3.0.5-sse3-i86pc-SunOS_BETA.tar.gz

gzip: stdin: unexpected end of file
gtar: Unexpected EOF in archive
gtar: Unexpected EOF in archive
gtar: Error is not recoverable: exiting now


According to ls -l, the file is 139557984 bytes long. Here's the
checksum:

$ digest -v -a md5 sage-3.0.5-sse3-i86pc--SunOS_BETA.tar.gz

md5 (sage-3.0.5-sse3-i86pc-SunOS_BETA.tar.gz) =
5f206b211d29e5c49518de8982ac92bc


Since I have had half a dozen beers tonight, that might possibly be
the issues, but I doubt it. I'll try to download again.

The OS here on my laptop is Solaris Express, Community Edition, Build
93. That was released < 2 weeks ago.

I would be interested in a SPARC version. The machine I have is a
Blade 2000, 2 x 1.2 GHz, 8 GB RAM. That has Solaris 10, update 4
(August 2007).

However, more than anything I'd like to see the patches you have
integrated into a new release and some notes on the process you use to
build your tool chain. There is not so much someone can do to help
debug code from a binary.

Like Vincent, I believe there would be interest from Solaris users who
do not subscribe here, but I think it would be premature to advertise
a binary in Solaris newsgroups. Obvious places would be
comp.unix,solaris, alt.solaris.x86 and a couple of the OpenSolaris
forums. I know there have been several Mathematica discussions on the
Solaris forums.

You could actually beat Wolfram Research to a Computer Algebra System
on Solaris x86 on Intel, as Wolfram's Mathematica only runs on ADM
CPUs, not Intel ones if the OS is Solaris x86. Netiher Maple or MATLAB
run on Solaris x86.

I've managed to hack Mathematica by replacing a couple of the
libraries supplied by Wolfram Research with those supplied by Sun as
part of Sun Studio 12., The libraries from Wolfram Research need the
AMD_3DNOW instructions, but those from Sun do not. But there is no
offical support for Intel CPUs on Solaris x86 from Wolfram Research,
although it can be made to work.

> but it is self contained and as long as you have Solaris 10 and SSE3
> it should be good enough to play around with. If there is interest I
> can also provide a Sparc binary. Please provide some feedback in case
> you care about Sage on Solaris.

Sure. In fact, I would probably try it more, as I tend to use my Blade
2000 more than the laptop.

>
> I am in the process of adding more details on the known bug to
>
> http://wiki.sagemath.org/solaris

Some more information would be useful, as I would like to try to build
from source, but I'm not over keen on trying to fix problems you are
aware of, and know how to solve.

It's great to see a Solaris port progress. At a later date, you could
try getting Sage on the OpenSolaris DVD images. Sum might well do
that.

Dave

[Dr. David Kirkby]

On 14 Jul, 23:25, mabshoff <mabsh...@googlemail.com> wrote:

> Hello folks,
>
> since Sage on Solaris is more than a little tricky to build at the
> moment I packaged up a 3.0.5 build at
>

> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.5/sa...

>
> Notice that it still has some serious bugs in it (41 doctests fail),

> but it is self contained and as long as you have Solaris 10 and SSE3
> it should be good enough to play around with. If there is interest I
> can also provide a Sparc binary. Please provide some feedback in case
> you care about Sage on Solaris.

Sure. In fact, I would probably try it more, as I tend to use my Blade
2000 more than the laptop.

>

> I am in the process of adding more details on the known bug to
>
> http://wiki.sagemath.org/solaris

[mabshoff]

On Jul 15, 3:18 pm, "Dr. David Kirkby" <david.kir...@onetel.net>
wrote:

> On 14 Jul, 23:25, mabshoff <mabsh...@googlemail.com> wrote:
>
> > Hello folks,

Hi,

> > since Sage on Solaris is more than a little tricky to build at the
> > moment I packaged up a 3.0.5 build at
>
> >    http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.5/sa...
>
> > Notice that it still has some serious bugs in it (41 doctests fail),
>
> I'm just downloaded your binary to my laptop (Sony Vaio VGN-SZ4XWN/C
> Core 2 Duo 2.0 GHz, 2 GB  RAM), but gnu tar thinks the file is too
> corrupt.
>
> $  gtar xfz sage-3.0.5-sse3-i86pc-SunOS_BETA.tar.gz
>
> gzip: stdin: unexpected end of file
> gtar: Unexpected EOF in archive
> gtar: Unexpected EOF in archive
> gtar: Error is not recoverable: exiting now
>
> According to ls -l, the file is 139557984 bytes long. Here's the
> checksum:
>
> $  digest -v -a md5  sage-3.0.5-sse3-i86pc--SunOS_BETA.tar.gz
>
> md5 (sage-3.0.5-sse3-i86pc-SunOS_BETA.tar.gz) =
> 5f206b211d29e5c49518de8982ac92bc

Whatever you downloaded is truncated:

-rw-r--r-- 1 mabshoff 1090 267772545 2008-07-14 15:17 sage-3.0.5-sse3-
i86pc-SunOS_BETA.tar.gz
-rw-r--r-- 1 mabshoff 1090 74 2008-07-14 15:18 sage-3.0.5-sse3-
i86pc-SunOS_BETA.tar.gz.md5sum

mabshoff@sage:~/release-cycles-3.0.5$ cat sage-3.0.5-sse3-i86pc-
SunOS_BETA.tar.gz.md5sum
5ef343edc475f5b2ee0978d60ba3c566 sage-3.0.5-sse3-i86pc-
SunOS_BETA.tar.gz

> Since I have had half a dozen beers tonight, that might possibly be
> the issues, but I doubt it. I'll try to download again.

"Mothers against drunk downloading" anyone? ;)

> The OS here on my laptop is Solaris Express, Community Edition, Build
> 93. That was released < 2 weeks ago.
>
> I would be interested in a SPARC version. The machine I have is a
> Blade 2000, 2 x 1.2 GHz, 8 GB RAM. That has Solaris 10, update 4
> (August 2007).

That should be doable, the problem right now is that clisp on Sparc is
FUBAR and Maxima will not even build with it. I used SBCL 0.9.11 on
Sparc and doctesting Sage crashes Maxima 35+ times with it. And of the
sbcl releases past 1.0.0 do not seem to build on Sparc (I tried,
something about signal masks, I could care less), so Sage on Sparc
will have to wait until we do the ecls switch to be any useful. I had
some clisp 2.39 from Blastwave running on Solaris 9 at some point, but
I had to do dreadful things with some libs to get it to even run.

> However, more than anything I'd like to see the patches you have
> integrated into a new release and some notes on the process you use to
> build your tool chain. There is not so much someone can do to help
> debug code from a binary.

Sure, but the people debugging this do have access to the build
machine and the problems right now are known, i.e. multi-modular
matrix matrix multiply has a bug, etc. The numpy we ship also
segfaults its test suite and is the cause for a number of problems,
but I am on top of them.

> Like Vincent, I believe there would be interest from Solaris users who
> do not subscribe here, but I  think it would be premature to advertise
> a binary in Solaris newsgroups. Obvious places would be
> comp.unix,solaris, alt.solaris.x86 and a couple of the OpenSolaris
> forums. I know there have been several Mathematica discussions on the
> Solaris forums.

Sure, this is way too early. I would want to do that once Sage builds
actually pass doctest at least on the Solaris boxen I have access to,
not any time before that.

> You could actually beat Wolfram Research to a Computer Algebra System
> on Solaris x86 on Intel, as Wolfram's Mathematica only runs on ADM
> CPUs, not Intel ones if the OS is Solaris x86. Netiher Maple or MATLAB
> run on Solaris x86.

Yeah, that is strangely odd. Any reason why they would do so? 3DNOW
cannot be the reason since MMA and Maple do run of plenty of Intel
CPUs with those other OSes ;)

> I've managed to hack Mathematica by replacing a couple of the
> libraries supplied by Wolfram Research with those supplied by Sun as
> part of Sun Studio 12., The libraries from Wolfram Research need the
> AMD_3DNOW instructions, but those from Sun do not. But there is no
> offical support for Intel CPUs on Solaris x86 from Wolfram Research,
> although it can be made to work.
>
> > but it is self contained and as long as you have Solaris 10 and SSE3
> > it should be good enough to play around with. If there is interest I
> > can also provide a Sparc binary. Please provide some feedback in case
> > you care about Sage on Solaris.
>
> Sure. In fact, I would probably try it more, as I tend to use my Blade
> 2000 more than the laptop.

Yeah.

> > I am in the process of adding more details on the known bug to
>
> >    http://wiki.sagemath.org/solaris
>
> Some more information would be useful, as I would like to try to build
> from source, but I'm not over keen on trying to fix problems you are
> aware of, and know how to solve.

Sure, I got sidetracked doing other things the last day, but now I am
back on the case again.

> It's great to see a Solaris port progress. At a later date, you could
> try getting Sage on the OpenSolaris DVD images. Sum might well do
> that.

Some Sun fellow contacted the group a while back, but after contacting
him off list we never heard back. Maybe it is time to ping him again.

> Dave

Cheers,

Michael

[Brandon...@gmail.com]

Nice work!

Haven't been able to try it yet, the download link seems to be dead
for me as well, though the server is alive according to ping.

On Jul 15, 6:48 pm, mabshoff <mabsh...@googlemail.com> wrote:
> On Jul 15, 3:18 pm, "Dr. David Kirkby" <david.kir...@onetel.net>
> wrote:
>
> > On 14 Jul, 23:25, mabshoff <mabsh...@googlemail.com> wrote:
>
> > > Hello folks,
>
> Hi,
>
>
>

> > > since Sage onSolarisis more than a little tricky to build at the

> > The OS here on my laptop isSolarisExpress, Community Edition, Build

> > 93. That was released < 2 weeks ago.
>
> > I would be interested in a SPARC version. The machine I have is a

> > Blade 2000, 2 x 1.2 GHz, 8 GB RAM. That hasSolaris10, update 4

> > (August 2007).
>
> That should be doable, the problem right now is that clisp on Sparc is
> FUBAR and Maxima will not even build with it. I used SBCL 0.9.11 on
> Sparc and doctesting Sage crashes Maxima 35+ times with it. And of the
> sbcl releases past 1.0.0 do not seem to build on Sparc (I tried,
> something about signal masks, I could care less), so Sage on Sparc
> will have to wait until we do the ecls switch to be any useful. I had

> some clisp 2.39 from Blastwave running onSolaris9 at some point, but

> I had to do dreadful things with some libs to get it to even run.
>
> > However, more than anything I'd like to see the patches you have
> > integrated into a new release and some notes on the process you use to
> > build your tool chain. There is not so much someone can do to help
> > debug code from a binary.
>
> Sure, but the people debugging this do have access to the build
> machine and the problems right now are known, i.e. multi-modular
> matrix matrix multiply has a bug, etc. The numpy we ship also
> segfaults its test suite and is the cause for a number of problems,
> but I am on top of them.
>

> > Like Vincent, I believe there would be interest fromSolarisusers who

> > do not subscribe here, but I think it would be premature to advertise

> > a binary inSolarisnewsgroups. Obvious places would be

> > comp.unix,solaris, alt.solaris.x86 and a couple of the OpenSolaris
> > forums. I know there have been several Mathematica discussions on the
> >Solarisforums.
>
> Sure, this is way too early. I would want to do that once Sage builds

> actually pass doctest at least on theSolarisboxen I have access to,

> not any time before that.
>
> > You could actually beat Wolfram Research to a Computer Algebra System

> > onSolarisx86 on Intel, as Wolfram's Mathematica only runs on ADM
> > CPUs, not Intel ones if the OS isSolarisx86. Netiher Maple or MATLAB

> > run onSolarisx86.
>
> Yeah, that is strangely odd. Any reason why they would do so? 3DNOW
> cannot be the reason since MMA and Maple do run of plenty of Intel
> CPUs with those other OSes ;)
>
> > I've managed to hack Mathematica by replacing a couple of the
> > libraries supplied by Wolfram Research with those supplied by Sun as
> > part of Sun Studio 12., The libraries from Wolfram Research need the
> > AMD_3DNOW instructions, but those from Sun do not. But there is no

> > offical support for Intel CPUs onSolarisx86 from Wolfram Research,

> > although it can be made to work.
>

> > > but it is self contained and as long as you haveSolaris10 and SSE3

> > > it should be good enough to play around with. If there is interest I
> > > can also provide a Sparc binary. Please provide some feedback in case
> > > you care about Sage onSolaris.
>
> > Sure. In fact, I would probably try it more, as I tend to use my Blade
> > 2000 more than the laptop.
>
> Yeah.
>
> > > I am in the process of adding more details on the known bug to
>
> > > http://wiki.sagemath.org/solaris
>
> > Some more information would be useful, as I would like to try to build
> > from source, but I'm not over keen on trying to fix problems you are
> > aware of, and know how to solve.
>
> Sure, I got sidetracked doing other things the last day, but now I am
> back on the case again.
>

> > It's great to see aSolarisport progress. At a later date, you could

[mabshoff]

On Jul 15, 11:18 pm, "Brandon.Bar...@gmail.com"

<Brandon.Bar...@gmail.com> wrote:
> Nice work!
>
> Haven't been able to try it yet, the download link seems to be dead
> for me as well, though the server is alive according to ping.

Odd, I just checked and

http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.5/sage-3.0.5-sse3-i86pc-SunOS_BETA.tar.gz

is alive and well for me from Europe.

I also started putting info about this build, its doctest failures and
so on in the wiki at

http://wiki.sagemath.org/solaris/solaris/sage-3.0.5

The build issues are not up yet since I am cleaning them up and doing
spkgs and patches for 3.0.6.alpha0.

Cheers,

Michael

[Dr. David Kirkby]

On 15 Jul, 23:48, mabshoff <mabsh...@googlemail.com> wrote:
> On Jul 15, 3:18 pm, "Dr. David Kirkby" <david.kir...@onetel.net>

> > According to ls -l, the file is 139557984 bytes long. Here's the
> > checksum:
>
> > $ digest -v -a md5 sage-3.0.5-sse3-i86pc--SunOS_BETA.tar.gz
>
> > md5 (sage-3.0.5-sse3-i86pc-SunOS_BETA.tar.gz) =
> > 5f206b211d29e5c49518de8982ac92bc
>
> Whatever you downloaded is truncated:

Yes, I see that. I've got it going now, so it can be downloaded from
Europe OK, despite the mention of it now (In case you don't know, I'm
in the UK).

$ ./sage
----------------------------------------------------------------------
| SAGE Version 3.0.5, Release Date: 2008-07-11 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
The SAGE install tree may have moved.
Regenerating Python.pyo and .pyc files that hardcode the install PATH
(please wait at most a few minutes)...
Please do not interrupt this.
Setting permissions of DOT_SAGE directory so only you can read and
write it.

sage: notebook()
The notebook files are stored in: /export/home/drkirkby/.sage//
sage_notebook

There does not appear to be anything acting as a server on port 8000,
but I know you said there were bugs on Solaris, so I guess the GUI is
one of them.

> > Since I have had half a dozen beers tonight, that might possibly be
> > the issues, but I doubt it. I'll try to download again.
>
> "Mothers against drunk downloading" anyone? ;)

Yeah, it needs it.

> > I would be interested in a SPARC version. The machine I have is a
> > Blade 2000, 2 x 1.2 GHz, 8 GB RAM. That has Solaris 10, update 4
> > (August 2007).
>
> That should be doable, the problem right now is that clisp on Sparc is

OK, well let us know when the SPARC looks more hopeful.

> > Like Vincent, I believe there would be interest from Solaris users who
> > do not subscribe here, but I think it would be premature to advertise
> > a binary in Solaris newsgroups. Obvious places would be
> > comp.unix,solaris, alt.solaris.x86 and a couple of the OpenSolaris
> > forums. I know there have been several Mathematica discussions on the
> > Solaris forums.
>
> Sure, this is way too early. I would want to do that once Sage builds
> actually pass doctest at least on the Solaris boxen I have access to,
> not any time before that.

Though you should weigh that against the fact that there are some real
Sun experts on these places, that are good at debugging Solaris
problems. It seems to me that might be what is needed now. Clearly you
don't want mathmaticians whose universities give them Sun boxes to
debug it, but Sun employees, or other Sun experts who have some
interest in maths software might be persuaded to look at the
problems.

Casper Dik for example, who works for Sun and hangs out on
comp.unix.solaris a lot, sorted out a Mathematica issue on Solaris
that Wolfram Research could not. Mathematica started using tons of CPU
time on Solaris 10 on some machines, but not on others, despite it
worked on Solaris 9 fine. Basically Sun had changed a minimum timeout
value from 1 ms to 1 us in Solaris 10, and WRI were using the minimum
for something. On slower machines a particular task would not complete
in 1 us, so would time out and be done again. The result was
Mathematica would peg the CPU usage after computing something as
simple as 1+1. Casper wrote me a shared library, which used the old
timeout. The library was then pre-loaded with LD_PRELOAD_64, so
Mathematica see that code, rather than the normal Solaris version.

It was with the help from someone on comp.unix.solaris that a solution
to the Mathematica on Solaris x86 with an Intel CPU was found.

Then I can think of the problem with GPIB drivers for the National
Instruments GPIB board, which would not work in Solaris 10, despite
working on Solaris 2.6 to 9. Casper Dik sorted that out, despite
National Instruments being totally stuck. It turned out National
Instruments had used the name 'ib' for the GPIB driver. Then in
Solaris 10, Sun used a name 'ib' for the Infiniband driver. Needless
to say, two drivers of the same name did not work. Casper suggested I
removed Infiniband support since I had no need for it, then the GPIB
board worked.

I know a few regular users of comp.unix.solaris that use Mathematica
and/or MATLAB on Solaris. There are also a few people keen for
Mathworks to port MATLAB to Solaris x86 (it runs on SPARC).

> > You could actually beat Wolfram Research to a Computer Algebra System
> > on Solaris x86 on Intel, as Wolfram's Mathematica only runs on ADM
> > CPUs, not Intel ones if the OS is Solaris x86. Netiher Maple or MATLAB
> > run on Solaris x86.
>
> Yeah, that is strangely odd. Any reason why they would do so? 3DNOW
> cannot be the reason since MMA and Maple do run of plenty of Intel
> CPUs with those other OSes ;)

The error message says its a lack of hardware support for AMD_3DNOW:

ld.so.1: MathKernel: fatal:
/usr/local/Wolfram/Mathematica/6.0/SystemFiles/Libraries/Solaris-
x86-64/libsunperf.so.1:
hardware capability unsupported: 0x100 [ AMD_3DNow ]

Running 'file' on the library indicates its a 64-bit library neededing
AMD_3DNOW.

Running

$ /usr/bin/isalist
amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86

on my laptop shows the instructions my CPU supports - as you can see
it lacks AMD_3DNOW. If you was to run that command on a modern AMD
CPU, it should reports AMD_3DNOW in that list. (I can't be bothered to
fire up my AMD Solaris x86 box to find out, but I believe that is
so).

Hence I'm pretty sure the Mathematica issue is related to AMD_3DNOW.
That information was passed to Wolfram back last year, but so far they
have not resolved the issue. All they need do is to ship updated
libraries!!

> Sure, I got sidetracked doing other things the last day, but now I am
> back on the case again.

Good.

> > It's great to see a Solaris port progress. At a later date, you could
> > try getting Sage on the OpenSolaris DVD images. Sum might well do
> > that.
>
> Some Sun fellow contacted the group a while back, but after contacting
> him off list we never heard back. Maybe it is time to ping him again.

There are several "live DVD" versions of OpenSolaris around. Pretty
much anyone can produce one of those, so anyone producing one could be
asked to add Sage once you have it fully debugged. Not now of course.

More useful, from an advertising point of view would be to get Sun to
add Sage to the Solaris Express DVD. There is noting remotely similar
on there now. People using Solaris tend to be technically savvy, so it
might be an application that would be welcome. However, I do know that
Sun have spent a lot of time working with Wolfram Research on
Mathematica. At one point, the Mathematica record was held on a Sun.
So there might be some reluctance in Sun to include free software in
direct competition to that they are paid to work on. That said, a lot
of Sun employees would not care too hoots about that, so it might
never be considered.

BTW, I think it would be useful if Sage reported that the Solaris
build was in an early stage of development, and so is not considered
stable. It could prevent anyone getting the wrong impression if they
happen to find the binary somehow.

Something like the following should work on any Unix/Linux system,
although I've tested only on Solaris x86 and SPARC.


#include <sys/utsname.h>
#include <stdio.h>
#include <string.h>

int main() {
struct utsname machine_data;
uname(&machine_data);
if(strcmp("SunOS",machine_data.sysname) == 0) {
fprintf(stderr,"WARNING - The Solaris port of Sage is an an
early stage, and has several severe bugs.\n");
}
}


Cheers,

Dave

[mabshoff]

On Jul 16, 1:33 am, "Dr. David Kirkby" <david.kir...@onetel.net>
wrote:

> On 15 Jul, 23:48, mabshoff <mabsh...@googlemail.com> wrote:
>
> > On Jul 15, 3:18 pm, "Dr. David Kirkby" <david.kir...@onetel.net>
> > > According to ls -l, the file is 139557984 bytes long. Here's the
> > > checksum:

Hi David,

> > > $  digest -v -a md5  sage-3.0.5-sse3-i86pc--SunOS_BETA.tar.gz
>
> > > md5 (sage-3.0.5-sse3-i86pc-SunOS_BETA.tar.gz) =
> > > 5f206b211d29e5c49518de8982ac92bc
>
> > Whatever you downloaded is truncated:
>
> Yes, I see that. I've got it going now, so it can be downloaded from
> Europe OK, despite the mention of it now (In case you don't know, I'm
> in the UK).
>
> $  ./sage
> ----------------------------------------------------------------------
> | SAGE Version 3.0.5, Release Date: 2008-07-11                       |
> | Type notebook() for the GUI, and license() for information.        |
> ----------------------------------------------------------------------
> The SAGE install tree may have moved.
> Regenerating Python.pyo and .pyc files that hardcode the install PATH
> (please wait at most a few minutes)...
> Please do not interrupt this.
> Setting permissions of DOT_SAGE directory so only you can read and
> write it.

Ok, so far so good.

> sage: notebook()
> The notebook files are stored in: /export/home/drkirkby/.sage//
> sage_notebook
>
> There does not appear to be anything acting as a server on port 8000,
> but I know you said there were bugs on Solaris, so I guess the GUI is
> one of them.

Yes, it is a known issue to me. The notebook just sits there waiting
for entropy. I suspect this has to do with RAND_MAX on Solaris being
2^15-1 instead of 2^31-1. We had a similar bug in the randgen
framework which caused ZZ.random_element() to take between 3 and 8
seconds of CPU time to return 0 with probablity 1. On sage.math things
are a little quicker:

sage: %timeit ZZ.random_element()
1000000 loops, best of 3: 519 ns per loop
sage:

So those order of magnitudes are screwing us at the moment.

> > > Since I have had half a dozen beers tonight, that might possibly be
> > > the issues, but I doubt it. I'll try to download again.
>
> > "Mothers against drunk downloading" anyone? ;)
>
> Yeah, it needs it.

:)

> > > I would be interested in a SPARC version. The machine I have is a
> > > Blade 2000, 2 x 1.2 GHz, 8 GB RAM. That has Solaris 10, update 4
> > > (August 2007).
>
> > That should be doable, the problem right now is that clisp on Sparc is
>
> OK, well let us know when the SPARC looks more hopeful.

The ecls switch is very high up on my priority list since it is always
very needed for Sage on native Windows.

> > > Like Vincent, I believe there would be interest from Solaris users who
> > > do not subscribe here, but I  think it would be premature to advertise
> > > a binary in Solaris newsgroups. Obvious places would be
> > > comp.unix,solaris, alt.solaris.x86 and a couple of the OpenSolaris
> > > forums. I know there have been several Mathematica discussions on the
> > > Solaris forums.
>
> > Sure, this is way too early. I would want to do that once Sage builds
> > actually pass doctest at least on the Solaris boxen I have access to,
> > not any time before that.
>
> Though you should weigh that against the fact that there are some real
> Sun experts on these places, that are good at debugging Solaris
> problems. It seems to me that might be what is needed now. Clearly you
> don't want mathmaticians whose universities give them Sun boxes to
> debug it, but Sun employees, or other Sun experts who have some
> interest in maths software might be persuaded to look at the
> problems.

I have no such problem letting anyone debug Sage on Solaris, but the
time has not come yet since right now I need to fix some build issue
and about three or four known bugs before Sage becomes usable to
debug. The problems are:

* multimodular matrix matrix multiply broken
* numpy 1.0.4 borken, numpy 1.1.0 fixes the issue
* pexpect Singular hangs
* factory from Singular segfaults

All of the above are things that an outsider is unlikely to solve
quickly and I have told the right people off-list about the problem.
There are certainly issues that I would happy to have solved:

* sympow returns wrong results on Sparc
* sympow does not build with gcc on x86 or x86-64, build with cc it
goes into infinite loops
* cvxopt does not build with gcc on x86, x86-64 or sparc due to
complex.h issues

If you get anybody willing to fix those issues let me know and I can
provide detailed problem reports. All of the above are independent of
Sage.

> Casper Dik for example, who works for Sun and hangs out on
> comp.unix.solaris a lot, sorted out a Mathematica issue on Solaris
> that Wolfram Research could not. Mathematica started using tons of CPU
> time on Solaris 10 on some machines, but not on others, despite it
> worked on Solaris 9 fine. Basically Sun had changed a minimum timeout
> value from 1 ms to 1 us in Solaris 10, and WRI were using the minimum
> for something. On slower machines a particular task would not complete
> in 1 us, so would time out and be done again. The result was
> Mathematica would peg the CPU usage after computing something as
> simple as 1+1. Casper wrote me a shared library, which used the old
> timeout. The library was then pre-loaded with LD_PRELOAD_64, so
> Mathematica see that code, rather than the normal Solaris version.
>
> It was with the help from someone on comp.unix.solaris that a solution
> to the Mathematica on Solaris x86 with an Intel CPU was found.
>
> Then I can think of the problem with GPIB drivers for the National
> Instruments GPIB board, which would not work in Solaris 10, despite
> working on Solaris 2.6 to 9. Casper Dik sorted that out, despite
> National Instruments being totally stuck. It turned out National
> Instruments had used the name 'ib' for the GPIB driver. Then in
> Solaris 10, Sun used a name 'ib' for the Infiniband driver. Needless
> to say, two drivers of the same name did not work. Casper suggested I
> removed Infiniband support since I had no need for it, then the GPIB
> board worked.

I am sure there are a lot of competent people around at Sun and in the
news groups, but getting them up to speed on Sage will take longer
than for us to fix the problems. Once the toolchain issues are sorted
out and the above four bugs are fixed I am more than happy to throw a
development version of Sage out there to the Solaris community.

> I know a few regular users of comp.unix.solaris that use Mathematica
> and/or MATLAB on Solaris. There are also a few people keen for
> Mathworks to port MATLAB to Solaris x86 (it runs on SPARC).

Ok.

> > > You could actually beat Wolfram Research to a Computer Algebra System
> > > on Solaris x86 on Intel, as Wolfram's Mathematica only runs on ADM
> > > CPUs, not Intel ones if the OS is Solaris x86. Netiher Maple or MATLAB
> > > run on Solaris x86.
>
> > Yeah, that is strangely odd. Any reason why they would do so? 3DNOW
> > cannot be the reason since MMA and Maple do run of plenty of Intel
> > CPUs with those other OSes ;)
>
> The error message says its a lack of hardware support for AMD_3DNOW:
>
> ld.so.1: MathKernel: fatal:
> /usr/local/Wolfram/Mathematica/6.0/SystemFiles/Libraries/Solaris-
> x86-64/libsunperf.so.1:
> hardware capability unsupported: 0x100  [ AMD_3DNow ]
>
> Running 'file' on the library indicates its a 64-bit library neededing
> AMD_3DNOW.

This is pathetic to say the least. I am curious now that Sun also
ships Intel boxen if they will fix it.

Yeah, I would be glad if this worked out. But packaging for Solaris is
on the to do list, but will probably take a while.

> BTW, I think it would be useful if Sage reported that the Solaris
> build was in an early stage of development, and so is not considered
> stable. It could prevent anyone getting the wrong impression if they
> happen to find the binary somehow.
>
> Something like the following should work on any Unix/Linux system,
> although I've tested only on Solaris x86 and SPARC.
>
> #include <sys/utsname.h>
> #include <stdio.h>
> #include <string.h>
>
> int main() {
>    struct utsname machine_data;
>    uname(&machine_data);
>    if(strcmp("SunOS",machine_data.sysname) == 0) {
>       fprintf(stderr,"WARNING - The Solaris port of Sage is an an
> early stage, and has several severe bugs.\n");
>    }
>
> }

It is easier to stick it into the banner, I have some code to do that.

> Cheers,
>
> Dave

Thanks for your feedback.

Cheers,

Michael

[Brandon...@gmail.com]

Speaking of Matlab, I was able to get version r2008a (most recent
version) working in a linux-2.6 zone using the CentOS 5 distribution.
I then installed RPyC 3.00 RC1 ( http://rpyc.wikispaces.com/ ) in both
the lx zone's copy of sage and in the native solaris sage
installation. I started up the RPyC server (which could be turned
into a daemon) in the lx zone:

sage: load rpyc_classic_server.sage # this is one of the server
scripts that came with RPyC, renamed to a ".sage" file

In the solaris client:
sage: import rpyc
c = rpyc.classic.connect("192.168.5.10") # 192.168.5.10 is the ip of
the linux zone
sage: c.modules.__main__.matlab('3+3')
6

Though I suppose this has some minimal use on its own as being a way
to call proprietary software not available natively on solaris while
still using native applications from sage (OpenGL visualization comes
to mind), I think a more common benefit would be in having a solaris
zone that is used to house a sage notebook server while not having to
sacrifice the ability to call proprietary software (from a lx zone).

Once I move in to my new apartment and have access to my sever again I
will try it out ... it doesn't look like it will be long before the
solaris port is adequate ;)

> > but I know you said there were bugs onSolaris, so I guess the GUI is

> > one of them.
>
> Yes, it is a known issue to me. The notebook just sits there waiting
> for entropy. I suspect this has to do with RAND_MAX onSolarisbeing
> 2^15-1 instead of 2^31-1. We had a similar bug in the randgen
> framework which caused ZZ.random_element() to take between 3 and 8
> seconds of CPU time to return 0 with probablity 1. On sage.math things
> are a little quicker:
>
> sage: %timeit ZZ.random_element()
> 1000000 loops, best of 3: 519 ns per loop
> sage:
>
> So those order of magnitudes are screwing us at the moment.
>
> > > > Since I have had half a dozen beers tonight, that might possibly be
> > > > the issues, but I doubt it. I'll try to download again.
>
> > > "Mothers against drunk downloading" anyone? ;)
>
> > Yeah, it needs it.
>
> :)
>
> > > > I would be interested in a SPARC version. The machine I have is a

> > > > Blade 2000, 2 x 1.2 GHz, 8 GB RAM. That hasSolaris10, update 4

> > > > (August 2007).
>
> > > That should be doable, the problem right now is that clisp on Sparc is
>
> > OK, well let us know when the SPARC looks more hopeful.
>
> The ecls switch is very high up on my priority list since it is always
> very needed for Sage on native Windows.
>
>
>

> > > > Like Vincent, I believe there would be interest fromSolarisusers who

> > > > do not subscribe here, but I  think it would be premature to advertise

> > > > a binary inSolarisnewsgroups. Obvious places would be

> > > > comp.unix,solaris, alt.solaris.x86 and a couple of the OpenSolaris
> > > > forums. I know there have been several Mathematica discussions on the
> > > >Solarisforums.
>
> > > Sure, this is way too early. I would want to do that once Sage builds

> > > actually pass doctest at least on theSolarisboxen I have access to,

> > > not any time before that.
>
> > Though you should weigh that against the fact that there are some real
> > Sun experts on these places, that are good at debuggingSolaris
> > problems. It seems to me that might be what is needed now. Clearly you
> > don't want mathmaticians whose universities give them Sun boxes to
> > debug it, but Sun employees, or other Sun experts who have some
> > interest in maths software might be persuaded to look at the
> > problems.
>

> I have no such problem letting anyone debug Sage onSolaris, but the

> time has not come yet since right now I need to fix some build issue
> and about three or four known bugs before Sage becomes usable to
> debug. The problems are:
>
>  * multimodular matrix matrix multiply broken
>  * numpy 1.0.4 borken, numpy 1.1.0 fixes the issue
>  * pexpect Singular hangs
>  * factory from Singular segfaults
>
> All of the above are things that an outsider is unlikely to solve
> quickly and I have told the right people off-list about the problem.
> There are certainly issues that I would happy to have solved:
>
>  * sympow returns wrong results on Sparc
>  * sympow does not build with gcc on x86 or x86-64, build with cc it
> goes into infinite loops
>  * cvxopt does not build with gcc on x86, x86-64 or sparc due to
> complex.h issues
>
> If you get anybody willing to fix those issues let me know and I can
> provide detailed problem reports. All of the above are independent of
> Sage.
>
>
>
> > Casper Dik for example, who works for Sun and hangs out on

> > comp.unix.solarisa lot, sorted out a Mathematica issue onSolaris

> > that Wolfram Research could not. Mathematica started using tons of CPU

> > time onSolaris10 on some machines, but not on others, despite it
> > worked onSolaris9 fine. Basically Sun had changed a minimum timeout
> > value from 1 ms to 1 us inSolaris10, and WRI were using the minimum

> > for something. On slower machines a particular task would not complete
> > in 1 us, so would time out and be done again. The result was
> > Mathematica would peg the CPU usage after computing something as
> > simple as 1+1. Casper wrote me a shared library, which used the old
> > timeout. The library was then pre-loaded with LD_PRELOAD_64, so
> > Mathematica see that code, rather than the normalSolarisversion.
>

> > It was with the help from someone on comp.unix.solaristhat a solution
> > to the Mathematica onSolarisx86 with an Intel CPU was found.

>
> > Then I can think of the problem with GPIB drivers for the National
> > Instruments GPIB board, which would not work inSolaris10, despite

> > working onSolaris2.6 to 9. Casper Dik sorted that out, despite

> > National Instruments being totally stuck. It turned out National
> > Instruments had used the name 'ib' for the GPIB driver. Then in

> >Solaris10, Sun used a name 'ib' for the Infiniband driver. Needless

> > to say, two drivers of the same name did not work. Casper suggested I
> > removed Infiniband support since I had no need for it, then the GPIB
> > board worked.
>
> I am sure there are a lot of competent people around at Sun and in the
> news groups, but getting them up to speed on Sage will take longer
> than for us to fix the problems. Once the toolchain issues are sorted
> out and the above four bugs are fixed I am more than happy to throw a
> development version of Sage out there to theSolariscommunity.
>
> > I know a few regular users of comp.unix.solaristhat use Mathematica

> > and/or MATLAB onSolaris. There are also a few people keen for
> > Mathworks to port MATLAB toSolarisx86 (it runs on SPARC).

>
> Ok.
>
>
>
> > > > You could actually beat Wolfram Research to a Computer Algebra System

> > > > onSolarisx86 on Intel, as Wolfram's Mathematica only runs on ADM
> > > > CPUs, not Intel ones if the OS isSolarisx86. Netiher Maple or MATLAB

> > > > run onSolarisx86.
>
> > > Yeah, that is strangely odd. Any reason why they would do so? 3DNOW
> > > cannot be the reason since MMA and Maple do run of plenty of Intel
> > > CPUs with those other OSes ;)
>
> > The error message says its a lack of hardware support for AMD_3DNOW:
>
> > ld.so.1: MathKernel: fatal:
> > /usr/local/Wolfram/Mathematica/6.0/SystemFiles/Libraries/Solaris-
> > x86-64/libsunperf.so.1:
> > hardware capability unsupported: 0x100  [ AMD_3DNow ]
>
> > Running 'file' on the library indicates its a 64-bit library neededing
> > AMD_3DNOW.
>
> This is pathetic to say the least. I am curious now that Sun also
> ships Intel boxen if they will fix it.
>
>
>
> > Running
>
> > $  /usr/bin/isalist
> > amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86
>
> > on my laptop shows the instructions my CPU supports - as you can see
> > it lacks AMD_3DNOW. If you was to run that command on a modern AMD
> > CPU, it should reports AMD_3DNOW in that list. (I can't be bothered to

> > fire up my AMDSolarisx86 box to find out, but I believe that is

> > so).
>
> > Hence I'm pretty sure the Mathematica issue is related to AMD_3DNOW.
> > That information was passed to Wolfram back last year, but so far they
> > have not resolved the issue. All they need do is to ship updated
> > libraries!!
>
> > > Sure, I got sidetracked doing other things the last day, but now I am
> > > back on the case again.
>
> > Good.
>

> > > > It's great to see aSolarisport progress. At a later date, you could

> > > > try getting Sage on the OpenSolaris DVD images. Sum might well do
> > > > that.
>
> > > Some Sun fellow contacted the group a while back, but after contacting
> > > him off list we never heard back. Maybe it is time to ping him again.
>
> > There are several "live DVD" versions of OpenSolaris around. Pretty
> > much anyone can produce one of those, so anyone producing one could be
> > asked to add Sage once you have it fully debugged. Not now of course.
>
> > More useful, from an advertising point of view would be to get Sun to

> > add Sage to theSolarisExpress DVD. There is noting remotely similar
> > on there now. People usingSolaristend to be technically savvy, so it

> > might be an application that would be welcome. However, I do know that
> > Sun have spent a lot of time working with Wolfram Research on
> > Mathematica. At one point, the Mathematica record was held on a Sun.
> > So there might be some reluctance in Sun to include free software in
> > direct competition to that they are paid to work on. That said, a lot
> > of Sun employees would not care too hoots about that, so it might
> > never be considered.
>
> Yeah, I would be glad if this worked out. But packaging forSolarisis
> on the to do list, but will probably take a while.
>
> > BTW, I think it would be useful if Sage reported that theSolaris
> > build was in an early stage of development, and so is not
>

> ...
>
> read more »

[Dr. David Kirkby]

On Jul 16, 4:17 pm, mabshoff <mabsh...@googlemail.com> wrote:

> > The error message says its a lack of hardware support for AMD_3DNOW:
>
> > ld.so.1: MathKernel: fatal:
> > /usr/local/Wolfram/Mathematica/6.0/SystemFiles/Libraries/Solaris-
> > x86-64/libsunperf.so.1:
> > hardware capability unsupported: 0x100  [ AMD_3DNow ]
>
> > Running 'file' on the library indicates its a 64-bit library neededing
> > AMD_3DNOW.
>
> This is pathetic to say the least. I am curious now that Sun also
> ships Intel boxen if they will fix it.

I would agree, it is pathetic.

I would think it pathetic if anyone produced a binary which run on
Intel but not AMD. But the reverse seems even more pathetic, given
Intel is more popular than AMD.

Then when you consider a few posts on a newsgroup resulted in a
solution many months ago, which was passed to Wolfram, and you must
think it even more crazy.

You would think Sun would be keen to see the x86 version which runs on
Intel. The strange thing is, Sun have run Mathematica on their
machines under Linux.

Currently neither Matlab or Maple run on Solaris x86 and Mathematica
only if there is an AMD CPU. Sage could score big time here.

I get the feeling that Wolfram do not have many staff devoted to
slightly less popular platforms like Solaris and HP-UX. Any time I
have seen Wolfram employees they have used Windows. I suspect they
would benifit from telling 20% of their staff to use it on Solaris and
so find the Solaris bugs a bit quicker. There seems to be some quite
obvious ones they miss.

dave

[Brandon...@gmail.com]

Actually this doesn't work perfectly (yet):

sage: matlab = c.modules.__main__.matlab
sage: my_vector1 = matlab('[1,5,7]')
sage: my_vector2 = matlab('[1;5;7]')
sage: my_vector1 * my_vector2
??? Undefined function or variable 'sage6'.
sage: my_vector1
1 5 7
sage: my_vector1 * my_vector2
??? Undefined function or variable 'sage7'.

It looks like the solaris sage (client) is getting confused and trying
to perform the matlab operation locally. Any ideas on how to get
around this?


On Jul 22, 1:17 pm, "Brandon.Bar...@gmail.com"

<Brandon.Bar...@gmail.com> wrote:
> Speaking of Matlab, I was able to get version r2008a (most recent
> version) working in a linux-2.6 zone using the CentOS 5 distribution.

> I then installed RPyC 3.00 RC1 (http://rpyc.wikispaces.com/) in both

> ...
>
> read more »

[mabshoff]

On Jul 22, 10:17 am, "Brandon.Bar...@gmail.com"
<Brandon.Bar...@gmail.com> wrote:

Hi Brandon

> Speaking of Matlab, I was able to get version r2008a (most recent
> version) working in a linux-2.6 zone using the CentOS 5 distribution.
> I then installed RPyC 3.00 RC1 (http://rpyc.wikispaces.com/)

Interesting, I had never heard of RPyC, but it will likely be of some
interest to some of the people around here.

> in both
> the lx zone's copy of sage and in the native solaris sage
> installation.  I started up the RPyC server (which could be turned
> into a daemon) in the lx zone:
>
> sage: load rpyc_classic_server.sage   # this is one of the server
> scripts that came with RPyC, renamed to a ".sage" file
>
> In the solaris client:
> sage: import rpyc
> c = rpyc.classic.connect("192.168.5.10") # 192.168.5.10 is the ip of
> the linux zone
> sage: c.modules.__main__.matlab('3+3')
>      6

Cool. There is also some code IIRC that let's you use ssh to open a
tunnel to another box to execute commands in some supported
application there. It has been a while, but I believe they also used
Matlab.

> Though I suppose this has some minimal use on its own as being a way
> to call proprietary software not available natively on solaris while
> still using native applications from sage (OpenGL visualization comes
> to mind), I think a more common benefit would be in having a solaris
> zone that is used to house a sage notebook server while not having to
> sacrifice the ability to call proprietary software (from a lx zone).

I am very interested in providing a Solaris Zone with Sage since
isolating the notebook into its own little corner of the system is an
excellent idea. If you have some expertise in that area I would be
glad if you could help out there.

> Once I move in to my new apartment and have access to my sever again I
> will try it out ... it doesn't look like it will be long before the
> solaris port is adequate ;)

Yeah, I am really hoping that William and I will sit down this
Thursday and/or Friday and spend some time nailing down some of those
pesky Solaris bugs. It looks like we now have a solution to a sympow
problem, so hopefully another bug just bit the dust.

Cheers,

Michael