On Mon, 2006-04-17 at 22:08 -0700, ken mays wrote:
> Going back to the comments about Nexenta build system:
Nexenta build system == Debian build system
The equation above means that NexentaOS following
Debian Policy[1] as close as possible. This is done on purpose.
Since a) we now can collaborate
Going back to the comments about Nexenta build system:
1. What ever happened to running Debian/Linux packages
natively (or by wrapper)??
2. Can we build from Nexenta in providing "Debian"
packages for Schillix, SXCR, and Belenix???
3. What is being done currently with colleges,
universities, and
Hi,
Here's OpenSolaris Weekly News #8. As always feedback, or content [from
the missing represented communities] welcome. I probably did a poor job
of summarizing the biggest thread this week on the Nevada Companion
Software proposal - I blame Keith ;)
Glynn
==
Tom Erickson announced [1] Projec
Hi Alan,
On Mon, 17 Apr 2006, Alan DuBoff wrote:
> ...
> everyone, the blastwaves, the nexentras, pkgsrc, et
> all...or is this even possible? I think it would be
> possible to give these folks an > option by having a
> common set of libs that Sun and Community participates
> in, what do you thin
On Fri, 2006-04-14 at 07:41 -0400, Dennis Clarke wrote:
> Let's consider the posibility that someone joins and claims to be a
> programmer for company XYZ Inc. In truth they work for no one. We call up
> company XYZ to confirm that they actually work there and then someone will
> say "yes, they w
What do people think about this? I just saw it on some OSNews story I was
reading (don't cane me please..)
http://www.stdlib.net/~colmmacc/category/niagara/
Maybe somebody would be interested in working with the guy to analyze the
situation and determine the cause of the performance disparity?
Hiya,
On Thu, 2006-04-13 at 15:24 -0700, Philip Brown wrote:
> This issue came up wy back 5 years(?) ago when I started things off.
> We initially tried to build on top of Sun shipped stuff, which at that time,
> was all living in /opt/sfw. It didnt work.
I just wonder if those are a reflec
On Tue, 2006-04-18 at 13:26 +1200, Glynn Foster wrote:
> Hi,
>
> On Thu, 2006-04-13 at 14:52 -0500, Eric Boutilier wrote:
> > Another +1 here.
> >
> > And for another huge reason why it's important to go hash it out ASAP,
> > consider the build systems that the other distros are planning/doing f
Hi,
On Thu, 2006-04-13 at 14:52 -0500, Eric Boutilier wrote:
> Another +1 here.
>
> And for another huge reason why it's important to go hash it out ASAP,
> consider the build systems that the other distros are planning/doing for
> freeware apps:
>
> - The SchilliX project plans to implement t
On 4/18/06, Bart Smaalders <[EMAIL PROTECTED]> wrote:
> Martin Schaffstall wrote:
>
> > Obvious choice would be "SKML", the "Solaris Kernel Mailing List".
>
> That works, and seems somehow familiar.
>
> We've always (well, for the 17+ years I've been here) had
> a kernel mailing list. We could put
On Mon, 2006-04-17 at 16:23 -0700, Alan DuBoff wrote:
> However, what I personally would like to see is the same thing I've always
> invisioned from the days of yesteryear...That we could have a full
> distribution that rivaled any of the open source distributions with Solaris
> as our core, rat
I agree about keeping the scope broader (with perhaps sub-discussions more
specific? Don't know if this is do-able..). At the same time, I also agree a
better name is in order, when I saw "Muskoka" I quit reading previously. I
didn't even realize it was simply the technical mailing list, due to
> On Mon 17 Apr 2006 at 05:28PM, Daniel B. Price wrote:
> Can I ask a dumb question: why are we calling this
> "the muskoka
> project"?
>
> Naming a mailing list filled with technical kernel
> content after an obscure
> lake in Canada seems maximally confusing to me, and
> would seem to make
> it
On Mon 17 Apr 2006 at 04:55PM, Bart Smaalders wrote:
> Martin Schaffstall wrote:
>
> >Obvious choice would be "SKML", the "Solaris Kernel Mailing List".
>
> That works, and seems somehow familiar.
>
> We've always (well, for the 17+ years I've been here) had
> a kernel mailing list. We could pu
Martin Schaffstall wrote:
Obvious choice would be "SKML", the "Solaris Kernel Mailing List".
That works, and seems somehow familiar.
We've always (well, for the 17+ years I've been here) had
a kernel mailing list. We could put your idea in first normal
form and have
[EMAIL PROTECTED]
There
On 4/18/06, Rich Teer <[EMAIL PROTECTED]> wrote:
> On Mon, 17 Apr 2006, Dan Price wrote:
>
> > Naming a mailing list filled with technical kernel content after an obscure
> > lake in Canada seems maximally confusing to me, and would seem to make
>
> As opposed to naming it after an obscure state in
On Thursday 13 April 2006 03:24 pm, Philip Brown wrote:
> *wave*.
*wave*.;-)
(I've been away on vacation for a week, and have over 2000 messages in my
inbox, but it happened that yours was at the top of the stack;-)
You forgot to mention that you a conspirator in the [EMAIL PROTECTED], err...I
On Mon, 17 Apr 2006, Dan Price wrote:
> Naming a mailing list filled with technical kernel content after an obscure
> lake in Canada seems maximally confusing to me, and would seem to make
As opposed to naming it after an obscure state in the US? ;-)
Joking aside, I agree that mailing list nam
On Tue 11 Apr 2006 at 03:02PM, Nils Nieuwejaar wrote:
> >> Peter Buckingham wrote:
> >> > There was some discussion about having a more technical mailing
> >> > list/community ala freebsd hackers/lkml/...
> >> >
> >> > Was there any progress made on that? I'm definitely interested in
> >> > discove
Holger Berger wrote:
I think one part of this jigsaw is the disk bottleneck. If you build
ON on a tmpfs volume you should have a far better CPU utilisation on
Niagara.
Nothing beats real data, so I ran a nightly on a tmpfs file system with
max jobs = 32. The build time decreases from 1:53 (o
Jim Grisanzio wrote:
Michael Pogue wrote:
I have a suggestion: in another current thread, "Build times for Open
Solaris", there's discussion about build parallelism on a Niagara
(T1000), and how we don't get much benefit in build time beyond 4 CPUs.
I think that it would be a great Summer o
I'm not suggesting a new OpenSolaris Project, although that
would certainly be one way to do it. I'm just suggesting a Google
Summer of Code project.
If it ends up being just one Summer of Code student that takes this on,
then a full-blown OpenSolaris Project for one person might be overkill.
In
Hi all, I'm interested in installing Solaris 10/11 x86 on a remote
x86 machine which does *not* have LOM.
I have serial console access to the machine and it is currently
running Linux. Is there an easy way I can install Solaris on this
machine via an ISO file, or a partition with a Solaris
I'm not sure yet which internal Sun group could do this. But, since this could potentially improve
the build process for everybody, I think that figuring this out would be very much worth it. I'm
willing to help!
Since Niagara is one of the first machines with this much on-chip parallelism (b
On Mon 17 Apr 2006 at 02:24PM, Jim Grisanzio wrote:
>
> Michael Pogue wrote:
> >I have a suggestion: in another current thread, "Build times for Open
> >Solaris", there's discussion about build parallelism on a Niagara
> >(T1000), and how we don't get much benefit in build time beyond 4 CPUs.
>
Just to explain what the current situation is:
+ the NetBSD iSCSI target should build and run on Solaris x86/Sparc just fine
(I have an AXi with Solaris 9 on it) - I fixed some alignment bugs in the
target yesterday.
+ it should interoperate/work just fine with the MS initiator
+ there is an i
Michael Pogue wrote:
I have a suggestion: in another current thread, "Build times for Open
Solaris", there's discussion about build parallelism on a Niagara
(T1000), and how we don't get much benefit in build time beyond 4 CPUs.
I think that it would be a great Summer of Code project, to inv
On Mon, Apr 17, 2006 at 09:41:21PM +0200, Holger Berger wrote:
>
> It is still a bug which should be fixed. The requirement that only the
> base of a ZFS file system can be shared is a serious limitation which
> will hamper or even prevent deployment of ZFS at large sites.
I haven't quite grokked
Hi Mike,
This looks to be a good project. Student should get access to T1000
box. Which group within Sun can give T1000 access to student?
thanks
M.Sridhar
Michael Pogue wrote On 04/17/06 01:59 PM,:
I have a suggestion: in another current thread, "Build times for Open
Solaris", there's
Michael Pogue wrote:
I have a suggestion: in another current thread, "Build times for Open
Solaris", there's discussion about build parallelism on a Niagara
(T1000), and how we don't get much benefit in build time beyond 4 CPUs.
I just retracted that statement... It does improve with more
pa
> On 4/12/06, Darren J Moffat <[EMAIL PROTECTED]> wrote:
>> So why not have /export/zfs_0/
>> /export/zfs_0/jumpstart
>> /export/zfs_0/jumpstart/s10
>> /export/zfs_0/jumpstart/s10/SXCRb35
>>
>> all as separate ZFS filesystems, they are cheap after al
I have a suggestion: in another current thread, "Build times for Open Solaris", there's discussion
about build parallelism on a Niagara (T1000), and how we don't get much benefit in build time beyond
4 CPUs.
I think that it would be a great Summer of Code project, to investigate what it would
On 4/1/06, Roland Mainz <[EMAIL PROTECTED]> wrote:
> > because it implicitly assumes that their
> > approach was the best approach to solving the problem or was even tractable.
>
> Ok... I'll try to sync with Holger berger then how to proceed...
Feel free to write the project proposal. I will seco
On 4/12/06, Darren J Moffat <[EMAIL PROTECTED]> wrote:
> So why not have /export/zfs_0/
> /export/zfs_0/jumpstart
> /export/zfs_0/jumpstart/s10
> /export/zfs_0/jumpstart/s10/SXCRb35
>
> all as separate ZFS filesystems, they are cheap after all :-)
It
On 4/14/06, Menno Lageman <[EMAIL PROTECTED]> wrote:
> I happen to have access to a T2000 (1 GHz, 32 strands) for a couple of days,
> so I ran a nightly of on20050327:
>
> Nightly distributed build completed: Thu Apr 13 22:17:16 CEST 2006
>
> Total build time
>
> real2:26:
hey, guys.
Google has announced its 2006 Summer of Code:
http://code.google.com/summerofcode.html
This is the second summer where Google has engaged student developers
worldwide to participate on a variety of open source projects under this
mentoring program. OpenSolaris has applied to be one
On Mon, 17 Apr 2006, Eric Boutilier wrote:
> An up-to-date CCD (and JDS) drives an up-to-date SFW, which reduces
> (dramatically reduces?) the need for distros and ports projects to install
> duplicate libraries.
>
> Or put another way, the OpenSolaris "standard base" improves in a way that
> dra
Casper Dik wrote:
I know Solaris has a slower release cycle - but with CCD developed by
Open Solaris community it could change - I mean CCD could be uptodate
as Blastwave or other projects. Now it would be up to client if he/she
wants the latest from OpenSolaris or Solaris release boundled CCD.
Danek Duvall wrote:
On Fri, Apr 14, 2006 at 01:06:21AM -0700, Menno Lageman wrote:
This was with the default max concurrent jobs = 4. Increasing it to 32
through $HOME/.make.machines did not decrease build time, because the
build process is mostly serial as Bart noted earlier. Apart from short
>I know Solaris has a slower release cycle - but with CCD developed by
>Open Solaris community it could change - I mean CCD could be uptodate
>as Blastwave or other projects. Now it would be up to client if he/she
>wants the latest from OpenSolaris or Solaris release boundled CCD.
The big advanta
On Sat, Apr 15, 2006 at 03:35:52AM +0200, Robert Milkowski wrote:
>
> Saturday, April 15, 2006, 2:27:45 AM, PB writes...
>
> PB> Basically, blastwave packages are set up to be binary distributions, not
> PB> developer distributions.
> PB> If you want to compile other stuff against our packages, y
Hello Bill,
Saturday, April 15, 2006, 3:50:14 PM, you wrote:
BR> On Sat, 15 Apr 2006, Robert Milkowski wrote:
>> Hello Bill,
>>
>> Thursday, April 13, 2006, 8:28:32 PM, you wrote:
>>
>> BR> I say this as someone who has no vested interest in Blastwave,
>> BR> Sunfreeware, or the companion CD but
On Mon, 2006-04-17 at 05:37 -0700, Richard L. Hamilton wrote:
> Same thing happening to me (Solaris 9, on a Sun Blade 100). Any progress
> with the netbsd
> iSCSI target on SPARC?
Yes, we've made a fair amount of progress. The target is now stable and
we're currently working out some issues wit
Same thing happening to me (Solaris 9, on a Sun Blade 100). Any progress with
the netbsd
iSCSI target on SPARC?
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
44 matches
Mail list logo
