[osol-discuss] Re: About Project Indiana
Hi Ian, hi community, I hope not to be late for an opinion about Indiana.If I correctly understand it's a new opensolaris distribution with a binary centric goal.If so,it could be an error.These are months of discussions about pros and cons of CDDL vs GPL and this could be a great occasion to demonstrate the real face (and advantages) of CDDL.This is the occasion to build a real and complete CDDL opensource distribution and offer as *first choice* only products with sources.It's not very important start with the best product,but is important to have all sources.I think that for many people out of there it is a prerequisite,and it is a clear message for all: CDDL is an opensource license same GPL and BSD and Sun with opensolaris community offer it.So,for example,Indiana should be offer as first choice GNU CC and not SunPro compiler because it is a only binary product.Then,but only after that, we can demonstrate the advantages of our license to take other good opportunities,missing in GPL, to offer different and sometimes best products like only binary and commercial products.However it should be remains an user choice. Giacomo ___ OpenSolaris - The Pride of a community This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
(E.g., nVidia drivers) Well, as far as I am aware, Nvidia doesn't allow redistribution of their drivers, due to GPL issues. -Brian ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
(E.g., nVidia drivers) Well, as far as I am aware, Nvidia doesn't allow redistribution of their drivers, due to GPL issues. Clearly they do allow Sun to redistribute them. So a Sun OpenSolaris distribution can contain them. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
opensolaris community offer it.So,for example,Indiana should be offer as first choice GNU CC and not SunPro compiler because it is a only binary product.Then,but only after that, we My understanding is the Forte was going to be OpenSourced? Is this not the case? ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
opensolaris community offer it.So,for example,Indiana should be offer as first choice GNU CC and not SunPro compiler because it is a only binary product.Then,but only after that, we My understanding is the Forte was going to be OpenSourced? Is this not the case? Even so, why should project Indiana offer opensource variants first when better software exists? (E.g., nVidia drivers) Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
Brian Gupta wrote: (E.g., nVidia drivers) Well, as far as I am aware, Nvidia doesn't allow redistribution of their drivers, due to GPL issues. They allow it for Linux BSD - I've asked Sun's contacts with them to ask them to add OpenSolaris to the list of OS'es in their free redistribution clause license, but haven't heard back yet if they will or not. (See section 2.1.2 of http://www.nvidia.com/object/nv_swlicense.html ) -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
On 18/05/07, Brian Gupta [EMAIL PROTECTED] wrote: (E.g., nVidia drivers) Well, as far as I am aware, Nvidia doesn't allow redistribution of their drivers, due to GPL issues. nVidia explicity allows it, the GPL issues exist only on the mind of some distributors and/or copyright holders. -- Less is only more where more is no good. --Frank Lloyd Wright Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Multiple development trees... Re: [osol-discuss] Re: About Project Indiana
OSEE - OpenSolaris Enterprise Edition (classic Solaris) OSCE - OpenSolaris Community Edition (swiss army knife distro) Please don't take my comments as throwing cold water on your strawman; rather, try to use them to help drive a deeper common understanding. I agree with you - we really need to have this kind of discussion. Sorry, I missed replying to this thread. I would say you have one main branch (let's call in OSM: OpenSolaris Main). the OSEE and OSCE distros would take what is in that main branch and make modifications to that base. (Preferably just adding to it.) In poor word pictures, I think we have this today with either (a true source code management system view) OSM = Solaris10RR baseline as of June 2005 | +- OSEE = Solaris10 update releases +- OSCE = OpenSolaris-Nevada (Minor Release) This would be the simplest to implement, and the most likely course of action. or (a cherry picking model requiring manual back porting of desired features from Nevada) OSM = Solaris10RR baseline as of June 2005 | +- OSCE = OpenSolaris-Nevada (Minor Release) | +- OSEE = Solaris10 update releases (pseudo-child of Nevada) +- Solaris Express +- The various existing OS.o distros Ok let me explain what I want: S100RR = Solaris10RR baseline as of June 2005 (Is now SXCE) | + OSM = A completely Opensource Nevada distro/sourcebase. (Our starting point.) | +- OSCE = OpenSolaris-Nevada - Linuxy/Indiana distro (this is a delta against OSM) +- OSEE = Communituy update releases (maybe Belenix based) (This would be an | |OpenSolaris supported distribution of what is now being called SXCE) | +- Solaris Express (Sun's version of OSEE that will be feed into the product Solaris) +- The various existing OS.o distros Changes are reviewed by the ARC for inclusion into OSM, just as they are currently done for Nevada. If for some reason they do not fit, and cause a conflict between OSCE and OSEE, they would be moved into the delta summary of that distro. Please let me know if I am unclear. One could evolve either of these into a more radical scenario where we charter a new Major release: OSM = Solaris10RR baseline as of June 2005 | +- OSEE = OpenSolaris-Nevada (Minor Release of ON5.10) | | | +- Solaris10 update releases (pseudo-child of Nevada) | +- Belinix | +- Schillix | +- Martux | +- OSCE = OpenSolaris-1.0 (Major Release) | +- Solaris 3.0 (aka SunOS 6.0...) +- Nexenta (Don't ask where Indiana fits here - I haven't a clue. As it is, I'm probably maligning Moinak, Erast, Joerg and Martin :-) This is interesting, but I'm sure no-one really wants a completely separate code fork for the Community Edition... When any addition is to be made to a OSEE or OSCE, it must be evaluated for integration into OSM. (With input from the community) In the ARC world view, part of this evaluation is to see if the scope of change proposed matches the target's scope of change allowed, based on the expectations set by the project that first introduced the things being changed, the interface and release taxonomies, and which (if any) things are going to be changed incompatibly. Think of this as: You promised us that XXX would exhibit some level of stability, and now you wish to break it. The magic decoder ring says you can do so only in a it picks one: Major, Minor, Micro release tree. This means that, depending on their release taxonomy bindings, changes that are allowed in OSCE might not be allowed in OSM or OSEE. (duh! :-) I would expect ISVs to port their apps to OSes that Sun distributes and supports. Today Sun distributes and supports Solaris 8 Solaris 9 Solaris 10 Solaris 10 update 1,2,3,4... Solaris Express Solaris Developer Express Historically, ISVs (and Blastwave, too :-) tended to support only Solaris 8, counting on binary compatibility to let it just run on S9 and S10. I'd guess that the number supporting S10 is still ramping up. I wouldn't expect anyone to be offering SX or SDX support at this time, though I assume that many are playing with it in house. Can I get commercial support for SX/SDX from Sun? I know it is distributed by Sun, but I thought it was strictly buyer beware? The $64K question is whether any of them would support a non-Sun distro; just as interesting is whether or not any of the various distro-producers would care and/or whether there was any expectation of compatibility between distros. I don't think this really matters, as this is entirely up to the third party developers. (I suspect their decisions would largely be driven by customer demand). One other note, my feeling is that the community edition would be initially geared more towards those that want a platform for running open source applications, vs. heavyweight commercial applications. You wouldn't need an entire team, as a lot of the work would be in OSM. The thought
Re: Multiple development trees... Re: [osol-discuss] Re: About Project Indiana
I do think that a lot of us folks on the OSS side of Sun want to see Opensolaris be the leader and Solaris be the distribution, which isn't the way it is right now. But I think we're correct in assuming that that is everyone's eventual goal, else why open source Solaris? While I agree with the spirit of what you are saying, I don't completely agree with this. I see: OpenSolaris is the leading distro and codebase. Solaris is *a* distro based on one of the opensolaris distros. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Multiple development trees... Re: [osol-discuss] Re: About Project Indiana
Red Hat and Microsoft had to start with unstable single-user OSes and make them enterprise-capable; surely our task is easier? I would consider Microsoft NT the basis of Modern windows. It took 5/6 major revs before it was ready for use as a mass market OS. The same could be said for RedHat, from the beginning it was targeted as a server OS, with the whole desktop revolution being a distant afterthought. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Multiple development trees... Re: [osol-discuss] Re: About Project Indiana
John, I'm worried about us developing into an OpenSolaris community where Sun's engineers are relegated into a small corner where they only work on Sun's Solaris additions in an OpenSolaris fork, while the rest of the community sees itself as being predominately of and for non-Sun-employed developers. Huh? What's my domain? What's the e-mail domain of 80% of the posters on this or any other OSOL forum? It's gonna be years before Opensolaris stops being 70% Sun. I do think that a lot of us folks on the OSS side of Sun want to see Opensolaris be the leader and Solaris be the distribution, which isn't the way it is right now. But I think we're correct in assuming that that is everyone's eventual goal, else why open source Solaris? Witness the it was said/done by [EMAIL PROTECTED], therefore it must be a conspiracy to undermine OpenSolaris type comments that have cropped up several times in Ian's Indiana thread... Heh. Because, after all, Sun spent hundreds of millions open sourcing Solaris so it could fail. Man, some people see conspiracies *everywhere*. I'm also worried that we at Sun haven't yet figured out how to make a product/distro based on OSCE. IMO, we have all the enterprise stability OSEE mindset we will ever need - so much so that it is blinding us to all those new OSCE-based opportunities. Maybe that is what Indiana is intended to be. That's the general goal as I understand it. As someone who's been with Sun for most of their career put it to me, We're good at making Solaris for hospitals. What we need now is a Solaris for developers. Red Hat and Microsoft had to start with unstable single-user OSes and make them enterprise-capable; surely our task is easier? -- Josh Berkus PostgreSQL Lead Sun Microsystems San Francisco 01-415-752-2500 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: About Project Indiana
Marc Hamilton wrote: but this is really an issue for Solaris engineering more so than for the OpenSolaris community. If the OpenSolaris community creates a production reference distro, then it should be relatively easy for Solaris engineering to align major Solaris releases with OpenSolaris releases and avoid the Fedora/RHEL chasm. Hi ... Perhaps I'm reading too much into your comments here, but why are you drawing a distinction between the OpenSolaris community (creating a reference distro) and Solaris engineering (aligning product releases)? From a development perspective, Solaris engineering /is/ the OpenSolaris community -- plus the new people who are getting involved since June 14, 2005. So, aren't we really talking about largely the same people here? For two years, we've been opening the Solaris code, infrastructure, and engineering organization and in the process mixing with developers from outside the company with the intention of growing one engineering community with one governance model and one development process. We're certainly not there yet, but isn't that the goal? Jim -- Jim Grisanzio, Sr. Program Manager, OpenSolaris Engineering http://blogs.sun.com/jimgris This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
Perhaps I'm reading too much into your comments here, but why are you drawing a distinction between the OpenSolaris community (creating a reference distro) and Solaris engineering (aligning product releases)? I think it is more like a distro that will go beyond the current Solaris market space and another that will solely cater to those who expect the current Solaris 10 environment which will require Solaris engineering to maintain. From a development perspective, Solaris engineering /is/ the OpenSolaris community -- plus the new people who are getting involved since June 14, 2005. So, aren't we really talking about largely the same people here? For two years, we've been opening the Solaris code, infrastructure, and engineering organization and in the process mixing with developers from outside the company with the intention of growing one engineering community with one governance model and one development process. We're certainly not there yet, but isn't that the goal? That, imho, may or may not perpetuate Solaris. Solaris is increasingly becoming a niche OS for 'specialized' environments with Linux slowly heading in the same direction. Current Solaris old hands are adamant that nothing change but unfortunately, the current Solaris environment does not appeal beyond the current Solaris market space. It is time that Solaris take on GNU/Linux by draining their mindshare and then giving others a reason to move to Solaris when it is no longer seen as irrelevant and niche. Send instant messages to your online friends http://uk.messenger.yahoo.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
Chung Hang Christopher Chan wrote: That, imho, may or may not perpetuate Solaris. Solaris is increasingly becoming a niche OS for 'specialized' environments with Linux slowly heading in the same direction. Current Solaris old hands are adamant that nothing change but unfortunately, the current Solaris environment does not appeal beyond the current Solaris market space. It is time that Solaris take on GNU/Linux by draining their mindshare and then giving others a reason to move to Solaris when it is no longer seen as irrelevant and niche. But, work on this has been going on for a while now. Ever seens OpenSolaris came into existence, there is renewed vigour for, for example, laptop support. Live CDs have been created. Sure, there's some way to go, but all of this is already going on, project Indiana or not. More needs to happen, absolutely, but your comment makes it sound like there is a status quo right now. Also, don't assume that some of the hardcore commandline/text afficionados represent a majority here :-) - Frank ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
I have reached decided to include my local LUG in the conversation. I have linked the thread, in case anyone is interested. They have some very valid points). http://nylug.org/pipermail/nylug-talk/2007-May/thread.html#33873 Cheers, Brian P.S. - Please reach out to your local Linux User groups as well. (I did it because I am a member). ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
Brian Gupta wrote: I have reached decided to include my local LUG in the conversation. I have linked the thread, in case anyone is interested. They have some very valid points). Thanks for doing this Brian. I find the discussion on the thread fascinating. -Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
Chung Hang Christopher Chan wrote: That, imho, may or may not perpetuate Solaris. Solaris is increasingly becoming a niche OS for 'specialized' environments with Linux slowly heading in the same direction. Current Solaris old hands are adamant that nothing change but unfortunately, the current Solaris environment does not appeal beyond the current Solaris market space. It is time that Solaris take on GNU/Linux by draining their mindshare and then giving others a reason to move to Solaris when it is no longer seen as irrelevant and niche. I certainly don't agree with the current Solaris old hands comment since many of those engineers are actually quite young and they are the people who built S10, ported to x86/x64, and then opened all this code. Yet you say they are adamant that nothing change? I'm confused. They changed pretty much everything. Also, I think we as a community are doing pretty well. We really don't need to go out and take on and drain the mindshare from other communities. I'd much rather we grow organically at our own pace and earn our way as we go. Jim -- Jim Grisanzio, Sr. Program Manager, OpenSolaris Engineering http://blogs.sun.com/jimgris ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
Ooo,,, the installer has ZFS boot/root support, etc. Huzzah! Now, I wonder if a Solaris built on built on Sun Studio (such as SXCE) would live nicely in a distro built on GCC... *That* would be interesting. DSL ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
the installer has ZFS boot/root support, etc. Huzzah! Now, I wonder if a Solaris built on built on Sun Studio (such as SXCE) would live nicely in a distro built on GCC... *That* would be interesting. ROTFL. Well running Sun Studio did not seem to be a problem (except for missing sun linker...) so may sun studio compiled stuff will be okay since i believe sun studio is sun studio compiled ;). Can't wait for root on zfs install eh? Send instant messages to your online friends http://uk.messenger.yahoo.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Multiple development trees... Re: [osol-discuss] Re: About Project Indiana
Brian Gupta wrote: I proposed in an earlier thread that there I felt there should be two products/distros developed within OpenSolaris.org. - OpenSolaris Enterprise Edition (classic Solaris) - OpenSolaris Community Edition (swiss army knife distro) This is a simple idea that gets hard rather quickly. Coming up with a roadmap/plan that describes what is intended is where we have always run into problems. Some of these imponderables are: Given that we want to have multiple distros, how do we expect that they will be developed? What are the relationships between them? Do we intend to have independent branches, parent-child feature waterfalls, cross-dependent peers, no relationshoip at all, or something else all together? Given a relationship, what is the desired endgame? Does the classic source base go the way of SunOS4.x, becoming a frozen, bugfix-only, no new features platform? Is this simply a request that we do a Major release of Solaris instead of the sequence of compatible Minor releases that we have been doing for the last 15 years? Which of the development trees do we expect ISVs to port their applications to? Both? - if so, are we sure we all understand what drives ISV adoption and customer deployments? Who are the target audiences for each of these releases? If we do this, and it is successful, what does the world look like in 2 years? 5? 10? It would be Sun's digression to support and/or productize either version. (Also, they of course retain the right to make changes when productized, but my hope would be that Sun would propose their changes within the community). Once we have committed to having multiple development branches, we need to figure out how we can avoid doubling the development efforts needed to sustain the code (for bugfixes and patches, feature backports, etc). Of course, it is in Sun's best interest to try and ensure that the work-product of the community aligns with its product plans; IM(NS)HO, it would be a disaster if Sun was forced staff an entire porting team just to maintain its own divergent fork of OS.o ... -John ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Multiple development trees... Re: [osol-discuss] Re: About Project Indiana
- OpenSolaris Enterprise Edition (classic Solaris) - OpenSolaris Community Edition (swiss army knife distro) This is a simple idea that gets hard rather quickly. Coming up with a roadmap/plan that describes what is intended is where we have always run into problems. Some of these imponderables are: Given that we want to have multiple distros, how do we expect that they will be developed? What are the relationships between them? Do we intend to have independent branches, parent-child feature waterfalls, cross-dependent peers, no relationshoip at all, or something else all together? I would say you have one main branch (let's call in OSM: OpenSolaris Main). the OSEE and OSCE distros would take what is in that main branch and make modifications to that base. (Preferably just adding to it.) When any addition is to be made to a OSEE or OSCE, it must be evaluated for integration into OSM. (With input from the community) Given a relationship, what is the desired endgame? Does the classic source base go the way of SunOS4.x, No. The thought is that OSEE, might be the basis for the classic Solaris source base. (Free to be modified by Sun) becoming a frozen, bugfix-only, no new features platform? Is this simply a request that we do a Major release of Solaris instead of the sequence of compatible Minor releases that we have been doing for the last 15 years? Which of the development trees do we expect ISVs to port their applications to? Both? - if so, are we sure we all understand what drives ISV adoption and customer deployments? Who are the target audiences for each of these releases? If we do this, and it is successful, what does the world look like in 2 years? 5? 10? I would expect ISVs to port their apps to OSes that Sun distributes and supports. Whether that is one or two OSes, is still an open question that Sun has to answer outside of the scope of OpenSOlaris). Who is to say what it will look like in ten years. One possible scenario is that OSCE gains critical mass and ends up pulling OSEE into an eventual convergance, with Solaris named releases being 3 year snapshots of OSCE. (Possibly with major changes being backported into the 3 year releases, where they would not be in the 6 month releases) Another possibility is that they diverge and that Sun sells and supports two distros. One for webbies, and the other for bigiron enterprise shops. Initially I see this as somewhat likely, in the next two years, but over the next 5-10 years, it would move to a model closer to the convergance. It would be Sun's digression to support and/or productize either version. (Also, they of course retain the right to make changes when productized, but my hope would be that Sun would propose their changes within the community). Once we have committed to having multiple development branches, we need to figure out how we can avoid doubling the development efforts needed to sustain the code (for bugfixes and patches, feature backports, etc). Try to keep as much code in OSM as possible. (See above for some very rough backporting guidelines). Of course, it is in Sun's best interest to try and ensure that the work-product of the community aligns with its product plans; IM(NS)HO, it would be a disaster if Sun was forced staff an entire porting team just to maintain its own divergent fork of OS.o ... You wouldn't need an entire team, as a lot of the work would be in OSM. The thought would be that Sun developers would focus on OSM, and OSEE, with a few bodies dedicated to OSCE. Most of the community work would be done in OSM and OSCE, with the goal to backport any universally useful OSCE changes into OSM, so that OSEE can leverage that work. Let's use this as a strawman and work from here to figure out how to make this work. brian ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Multiple development trees... Re: [osol-discuss] Re: About Project Indiana
Brian Gupta wrote: OSEE - OpenSolaris Enterprise Edition (classic Solaris) OSCE - OpenSolaris Community Edition (swiss army knife distro) Please don't take my comments as throwing cold water on your strawman; rather, try to use them to help drive a deeper common understanding. I agree with you - we really need to have this kind of discussion. I would say you have one main branch (let's call in OSM: OpenSolaris Main). the OSEE and OSCE distros would take what is in that main branch and make modifications to that base. (Preferably just adding to it.) In poor word pictures, I think we have this today with either (a true source code management system view) OSM = Solaris10RR baseline as of June 2005 | +- OSEE = Solaris10 update releases +- OSCE = OpenSolaris-Nevada (Minor Release) or (a cherry picking model requiring manual back porting of desired features from Nevada) OSM = Solaris10RR baseline as of June 2005 | +- OSCE = OpenSolaris-Nevada (Minor Release) | +- OSEE = Solaris10 update releases (pseudo-child of Nevada) +- Solaris Express +- The various existing OS.o distros One could evolve either of these into a more radical scenario where we charter a new Major release: OSM = Solaris10RR baseline as of June 2005 | +- OSEE = OpenSolaris-Nevada (Minor Release of ON5.10) | | | +- Solaris10 update releases (pseudo-child of Nevada) | +- Belinix | +- Schillix | +- Martux | +- OSCE = OpenSolaris-1.0 (Major Release) | +- Solaris 3.0 (aka SunOS 6.0...) +- Nexenta (Don't ask where Indiana fits here - I haven't a clue. As it is, I'm probably maligning Moinak, Erast, Joerg and Martin :-) When any addition is to be made to a OSEE or OSCE, it must be evaluated for integration into OSM. (With input from the community) In the ARC world view, part of this evaluation is to see if the scope of change proposed matches the target's scope of change allowed, based on the expectations set by the project that first introduced the things being changed, the interface and release taxonomies, and which (if any) things are going to be changed incompatibly. Think of this as: You promised us that XXX would exhibit some level of stability, and now you wish to break it. The magic decoder ring says you can do so only in a it picks one: Major, Minor, Micro release tree. This means that, depending on their release taxonomy bindings, changes that are allowed in OSCE might not be allowed in OSM or OSEE. (duh! :-) I would expect ISVs to port their apps to OSes that Sun distributes and supports. Today Sun distributes and supports Solaris 8 Solaris 9 Solaris 10 Solaris 10 update 1,2,3,4... Solaris Express Solaris Developer Express Historically, ISVs (and Blastwave, too :-) tended to support only Solaris 8, counting on binary compatibility to let it just run on S9 and S10. I'd guess that the number supporting S10 is still ramping up. I wouldn't expect anyone to be offering SX or SDX support at this time, though I assume that many are playing with it in house. The $64K question is whether any of them would support a non-Sun distro; just as interesting is whether or not any of the various distro-producers would care and/or whether there was any expectation of compatibility between distros. You wouldn't need an entire team, as a lot of the work would be in OSM. The thought would be that Sun developers would focus on OSM, and OSEE, with a few bodies dedicated to OSCE. Most of the community work would be done in OSM and OSCE, with the goal to backport any universally useful OSCE changes into OSM, so that OSEE can leverage that work. When I read your comments above, I get the impression that there will be two rather disjoint communities - the Sun- dominated OSM/OSEE one and the non-Sun dominated OSCE. If this is how it works out, what would motivate the OSCE crowd to do the backport work, especially since it would undoubtedly involve more work? -John ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Multiple development trees... Re: [osol-discuss] Re: About Project Indiana
John, This means that, depending on their release taxonomy bindings, changes that are allowed in OSCE might not be allowed in OSM or OSEE. (duh! :-) One of the questions I'd like to answer with the new plan is to find a way to get stuff into some form of OpenSolaris which are not on a roadmap to be in a supported version -- the same way that Linux distros do, such as Fedora and Debian-unstable. There should be a way for things to get into an Opensolaris edition which do not go though the full ARC process; we just check that their file paths are acceptable, flag them as unsupported and leave it at that. As an example, it's probably in the future that Sun Solaris will not support every single release of PostgreSQL; they are too frequent and users are too reluctant to upgrade, so we will probably skip some releases. But we want to offer the cutting edge versions in an unsupported, rapid-release fashion for the users who care more about the latest features than they do about API stability. I'd like a way to do that which is more mainstream than the current Blastwave - Solaris relationship. So if that's OSCE then I'm for it. When I read your comments above, I get the impression that there will be two rather disjoint communities - the Sun- dominated OSM/OSEE one and the non-Sun dominated OSCE. If this is how it works out, what would motivate the OSCE crowd to do the backport work, especially since it would undoubtedly involve more work? Frankly, I don't see the opensolaris community doing backport work at all. Why would we? Backporting is for supported versions, where (presumably) support customers will pay for someone to do the boring backporting work. I guess I'm not seeing why this is a problem? -- Josh Berkus PostgreSQL Lead Sun Microsystems San Francisco 01-415-752-2500 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: About Project Indiana
Again, these are just some thoughts, not a plan. Constructive comments are welcome. The Solaris community seems to be stratified into two very different layers. One group is made up of the people who have worked with Unix systems for years. And the other group is people looking to push the OS into places it has never been before. You could say that one group wants the status quo, while the other wants significant change. Those two groups seem to want things that are very nearly mutually exclusive. As such, is there a way to accommodate both groups? A way to continue producing traditionally featured Solaris releases for one part of the community, while developing a cutting edge system of new designs for the other part of the community? I think that is almost being done right now. But the problem is that everyone is smushed into the same group, so the different identities are conflicting, which is holding the whole group back. So what if you created two distinct communities. One that pushes the OpenSolaris code base to new places with smart *new* (key word) ideas and research. You'd see frequent builds of this, say OpenSolaris Edge. Meanwhile, Sun continues to pull code from this base to build the classic Solaris that everyone knows, for as long as it is demanded. The first thing I ask myself is why is that OS-OS distinction better than keeping the distinction in two branded zones of one OS?, and maybe there isn't much difference. But we already see a gaping hole where people say isn't OpenSolaris an OS? What is it?, so maybe there is a need that can be filled by two distinct OS products. Maybe everyone in the community needs to find their home in a cause that they support (Solaris vs OpenSolaris cutting edge), so that everyone can move forward to cooperate in what they agree upon, and go their own way on what they disagree upon. If you look into the future you might see one product swallowing the other. But for now, as long as two special cultures exist, maybe two distinct projects/products/communities should be formed to allow mostly-similar but somewhat-different directions to be taken. Maybe then everyone can have and eat their cake :) This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
On 5/14/07, Brian Gupta [EMAIL PROTECTED] wrote: I proposed in an earlier thread that there I felt there should be two products/distros developed within OpenSolaris.org. - OpenSolaris Enterprise Edition (classic Solaris) - OpenSolaris Community Edition (swiss army knife distro) It would be Sun's digression to support and/or productize either version. (Also, they of course retain the right to make changes when productized, but my hope would be that Sun would propose their changes within the community). I thought it best to add in here that Nexenta itself is not stagnant, and has tried to be the swiss army knife distro. I'm a little biased to getting Solaris over its perceived hurdles and taking ideas liberally from others. All that said, my slides on Nexenta's use at Stanford as our new preferred Solaris solution, presented at CommunityOne, are now online at http://jmlittle.blogspot.com Furthermore, expect an A7 release this week of Nexenta on B61. As noted from the slides, it will quickly approach a 1.0 as all the latest Ubuntu (Feisty Fawn) packages are integrated, the installer has ZFS boot/root support, etc. Cheers, Brian ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
- OpenSolaris Enterprise Edition (classic Solaris) - OpenSolaris Community Edition (swiss army knife distro) I thought it best to add in here that Nexenta itself is not stagnant, and has tried to be the swiss army knife distro. I'm a little biased Thanks for info! I am thinking that the existing distros should play parts in this strategy, as some have overlapping goals. Off the top of my head, I think that for the dual d9stro strategy, the following would be the best suited starting points. - Belenix - base for building OpenSolaris Enterprise Edition (SEE) - Nexenta - base for building OpenSolaris Community Edition (SCE) One question. Should there be a third build? OpenSolaris CBR (Common Base Reference)? This would be the minimum runnable build that all distros could use as a starting point. (Both of the above would be build on top of the Reference build). Cheers, Brian ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
MC wrote: Again, these are just some thoughts, not a plan. Constructive comments are welcome. The Solaris community seems to be stratified into two very different layers. One group is made up of the people who have worked with Unix systems for years. And the other group is people looking to push the OS into places it has never been before. You could say that one group wants the status quo, while the other wants significant change. There are actually 3 types (actually more). You missed the people you have use Unix systems for years, and thinks that the status quo always sux! ( Not the Band ). Also there is a 'I hate Linux at all cost' crowd. Those two groups seem to want things that are very nearly mutually exclusive. As such, is there a way to accommodate both groups? A way to continue producing traditionally featured Solaris releases for one part of the community, while developing a cutting edge system of new designs for the other part of the community? You are fixated by the only 2 groups that are just the representatives of noise. My views on people who wants the traditional is to give them Solaris 2.6 and an Ultra 1. As long as they have electricity, they will be happy as a pig in. No really, people who do not want change, would be better suited by Closed Solaris. I think that is almost being done right now. But the problem is that everyone is smushed into the same group, so the different identities are conflicting, which is holding the whole group back. So what if you created two distinct communities.One that pushes the OpenSolaris code base to new places with smart *new* (key word) ideas and research. You'd see frequent builds of this, say OpenSolaris Edge. Meanwhile, Sun continues to pull code from this base to build the classic Solaris that everyone knows, for as long as it is demanded. Why bother. Just keep on patching Sol 2.6, and let everybody else progress. In 10 years time they will still be able to upgrade to Solaris 8. The first thing I ask myself is why is that OS-OS distinction better than keeping the distinction in two branded zones of one OS?, and maybe there isn't much difference. Actually there is a hell of a difference. My desktop is in the global zone. I would hate to see it stuck in the last century. Doug ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
Furthermore, expect an A7 release this week of Nexenta on B61. As noted from the slides, it will quickly approach a 1.0 as all the latest Ubuntu (Feisty Fawn) packages are integrated, the installer has ZFS boot/root support, etc. yah! let the packaging begin! i'll live with gcc. Send instant messages to your online friends http://uk.messenger.yahoo.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: About Project Indiana
Ian Murdock wrote: So, what will be the big features in Indiana? You tell me--and, indeed, a discussion of features could be a great way to actually get off on the right foot here given the somewhat rocky start so far.. My list: packaging, installation, GNU userland alongside Solaris classic userland, and laptop support (see what I mean that there are already people working on these things?). Hi, I would like to report that regarding the laptop issues many of them have actually been resolved already. with Build 63 SXDE I have : Automatic Graphics card recognition. Automatic Wireless driver installation. Automatic Network setup with wireless. Whats needed in the laptop arena is more effort from SUN to convince Vendors to make Specs for hardware available to the open source community I bought an Intel 2200BG Mini-pci wireless card off a local shop. The comment from the salesman was : I cant believe how popular this wireless card is, do you know why ? So I told him that Intel made the specs for the device available to the opensource community , and lots of people running Unix/Linux on their laptops were replacing the wireless devices from Broadcom and others who did not publish the specs. Thats the kind of effect on sales that opensourceing a hardware driver has. Vendors need to be told. So a large part of the usability of laptops is in the area of drivers rather than a linux style userland. Heck, even linux users are suffering from the the lack of will to opensource drivers from hardware vendors. Regarding the Userland and the Toolchain needed to produce the userland: Solaris has by now at least 4 different sets of toolchains/userland that I know of ( apart from Nexenta/benelix/shilix/martux distros ) for opensource S/W Companion CD Blastwave Sunfreeware KDE-Solaris All this stuff has risen from the need to compile and deliver opensource S/W on solaris , because the ON-Solaris toolchain/libraries was not compatible enough at some point in time. There has been discussions over and over again to address this problem and create a common single set of opensource toolchain/userland for opensource applications . PLEASE: Do NOT create a FIFTH set of userland/toolchain to be used on top of Solaris. If you want to achive usability and familiarty for the developer which results in more applications for the users: Spend 20 million dollars or so and unify these existing environments. and secure agreements from the people involved to work together on one environment. //Lars This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
Lars Tunkrans wrote: Ian Murdock wrote: So, what will be the big features in Indiana? You tell me--and, indeed, a discussion of features could be a great way to actually get off on the right foot here given the somewhat rocky start so far.. My list: packaging, installation, GNU userland alongside Solaris classic userland, and laptop support (see what I mean that there are already people working on these things?). Hi, I would like to report that regarding the laptop issues many of them have actually been resolved already. with Build 63 SXDE I have : Automatic Graphics card recognition. Most graphics cards are recognized with Solaris Express. I fact Solaris Express is the 'only' OS that installed the Nvidia drivers off the OS media for my desktop. For both Windows and Linux it involved a download. Automatic Wireless driver installation. Automatic Network setup with wireless. Whats needed in the laptop arena is more effort from SUN to convince Vendors to make Specs for hardware available to the open source community I bought an Intel 2200BG Mini-pci wireless card off a local shop. The comment from the salesman was : I cant believe how popular this wireless card is, do you know why ? So I told him that Intel made the specs for the device available to the opensource community , and lots of people running Unix/Linux on their laptops were replacing the wireless devices from Broadcom and others who did not publish the specs. Yeah I would never buy another laptop with a ATI graphics card and a broadcom wireless network card. Thats the kind of effect on sales that opensourceing a hardware driver has. Vendors need to be told. It does not need to be opensource, as long as they make a driver available for every platform :) Their Choice! Regarding the Userland and the Toolchain needed to produce the userland: Solaris has by now at least 4 different sets of toolchains/userland that I know of ( apart from Nexenta/benelix/shilix/martux distros ) for opensource S/W Companion CD Blastwave Sunfreeware KDE-Solaris If you call KDE-Solaris a 'toolchain', then you should multiply your figures by 100's. I don't see a problem with 'multiple tool chains'. Most cater for different needs. Blastwave for instance best suited for Solaris 8 to 10. As long as they openly share patches and build specs I do not really see a big problem. All this stuff has risen from the need to compile and deliver opensource S/W on solaris , because the ON-Solaris toolchain/libraries was not compatible enough at some point in time. No it is more the case that Sun could not afford to support costs for their customers. There has been discussions over and over again to address this problem and create a common single set of opensource toolchain/userland for opensource applications . Personally I quite like choice. Not everybody builds their systems the same way. Everybody has different needs. For instance you will get a very heated discussion on what packages and library dependencies an application has. Some people want only the minimal dependencies and give up features of an application. Where others want the kitchen sink thrown in. PLEASE: Do NOT create a FIFTH set of userland/toolchain to be used on top of Solaris. Please do! If you want to achive usability and familiarty for the developer which results in more applications for the users: Spend 20 million dollars or so and unify these existing environments. and secure agreements from the people involved to work together on one environment. A waste of 20 million... Doug ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
Doug Scott wrote: Yeah I would never buy another laptop with a ATI graphics card and a broadcom wireless network card. Hmmm, maybe I was just a little hasty with not buying AMD/ATI anymore - http://www.osnews.com/comment.php?news_id=17902 Doug ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
packaging, installation, GNU userland alongside Solaris classic userland, and laptop support may I insert gcc extension support before GNU userland (not that it is not getting there)? Send instant messages to your online friends http://uk.messenger.yahoo.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: About Project Indiana
[...] far.. My list: packaging, installation, GNU userland alongside Solaris classic userland, and laptop support (see what I mean that there are already people working on these things?). At least you didn't use the pejorative marketing term legacy. Hopefully, if different userlands were to appear in different zones, the alien, er, I mean immigrant-friendly (pain. from. PC. speak.) environments would optional and not in the global zone. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: About Project Indiana
Firstly, let me state that upfront that I'm not sure that I have much sympathy for the familiarity problem; one problem for the non-Linux world is that a large proportion of free software developers have been ignorant of the fact that there are systems that aren't Linux and work in different ways, although this has been improved recently. Therefore, I'm somewhat loathe to change anything in OpenSolaris to help perpetuate that mindset. Having said that, of course Sun want to grow their mindshare and install base and breaking down some barriers is part of that. That said, even as we aggressively move to make Solaris more familiar to Linux users, we will be equally aggressive in pushing Solaris' unique features to the fore--i.e., to the extent that Solaris starts to look like a distro to solve the familiarity problem, it's not yet another Linux, but a _better Solaris_. So does it replace Solaris? I'm all for having an additional project pushing a distribution of OpenSolaris that smells like Linux, but I want you to leave Solaris out of it, thanks very much. If it's not Solaris, but something different, then it doesn't really bridge the barrier to adoption and Solaris proper will actually suffer worse than it apparently does now. Solaris with more of a GNU userland, as either a separate distro or as a branded zone, might, as long as all libs, devs, and config files remained the same as on plain Solaris (so that anything developed in the Linux-friendly environment would Just Work in a plain Solaris environment) ease porting Linux apps to Solaris; at least it would cut out for the most part the excuse (IMO) that the usual tools weren't handy in the usual places; hopefully the remaining differences other than code things (for which the app developers should then be able to focus on or at least accept patches!) wouldn't be too much greater than between Linux distros. That is, they wouldn't have to waste a lot of time on just build mechanics. IMO it's critical that that be usable in that fashion (and not result in packages that won't run on regular Solaris), and that it be utterly optional and non-interfering on the traditional Solaris distro. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
Solaris with more of a GNU userland, as either a separate distro or as a branded zone, might, as long as all libs, devs, and config files remained the same as on plain Solaris (so that anything developed in the Linux-friendly environment would Just Work in a plain Solaris environment) ease porting Linux apps to Solaris; at least it would cut out for the most part the excuse (IMO) that the usual tools weren't handy in the usual places; hopefully the remaining differences other than code things (for which the app developers should then be able to focus on or at least accept patches!) wouldn't be too much greater than between Linux distros. That is, they wouldn't have to waste a lot of time on just build mechanics. Even a choice through $PATH is just fine with me; or compatible extended changes of our own utilities, though one shudders to think what on earth gave rise to make -C IMO it's critical that that be usable in that fashion (and not result in packages that won't run on regular Solaris), and that it be utterly optional and non-interfering on the traditional Solaris distro. Clearly. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
On Sat, May 12, 2007 at 03:49:52AM -0700, Richard L. Hamilton wrote: Firstly, let me state that upfront that I'm not sure that I have much sympathy for the familiarity problem; one problem for the non-Linux world is that a large proportion of free software developers have been ignorant of the fact that there are systems that aren't Linux and work in different ways, although this has been improved recently. Therefore, I'm somewhat loathe to change anything in OpenSolaris to help perpetuate that mindset. Having said that, of course Sun want to grow their mindshare and install base and breaking down some barriers is part of that. That said, even as we aggressively move to make Solaris more familiar to Linux users, we will be equally aggressive in pushing Solaris' unique features to the fore--i.e., to the extent that Solaris starts to look like a distro to solve the familiarity problem, it's not yet another Linux, but a _better Solaris_. So does it replace Solaris? I'm all for having an additional project pushing a distribution of OpenSolaris that smells like Linux, but I want you to leave Solaris out of it, thanks very much. If it's not Solaris, but something different, then it doesn't really bridge the barrier to adoption and Solaris proper will actually suffer worse than it apparently does now. Solaris with more of a GNU userland, as either a separate distro or as a branded zone, might, as long as all libs, devs, and config files remained the same as on plain Solaris (so that anything developed in the Linux-friendly environment would Just Work in a plain Solaris environment) ease porting Linux apps to Solaris; at least it would cut out for the most part the excuse (IMO) that the usual tools weren't handy in the usual places; hopefully the remaining differences other than code things (for which the app developers should then be able to focus on or at least accept patches!) wouldn't be too much greater than between Linux distros. That is, they wouldn't have to waste a lot of time on just build mechanics. What worries me is that if Indiana is some third thing between Solaris and Linux then apps will never be ported past Indiana, making the availability of applications on Solaris actually suffer. Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgp53RKPBj0Ue.pgp Description: PGP signature ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: About Project Indiana
On 5/12/07, Ceri Davies [EMAIL PROTECTED] wrote: On Sat, May 12, 2007 at 03:49:52AM -0700, Richard L. Hamilton wrote: Having said that, of course Sun want to grow their mindshare and install base and breaking down some barriers is part of that. What worries me is that if Indiana is some third thing between Solaris and Linux then apps will never be ported past Indiana, making the availability of applications on Solaris actually suffer. Perhaps like the effect that WinOS2 had on OS/2 ? Windows better than Windows was the IBM message of the day and they were right. No one needs apps for OS/2 anymore. No .. somehow I think that sort of thing is not in the works again. Dennis ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: About Project Indiana
My list: packaging, installation, GNU userland alongside Solaris classic userland, and laptop support Ian, your list sounds a lot like what I would call usability issues. If you feel like you have to use the term familiarity to sell the concept to Sun management, then you have my sympathy and my understanding. :-) I hope it's okay if I continue to call these issues usability issues. There's really not enough room in the universe for a server-only operating system. I think if Solaris becomes marginalized on the desktop, it'll be the start of a downhill slide. Therefore, we need to be more usable *relative to* all the people who are currently using the most popular UNIX-like desktop operating systems. (That would be mostly Linux). If you're asking for my list of priorities, it would be: packaging, installation, GNU userland alongside Solaris classic userland, and laptop support Go, man, go! --chris This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: About Project Indiana
Good post. Too bad it didn't come sooner to cut off the FUD before it started :) This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: About Project Indiana
I wrote this rant in response to a question about how to solve the problems that show up when two different versions of the same library get pulled into a program through different dependencies and chaos ensues. This thread seems like a better thread to attach my rant to. :-) - The practical consideration that keeps this from happening in Linux distros is a unified software distribution model that includes OS packages like gnome, and USER packages like the stuff in blastwave in the same distribution and update system. This makes it possible to fix such overlap problems in a way for covers many more packages. My desktop has important, common, portable utilities in: /usr(apache 1.3) -- from OS/Net /usr/sfw(mysql) -- from SFW consolidation /opt/csw(ruby, etc) -- from blastwave /opt/sfw(xemacs, vnc) -- from companion dvd Trying to get various pieces from these different sources working together is enough to make me want to install Ubuntu. The solution that seems acceptable to the majority of Solaris developers (meaning devs OF solaris, not devs ON solaris) is to bundle everything into Solaris. I'm not sure that will ever get us to a state where it's easy to keep up-to-date with the open source world in a sane way. I understand the stability and quality that we get in Solaris as a direct result of our bundle and test orientation. But it's in direct conflict with being able to rearrange your file system and libraries to make them sane in response to changes coming in from the open source side. What I'm hoping we'll have one day is distribution system for packages (like pkg-get, for example, or something like it). This system should be able to supply and install all the latest: 1. packages to create Solaris 10 update N 2. patches to update this release 3. packages to produce latest nevada release 4. packages to install user-contributed software If the dependencies permit, I should be able to use the same user-contributed package on either Solaris 10 update N or on Nevada. This still supports a model where we bundle and test the set of packages that produce Solaris 10 update N. (And other FCS releases). The we need a unified distribution system that INCLUDES user-supplied packages. (For example, by having the user supply a list of URLs to scan for packages) I haven't seen any practical work towards this end. All the real installer / ease-of-use projects at Sun I've seen focus on Solaris. Meaning they ignore blastwave, companion cd, etc. We need to do better at facilitating the ability of our external developer community to do what they want to do. That is: produce, release, maintain and distribute software for Solaris without asking permission from Sun. --chris This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
