[osol-discuss] Re: Re: Re: JAVA iSCSI Target implementation ? / was:Re:Re:
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
Re: [osol-discuss] Project proposal: Nevada Companion Software
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, you are encouraged PB to become a maintainer and add to the collection, using our nice clean PB build servers ;-) Sorry, internal software only. fair enough... [...] What if I want to compile our own software linked with Solaris OpenSSL (to get Niagara HW acceleration for example) and linked with other open source libraries provided by Blastwave? What if then these libraries depend on openssl provided by Blastwave... and things get messy here. That does indeed get messy.But the thing is... in a way, this is sun's fault :-) it should provide patches to openssl to enable niagra acceleration, and then blastwave can use those patches, and then blastwave ssl will have that acceleration too. [really, it should give the patches to openssl.org. but barring that, it would be nice to see a patch set just posted somewhere, like opensolaris.org] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Re[3]: [osol-discuss] Project proposal: Nevada Companion Software
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 advantage I see for a community CCD is up-to-date and compiled against the latest Nevada release, rather than add duplication. (There have been duplications between the CCD and /usr/sfw in the past, notably gcc). And when it finds that certain /usr/sfw or more tightly integrated bits need to be updated, this can be driven from the CCD community directly, keeping the tight integration (duplicating a newer version on the CCD should never be done) Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Project proposal: Nevada Companion Software
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. The big advantage I see for a community CCD is up-to-date... +1 And when it finds that certain /usr/sfw or more tightly integrated bits need to be updated, this can be driven from the CCD community directly... +1. 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 dramatically makes life easier for developers and package mainainers. Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project proposal: Nevada Companion Software
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 dramatically makes life easier for developers and package mainainers. Agreed. As someone who's not followed this thread closely--I don't have THAT much free time! :-)--I'm not sure I see what all the fuss is about. Yes, I'm sure that all camps could learn from each other, but I don't see how a Sun blessed collection of freeware would spell the death of Blastwave et al. Each collection has its own way of doing things, which may or may not be value; the community will decide which one(s) it prefers. I mean, from my back row seat, this debate is also as sensibe as Joerg getting upset because of Nexenta, BelliniX, and other OpenSolaris distros. Each offers something the others don't, and each (and others hopefully) will find their place in the market. As will Sun's brand of OpenSolaris: Solaris. Just my $0.02 CAD... -- Rich Teer, SCNA, SCSA, OpenSolaris CAB member President, Rite Online Inc. Voice: +1 (250) 979-1638 URL: http://www.rite-group.com/rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Google Summer of Code: Call for OpenSolaris Participation
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 of those mentoring communities. It's a great way for us to contribute to the greater open source community, while at the same time providing us the opportunity to meet new developers -- especially students -- in new areas. See the details (especially question #2) about mentoring: http://code.google.com/soc/mentorfaq.html With more than 40 communities and more than 20 projects I think we have more than enough to offer as this point. I'd like to get a thread started here for possible project ideas. We need to act quickly if we want to participate, though. My initial thought: I think the easiest way to participate is for the OpenSolaris project owners http://www.opensolaris.org/os/projects to be mentors (or identify mentors) to these new student developers. Perhaps we could flush out some ideas in this thread and then the interested projects/owners can mock up their project pages with a Summer of Code section with some items the students can work on. We can then add a box to the front page directing Summer of Code students to those participating projects. That part is easy. The question is this, though: are there any OpenSolaris projects interested in engaging these students in Google's Summer of code? If so, let's talk about what we could offer. I'll collect the ideas and feed them into our application process. Please feel free to forward to any list you think appropriate. Best, Jim -- Jim Grisanzio, Community Manager, OpenSolaris http://blogs.sun.com/jimgris/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Build times for Open Solaris....
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:51 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 periods where 32 concurrent jobs can be seen utilizing the system 100%, the system is mostly idle during the build. This of course makes it a nice shared build machine running, say, 32 builds in parallel. 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. I wish tmpfs would utilise 64k pages instead of the dwarfpages which may even better :-) Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] However, the zfs file system /export/zfs_0 must be shared ?? What ?
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 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. Simplified example: Someone may want to set up shares temporarily in a sub directory and the requirement to create an extra ZFS file system for that is a overkill, if not even a risk for production usage (I consider changes in a file system setup as a far higher risk than letting people share their data via NFS). Holger ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Google Summer of Code: Call for OpenSolaris Participation
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 parallelism, for instance moving to 16 jobs reduces the build time by half an hour. Increasing parallelism further shows only slight improvement. Still, investigating what could be done to further improve would be a nice project. Menno ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Google Summer of Code: Call for OpenSolaris Participation
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 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 take to get full utilization (32 CPU's) on a T1000 building Open Solaris. And then, contribute the changes back to OpenSolaris, speeding up the build process for everybody (who has access to multi-cpu hardware). It wouldn't require deep knowledge of the internals of Solaris, so the barrier to entry is not high. And, it's a chance to play around with some really cool hardware (pun intentional :-). Mike Jim Grisanzio wrote: 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 of those mentoring communities. It's a great way for us to contribute to the greater open source community, while at the same time providing us the opportunity to meet new developers -- especially students -- in new areas. See the details (especially question #2) about mentoring: http://code.google.com/soc/mentorfaq.html With more than 40 communities and more than 20 projects I think we have more than enough to offer as this point. I'd like to get a thread started here for possible project ideas. We need to act quickly if we want to participate, though. My initial thought: I think the easiest way to participate is for the OpenSolaris project owners http://www.opensolaris.org/os/projects to be mentors (or identify mentors) to these new student developers. Perhaps we could flush out some ideas in this thread and then the interested projects/owners can mock up their project pages with a Summer of Code section with some items the students can work on. We can then add a box to the front page directing Summer of Code students to those participating projects. That part is easy. The question is this, though: are there any OpenSolaris projects interested in engaging these students in Google's Summer of code? If so, let's talk about what we could offer. I'll collect the ideas and feed them into our application process. Please feel free to forward to any list you think appropriate. Best, Jim ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [zfs-discuss] Re: [osol-discuss] However, the zfs file system /export/zfs_0 must be shared ?? What ?
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 the original thread completely, but the above statement isn't true. You can _always_ use /etc/dfs/dfstab to share whatever directories you want. The zfs set sharenfs=XXX syntax is just a simplified interface for managing shares, and has the beneficial side effect that such options are kept with your data (in the case of import/export, for example). There will always be things you may want to do (such as sharing it under a different name, or sharing subdirectories of a filesystem) which will exceed the capabilities of this simplified interface. Hope that helps, - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Google Summer of Code: Call for OpenSolaris Participation
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 investigate what it would take to get full utilization (32 CPU's) on a T1000 building Open Solaris. And then, contribute the changes back to OpenSolaris, speeding up the build process for everybody (who has access to multi-cpu hardware). So, in this instance, you are suggesting an entirely new project, correct? If so, a new project will have to be proposed and seconded. Is this something you are proposing? In addition to suggestions for new projects, I'm especially interested in hearing from our existing projects to see what they plan to offer. Thanks, Mike. Jim It wouldn't require deep knowledge of the internals of Solaris, so the barrier to entry is not high. And, it's a chance to play around with some really cool hardware (pun intentional :-). Mike Jim Grisanzio wrote: 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 of those mentoring communities. It's a great way for us to contribute to the greater open source community, while at the same time providing us the opportunity to meet new developers -- especially students -- in new areas. See the details (especially question #2) about mentoring: http://code.google.com/soc/mentorfaq.html With more than 40 communities and more than 20 projects I think we have more than enough to offer as this point. I'd like to get a thread started here for possible project ideas. We need to act quickly if we want to participate, though. My initial thought: I think the easiest way to participate is for the OpenSolaris project owners http://www.opensolaris.org/os/projects to be mentors (or identify mentors) to these new student developers. Perhaps we could flush out some ideas in this thread and then the interested projects/owners can mock up their project pages with a Summer of Code section with some items the students can work on. We can then add a box to the front page directing Summer of Code students to those participating projects. That part is easy. The question is this, though: are there any OpenSolaris projects interested in engaging these students in Google's Summer of code? If so, let's talk about what we could offer. I'll collect the ideas and feed them into our application process. Please feel free to forward to any list you think appropriate. Best, Jim ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Re: Re: JAVA iSCSI Target implementation ? / was:Re:Re:
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 issue with the Cisco/Sun initiator which I'm looking into right now. I've nuked a Lunix partition, installed Sol 10 update 1, and am doing some analysis. More on this as it happens. I'd really like to run open solaris on a Xen domainU - the machine with Sol10 on it is a pkgsrc NetBSD bulk build machine (in one VM), and a NetBSD build box (in another VM). I'd prefer not to have to reboot the box just to run Solaris. I don't suppose there's any chance of Xen domU coming soon? http://www.alistaircrooks.co.uk/src/netbsd-iscsi-20060416.tar.gz Thanks, Alistair This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Google Summer of Code: Call for OpenSolaris Participation
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. I think that it would be a great Summer of Code project, to investigate what it would take to get full utilization (32 CPU's) on a T1000 building Open Solaris. And then, contribute the changes back to OpenSolaris, speeding up the build process for everybody (who has access to multi-cpu hardware). So, in this instance, you are suggesting an entirely new project, correct? If so, a new project will have to be proposed and seconded. Is this something you are proposing? In addition to suggestions for new projects, I'm especially interested in hearing from our existing projects to see what they plan to offer. I don't see why there has to be a 1:1 mapping between opensolaris projects and SoC ideas. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Installing Solaris on a remote x86 box?
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 ISO image on it? Thanks. -Moazam ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Google Summer of Code: Call for OpenSolaris Participation
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. Instead, maybe that student could be participant in a thread in the OpenSolaris Tools community, or perhaps the Performance community (or both). Mike 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 of Code project, to investigate what it would take to get full utilization (32 CPU's) on a T1000 building Open Solaris. And then, contribute the changes back to OpenSolaris, speeding up the build process for everybody (who has access to multi-cpu hardware). So, in this instance, you are suggesting an entirely new project, correct? If so, a new project will have to be proposed and seconded. Is this something you are proposing? In addition to suggestions for new projects, I'm especially interested in hearing from our existing projects to see what they plan to offer. Thanks, Mike. Jim It wouldn't require deep knowledge of the internals of Solaris, so the barrier to entry is not high. And, it's a chance to play around with some really cool hardware (pun intentional :-). Mike Jim Grisanzio wrote: 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 of those mentoring communities. It's a great way for us to contribute to the greater open source community, while at the same time providing us the opportunity to meet new developers -- especially students -- in new areas. See the details (especially question #2) about mentoring: http://code.google.com/soc/mentorfaq.html With more than 40 communities and more than 20 projects I think we have more than enough to offer as this point. I'd like to get a thread started here for possible project ideas. We need to act quickly if we want to participate, though. My initial thought: I think the easiest way to participate is for the OpenSolaris project owners http://www.opensolaris.org/os/projects to be mentors (or identify mentors) to these new student developers. Perhaps we could flush out some ideas in this thread and then the interested projects/owners can mock up their project pages with a Summer of Code section with some items the students can work on. We can then add a box to the front page directing Summer of Code students to those participating projects. That part is easy. The question is this, though: are there any OpenSolaris projects interested in engaging these students in Google's Summer of code? If so, let's talk about what we could offer. I'll collect the ideas and feed them into our application process. Please feel free to forward to any list you think appropriate. Best, Jim ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Google Summer of Code: Call for OpenSolaris Participation
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 of Code project, to investigate what it would take to get full utilization (32 CPU's) on a T1000 building Open Solaris. And then, contribute the changes back to OpenSolaris, speeding up the build process for everybody (who has access to multi-cpu hardware). So, in this instance, you are suggesting an entirely new project, correct? If so, a new project will have to be proposed and seconded. Is this something you are proposing? It sounds like a task for the ONNV project (the one incorrectly labeled as the Nevada project on the current website), not something that needs new project framework set up. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Build times for Open Solaris....
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 (on UFS) to 1:45. It helps, but only slightly (as expected). Menno ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: technical (kernel?) discussion list progress?
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 discoverying/learning more about the internals of Solaris. It has been discussed, but there is some grumbling that opensolaris-discuss is still OK for this kind of discussion since we haven't reached the threshold of pain yet as far as traffic. There has also been a fair amount of this type of traffic on opensolaris-code, although that list should be going away soon... I would like to propose a highly technical kernel related mailing list/project - name TBD (chosen via discussion) per the original (failed community) proposal by Eric Lowe. Essentially I am proposing the Eric Lowe project/list of his behalf or by proxy, if you will. One of these is already being created: the 'muskoka project'. It was proposed and approved a week or two ago, and should go live within another week or so. Eric is one of the initial moderators. 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 harder for people googling for information to find what they want. It makes sense that a project destined to be integrated into a larger codebase would have a codename. Why isn't this named functionally? technical-journal, kernel-tech-journal, etc. all spring to mind. Also, the project seems to have mixed together the idea of a discussion, virtual memory changes, and a library. Wouldn't it make more sense to have a library project which is separate, and a VM project which is also separate? Confused, -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: technical (kernel?) discussion list progress?
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 names should be somewhat guessable by those not in the know. -- Rich Teer, SCNA, SCSA, OpenSolaris CAB member President, Rite Online Inc. Voice: +1 (250) 979-1638 URL: http://www.rite-group.com/rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project proposal: Nevada Companion Software
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 mean secret six.;-) That was over 4 years ago now...things have seemed to change slightly since those days...and Blastwave was formed not long before/after, but around the same time. Read on... Now, eventually, sun caught up, and shipped bar 1.1 But by that time, we were already shipping packages that depended on CSWbar, not SFWbar. It would be really bad policy to go back and force-recompile and repackage CSWfoo to depend on SFWbar, when SFWbar is going to be out of date again soon enough. I think a lot of folks are aware of this mess, not only with you folks, but other distributions are now coming up with their own trees also. To some extent I've learned over the past 4 years that yes, the libraries that were shipped by Sun became outdated, and in some cases to run Sun's packages was to not be using the new great features. Case in point, KDE. I can't fault Blastwave for their move to support their libs, quite honestly that would probably have been what most anyone would have done in the same situation. Sun's use of GNOME only complicates things a lot more though, IMO, and I think you would agree which you point out specifics on. 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, rather than Linux (Debian specific, or shall we say apt functionality). Who would have thought Solaris would become open sources, the thought was laughable 4+ years when the topic surfaced. So, how would it be possible to build a large set of libraries that everyone could update and use together? Is this at all possible? Sun has basically proposed to work with the community, and that is happening, albeit slowly...so would it at all be possible to work with the community and create one large set of libraries we all work with and update together? IOW, Debian unstable tree, and then move things over in static form for specific Solaris releases. I think there needs to be some line here, because folks that want to stay on a specific release will be hard to satisfy for library dependencies. Does this interest you at all Phil? How can we get folks together on the same playing field, 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 think? I don't think everyone will agree to use libs even if they were available, but it would be nice if there was a way for that to happen, IMO. -- Alan DuBoff - Sun Microsystems Solaris x86 Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: technical (kernel?) discussion list progress?
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 the US? ;-) Joking aside, I agree that mailing list names should be somewhat guessable by those not in the know. Obvious choice would be SKML, the Solaris Kernel Mailing List. -- // Martin Schaffstall //EMail: [EMAIL PROTECTED] \\ // \X/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: technical (kernel?) discussion list progress?
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 are, however, significant areas of both interest and technical complexity actually not in the kernel... there really is intelligent life on the other side of the trap table. Should the mailing list name reflect this? - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: technical (kernel?) discussion list progress?
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 put your idea in first normal form and have [EMAIL PROTECTED] There are, however, significant areas of both interest and technical complexity actually not in the kernel... there really is intelligent life on the other side of the trap table. Should the mailing list name reflect this? The Muskoka Project tells us it is more broad: Anyone is welcome to post content here, provided it is technical in nature and is relevant to the OpenSolaris community. (and I should note to Bart that the primary Sun-internal kernel list is mostly defunct at this point (20 members) and that he isn't on it). -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: technical (kernel?) discussion list progress?
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 harder for people googling for information to find what they want. +1 I thought the same thing. The first thing I did when I saw the name muskoka being thrown around was to search for it on wikipedia. While it's cute and all, I relaly think that mailing lists should have a blindingly obvious title :) The suggested name of, Solaris Kernel Mailing List; seems rather appropriate. -Shawn This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: technical (kernel?) discussion list progress?
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 the name. Cheers, David - Original Message - From: Dan Price [EMAIL PROTECTED] Date: Monday, April 17, 2006 2:04 pm Subject: Re: [osol-discuss] Re: technical (kernel?) discussion list progress? 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 put your idea in first normal form and have [EMAIL PROTECTED] There are, however, significant areas of both interest and technical complexity actually not in the kernel... there really is intelligent life on the other side of the trap table. Should the mailing list name reflect this? The Muskoka Project tells us it is more broad: Anyone is welcome to post content here, provided it is technical in nature and is relevant to the OpenSolaris community. (and I should note to Bart that the primary Sun-internal kernel list is mostly defunct at this point (20 members) and that he isn't on it). -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project proposal: Nevada Companion Software
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, rather than Linux (Debian specific, or shall we say apt functionality). Who would have thought Solaris would become open sources, the thought was laughable 4+ years when the topic surfaced. OK. Just to prevent an idea of splintering of Debian+OpenSolaris (i.e. NexentaOS) community. :-) Lets try to avoid a creation of yet another Debian+OpenSolaris community at the moment. Instead work with Nexenta guys to implement what you want. Here is what is going on in NexentaOS camp. Our package database now contains 3800 Debian packages out of 2 available. We soon planning automated import-recompile of huge chunk of missing packages at the point when core main packages will be fully integrated. The process could be monitored[6]. It might happen with Alpha 5 release, but nobody knows at this point. Last month we made significant progress with Debian/Ubuntu communities cooperation. With Debian we are pushing[1] solaris-i386,sparc architecture upstream for dpkg, apt-get, debhelper, debianutils, etc. With Ubuntu we are sharing the same web-portal to track cross-distro-bugs[2]. Launchpad has 300.000+ registered users and developers which contributes to Ubuntu community. Launchpad trying to coordinate development efforts among various distributions. With Ubuntu we are initiated SMFication project[3] which intention to come up with database of manifests script for Ubuntu(and eventually Debian) packages. The project found a warm support from Ubuntu developers community[4]. The was a proposal to come up with GNU/Linux SMF port. Join[5] Debian+OpenSolaris community today and help us to build a distro of your dream! [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361866 [2] https://launchpad.net/distros/nexenta [3] https://launchpad.net/projects/smf-nexenta [4] http://archives.free.net.ph/thread/20060414.201222.b0bd44c4.en.html [5] http://www.gnusolaris.org/gswiki/UserPreferences [6] http://www.gnusolaris.org/dapper.status -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: technical (kernel?) discussion list progress?
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 your idea in first normal form and have [EMAIL PROTECTED] Mailing list names should be descriptive and consists of more than one word. Famous examples for bad list names include [EMAIL PROTECTED] (who receive requests like ... Hey, guys, can I hire you for to hack the Yahoo! account of my ex-girlfriend? I'd like to get the address of her new lover...), [EMAIL PROTECTED] (no subscribers are two months, renamed afterwards) and so on. [EMAIL PROTECTED] is a worthy candidate for the 3rd place in that list. -- // Martin Schaffstall //EMail: [EMAIL PROTECTED] \\ // \X/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project proposal: Nevada Companion Software
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 the SchilliX build system (SPS) - The Belenix project plans to implement the pkgsrc build system. - The Nexenta project already implements a Debian build system (with _huge_ success I might add). IMO, these distros are critically important to a goal we all share; namely, to increase the popularity of OpenSolaris among the broader worldwide open-source/UNIX/Linux community. Yet none of them has endorsed either the Companion or Blastwave. +1 I personally believe its fundamentally important to have a shared infrastructure available that allows people to easily create a tailor made distribution of their own choice based on OpenSolaris technology. What Debian/Ubuntu have done is freaking cool, and we have an ideal opportunity to implement something similar with less complication. Glynn ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Project proposal: Nevada Companion Software
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 for freeware apps: - The SchilliX project plans to implement the SchilliX build system (SPS) - The Belenix project plans to implement the pkgsrc build system. - The Nexenta project already implements a Debian build system (with _huge_ success I might add). IMO, these distros are critically important to a goal we all share; namely, to increase the popularity of OpenSolaris among the broader worldwide open-source/UNIX/Linux community. Yet none of them has endorsed either the Companion or Blastwave. +1 I personally believe its fundamentally important to have a shared infrastructure available that allows people to easily create a tailor made distribution of their own choice based on OpenSolaris technology. What Debian/Ubuntu have done is freaking cool, and we have an ideal opportunity to implement something similar with less complication. From my experience, I found that real value behind Debian is NOT dpkg/apt-get/etc, but its huge, growing and successful community. -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project proposal: Nevada Companion Software
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 reflection of other problems o Communication between SFW teams within Sun and external people o Incompatability of release cycles and schedules o Different set of users targets But this eventually dwindled to such a small percentage, there was no longer any real gain to depending on the SFW versions any more. So I made the decision to simplify the user experience ;-) Completely understandable. I just wonder if it's time to bridge that gap again - and absolutely awesome that you're contributing to the discussion, btw ;) Given that we have to do the full gnome dependancy build on sol8 anyway... it would make life far too complicated to ship two very differently linked versions of gnome; one for sol8, and one for sol10. The single version approach is actually beneficial to the USERS, as well as the blastwave maintainers!! This way means that our users can NFS-export out a single /opt/csw, to ALL their solaris 8, 9, and 10 machines, and have gnome work *exactly the same way* on all of them. Within the JDS team, we're trying to constantly track the GNOME 6 month release cycle and provide packages for the latest and greatest. Doing that on Solaris 8, 9, 10 and Nevada isn't very realistic. As GNOME moves more towards the OS level with things like HAL, it'll prove harder and harder to have it working exactly the same way without porting some core infrastructure back to older releases. While I can appreciate many, many people running Solaris 8 and 9, it seems like a complete waste of development time. I'm a fan of 'release early, release often' stategy FWIW - I'd much rather spend my time filling the software swamps and evolve rather than constantly backport. Maybe you can explain how Blastwave works, and what release cycle you guys have? There's very obvious overlaps with what you're currently doing, and the utopic vision that a lot of people have. Glynn ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] niagra + solaris vs linux article, possible idea for the technically capable
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? That's a pretty big leap in performance considering Solaris really *should* be #1 on the hardware designed by the same company who writes the OS. ;) I realize it might be a bad test or some such, I just found it interesting. Maybe people (with the technical knowledge/know-how) should start approaching people who do comparisons like this one, and determine the root cause. If it's an actual issue with Solaris, then it could be reported and used to better Solaris itself. I wasn't sure if this belonged here or in performance, because this is more of a something people should consider doing in general type post than a setup X beat setup Y, what's the technical reasoning type. Cheers, David ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Project proposal: Nevada Companion Software
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 work here and we will put you right through. In truth it is two people in the same room and their business is to destroy servers with really nasty software. As opposed to the millions of software developers that are writing the millions of unaudited code that forms the base of your packages. Sometimes 'good faith' is as much as you can hope for. Glynn ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Project proposal: Nevada Companion Software
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 think? We can certainly dream... So are you thinking that we try to establish something an /opt/groflib (GRand-unified OpenSolaris Freeware Library), mangaged by a non-partisan governing body. And encourage all stacks to contribute to maintaining a high quality/quantity /opt/groflib, and (more importantly, (IMO) agree to treat /opt/groflib with the same deference as they now treat /usr/lib... ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] OpenSolaris Weekly News #8
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] Project Chime [2], a visualization tool for DTrace. Bryan Cantrill called out [3] for all advocates to post experiences of DTrace as a response to Stephen O'Grady's recent 'Linux response' blog [4], which started a thread of interesting experiences. 1. http://mail.opensolaris.org/pipermail/dtrace-discuss/2006-April/001442.html 2. http://opensolaris.org/os/project/dtrace-chime/ 3. http://mail.opensolaris.org/pipermail/dtrace-discuss/2006-April/001340.html 4. http://www.redmonk.com/sogrady/archives/001494.html Damien Carbery announced [5] that build 9 of JDS Vermillion was now available, including a number of new components. 5. http://mail.opensolaris.org/pipermail/desktop-discuss/2006-April/000710.html Peter Tribble mailed [6] with an install breakdown of where time is spent, analyzing that decompression of packages, SMF import of manifests and installation order were possible low hanging fruit to improve on. Gary M. Gere followed up [7] with some explanation of how the install time order is currently defined. Glen Lagasse announced [8] that build 38 of the packaging tools was now available. 6. http://mail.opensolaris.org/pipermail/install-discuss/2006-April/000142.html 7. http://mail.opensolaris.org/pipermail/install-discuss/2006-April/000154.html 8. http://mail.opensolaris.org/pipermail/install-discuss/2006-April/000172.html Andrei Dorofeev announced [9] that a new version of the cardbus driver was available, given the old one was incompatible with build 37. Andrei also announced [10] that new versions of the ipw/iwi drivers were available. 9. http://mail.opensolaris.org/pipermail/laptop-discuss/2006-April/001032.html 10. http://mail.opensolaris.org/pipermail/laptop-discuss/2006-April/001043.html Ben Rockwood mailed [11] saying that he would be attending the MySQL conference, complete with a T2000 to demo OpenSolaris on. Drop by and say hi! 11. http://mail.opensolaris.org/pipermail/opensolaris-mktg/2006-April/000850.html Moazam Raja asked [12] what the availability of the font for the OpenSolaris logo. Sara Dornsife replied [13] saying that the logo was generated with a Sun font which wasn't being used in any Sun related presentations anymore. Stephen Lau asked [14] if that font was freely available. Laura Ramsey followed up [15] saying that they would look into getting that font cleared for use, provided the current trademark restrictions for OpenSolaris were followed. 12. http://mail.opensolaris.org/pipermail/opensolaris-mktg/2006-April/000825.html 13. http://mail.opensolaris.org/pipermail/opensolaris-mktg/2006-April/000829.html 14. http://mail.opensolaris.org/pipermail/opensolaris-mktg/2006-April/000840.html 15. http://mail.opensolaris.org/pipermail/opensolaris-mktg/2006-April/000842.html Martin Bochnig announced [16] marTux 0.1 Live CD, a SPARC based OpenSolaris distribution [17]. 16. http://mail.opensolaris.org/pipermail/xwin-discuss/2006-April/000181.html 17. http://user.cs.tu-berlin.de/~mbeinsx/marTux/ Alan Coopersmith announced [18] that sources and changelog for the X consolidation to match Nevada build 38. This update contained a number of changes from the localization team to fix many keyboard layouts, along with other fixes. 18. http://mail.opensolaris.org/pipermail/xwin-discuss/2006-April/000189.html Laura Ramsey mailed [19] saying that the April edition of Linux Format included a feature on OpenSolaris. She followed up with a PDF version of the article. 19. http://mail.opensolaris.org/pipermail/opensolaris-discuss/2006-April/015231.html Stephen Hahn posted [20] a technical status update for the OpenSolaris project. 20. http://mail.opensolaris.org/pipermail/opensolaris-discuss/2006-April/015205.html John Plocher announced [21] that the CLIP PSARC case, the command line interface guidelines, was now published on the ARC community. 21. http://mail.opensolaris.org/pipermail/arc-discuss/2006-April/20.html Keith Wesolowski mailed [22] with a project proposal for the Nevada Companion CD. Dennis Clarke argued [23] that everything Keith was proposing was already available with Blastwave [24]. James Dickens replied [25] saying that it would be difficult to get going given that the CCD was a complete closed process. Keith followed up [26] explaining that the current 'CCD team' was just a small group of part time volunteers, and that he hoped to open up the process for all to contribute, with a caveat that this wasn't a project to kill off Blastwave [27]. 22. http://mail.opensolaris.org/pipermail/opensolaris-discuss/2006-April/015203.html 23. http://mail.opensolaris.org/pipermail/opensolaris-discuss/2006-April/015208.html 24. http://www.blastwave.org/ 25.
Re: [osol-discuss] Re: Project proposal: Nevada Companion Software
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 organizations?? Isn't NetBSD doing work in providing packages/ports to Solaris using the NetBSD build system?!? We seem to have lost track of the previous work that was being done to provide Debian packages to Solaris. There was the Linux/FreeBSD style wrapper for running Linux packages on Solaris and then the native source compiles of the same package base used for the Debian packages (17,000-20,200+ packages). We can take all of the current GNU source code as a start and see what builds and doesn't build using the Sun Studio 11 compiler or GCC. That would be a start for someone. Everything else starts to become personal taste ~ Ken Mays __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
