Re: [osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
I think we can close this thread off with the following carton - seen today at http://xkcd.com/c225.html http://imgs.xkcd.com/comics/open_source.png";> James C. McPherson -- Solaris kernel software engineer Sun Microsystems ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
> Few examples: > Linux+Gnome is much faster than Solaris+JDS on the > same AMD hardware. > JDS+Solaris needs more memory than Linux+Gnome (same > hardware). 512MB > are enough for Linux, Solaris starts swapping after a > few hours of > usage and doesn't stop until swap is full. JDS > doesn't grok Gnome > session files from Linux. > > Sure, this is s subjective. Let's ignore these > problems and add > more colorful branding to JDS. > > Josh For me, this isn't the case. Solaris + JDS is much faster than Linux + GNOME on my E6600 Core 2 DUO workstation. Logging in and out are notably faster I might add. As far as Solaris starts swapping after a few hours until it's full? I haven't seen that on my system even after hours or days of usage. As far as the session files, I wouldn't expect it to "grok" them. Given that most distributions of UNIX/Linux/*BSD, etc. heavily patch their versions of GNOME it's unlikely that they would be version compatible anyway. -Shawn This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
On 2/6/07, Alan Coopersmith <[EMAIL PROTECTED]> wrote: Sorry - I've never used Opera and don't know what it does. One thing it *doesn't* do is to bloat Xorg to 684MB in 24 hours. --Stefan -- Stefan Teleman KDE e.V. [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
Doug Scott wrote: Thanks for the explanation. This explains what is happening to firefox. Is Xorg looking into the problem, as it can be a real pain having to restart X every so often. I don't know of anyone at X.Org looking into the problem since it's pretty universally believed to be a Firefox problem, not an Xorg one. Does opera do something else with images? It does not seem to cause the same problem. I will re-test opera again to check my original test. Sorry - I've never used Opera and don't know what it does. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
Alan Coopersmith wrote: Doug Scott wrote: Xorg, keeps on going and going. You exit firefox, and Xorg does not return the memory. Xorg uses standard UNIX malloc, so memory won't be returned to the OS upon free, just to the free space list in the Xorg heap, unless it was a shared memory pixmap that was attached to and later released. (Xsun has a hack to use mmap() for large pixmaps so that it can return memory to the OS, but this hasn't been ported to Xorg.) Alan, Thanks for the explanation. This explains what is happening to firefox. Is Xorg looking into the problem, as it can be a real pain having to restart X every so often. Does opera do something else with images? It does not seem to cause the same problem. I will re-test opera again to check my original test. Doug ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
Richard L. Hamilton wrote: Quite right; I've watched firefox shoot up past 300MB VM usage when it really wasn't doing that much. And I've also seen both mozilla and firefox generate silly amounts of disk I/O simply because of animated GIFs being on a page. Personally, this mostly seems to depend if you have Flash installed. If you do, and you iconify certain windows with flash content looping, then Firefox (and Xorg) can leak gigabytes in a few days. If not (no Flash), the same web browser is fine for weeks and weeks. However, I'm pretty sure I've seen the Linux version of Firefox + flashplayer leak just as badly, given the same web sites. Hugh. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
On 2/5/07, UNIX admin <[EMAIL PROTECTED]> wrote: > I think that maybe x86 *is* the main area where we > need help > from device driver writers who have done the > compatibility > heavy lifting for Linux already. > > Is there a licensing problem in getting their work > onto Open > Solaris for x64/x86? The most bizzarre part is the fact that Linux drivers are completely incompatible with Solaris. One couldn't even port them without actually rewriting them from the ground up. It would seem that people who want Solaris to be GPL and use Linux drivers issue as an argument aren't even aware of this fact. Perplexing. And the fact that to integrate them properly ( ie without effectively killing the CDDL part of opensolaris), they would also have to be dual licensed nacho ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
> I think that maybe x86 *is* the main area where we > need help > from device driver writers who have done the > compatibility > heavy lifting for Linux already. > > Is there a licensing problem in getting their work > onto Open > Solaris for x64/x86? The most bizzarre part is the fact that Linux drivers are completely incompatible with Solaris. One couldn't even port them without actually rewriting them from the ground up. It would seem that people who want Solaris to be GPL and use Linux drivers issue as an argument aren't even aware of this fact. Perplexing. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
Alan Coopersmith <[EMAIL PROTECTED]> wrote: > Doug Scott wrote: > > Xorg, keeps on going and going. You exit firefox, and Xorg does not return > > the memory. > > Xorg uses standard UNIX malloc, so memory won't be returned to the OS upon > free, just to the free space list in the Xorg heap, unless it was a shared > memory pixmap that was attached to and later released. > > (Xsun has a hack to use mmap() for large pixmaps so that it can return memory > to the OS, but this hasn't been ported to Xorg.) I would like to see this hack ported to Xorg. With a vanilla Xorg, I need to restart X after ~ 3 Netscape blow up deads. With this hack: #!/bin/sh LD_PRELOAD=libmapmalloc.so /usr/X11/bin/Xorg.bin "$@" it lasts much longer, but X does not shrink as much after a netscape dead than it does with Xsun. Your hack would help a lot! Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
Quite right; I've watched firefox shoot up past 300MB VM usage when it really wasn't doing that much. And I've also seen both mozilla and firefox generate silly amounts of disk I/O simply because of animated GIFs being on a page. Doesn't matter who compiled it, or even whose libs (Sun's vs blastwave's) it's using... This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
Doug Scott wrote: Xorg, keeps on going and going. You exit firefox, and Xorg does not return the memory. Xorg uses standard UNIX malloc, so memory won't be returned to the OS upon free, just to the free space list in the Xorg heap, unless it was a shared memory pixmap that was attached to and later released. (Xsun has a hack to use mmap() for large pixmaps so that it can return memory to the OS, but this hasn't been ported to Xorg.) -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
> Few examples: > Linux+Gnome is much faster than Solaris+JDS on the > same AMD hardware. > JDS+Solaris needs more memory than Linux+Gnome (same > hardware). 512MB > are enough for Linux, Solaris starts swapping after a > few hours of > usage and doesn't stop until swap is full. JDS > doesn't grok Gnome > session files from Linux. > > Sure, this is s subjective. Let's ignore these > problems and add > more colorful branding to JDS. You know, I have what I believe to be a much better idea: let's ditch that Linux thing and start developing GNOME directly on Solaris. And once that is done, I bet those performance problems will "magically" go away! This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
> Few examples: > Linux+Gnome is much faster than Solaris+JDS on the > same AMD hardware. > JDS+Solaris needs more memory than Linux+Gnome (same > hardware). 512MB > are enough for Linux, Solaris starts swapping after a > few hours of > usage and doesn't stop until swap is full. JDS > doesn't grok Gnome > session files from Linux. Actually, I think that these are a bug within Gnome on Solaris rather than anything directly to do with JDS. I have seen all of the above. The main issue why Linux+Gnome is faster than Solaris+Gnome, comes down to the fact that Gnome is developed on Linux. Therefore Linux specific bugs get fixed much quicker. There is a simple test I have come up with, which shows there is some memory leakage. If you startup gnome, browse to http://research.sun.com:8080/SnappRadio/RadioParadise.html. Let the slideshow go for an hour or 2. You will see firefox uses memory up to a point. Xorg, keeps on going and going. You exit firefox, and Xorg does not return the memory. Try the same thing with opera, and everything behaves normally. I haven't had time to file a bug, or have a closer look, but there is a problem somewhere. Though I would not blame JDS for this. Doug > > Sure, this is s subjective. Let's ignore these > problems and add > more colorful branding to JDS. > > Josh > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
S Destika wrote: OSS people value it to no ends that for-profit organization should not be in sole control and dictatorship of any OSS project for simple reasons. And yet MySQL, Ubuntu, Fedora, and other high-profile OSS projects thrive in such environments, so it can't be universally true. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
[i]Firstly, your point about full control. The CAB is made up of 5 people. 2 from Sun, 2 from the pilot project, and 1 from the OSS community at large. That to me does not equate to full control or a dictatorship. I assume they aren't paying Rich :) [/i] For me,the problems of the control is not around the type or the number of CAB members but around methodology of decision or management about community projects.This is probably a more practical than formal issue.I saw great participation around the decision to start kde project and now around rewrite libc_i18n.a.This is a great tentative to start taking an identity.I'm shocked to see a numerous participation around GPLv3's issue.This isn't waste time but a democracy exercise,the foundation of a free community.I prefer to think that this community is born in these days. :-) This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
> If you continue to repeatedly miss the point it > becomes frustrating for me to repeat it over and > over. OSS people value it to no ends that for-profit > organization should not be in sole control and > dictatorship of any OSS project for simple reasons. > That simply cannot be a good thing - there is > something called conflict of interest - go read about > it - > http://en.wikipedia.org/wiki/Conflict_of_interest . I saw a lot of postings, and I did not want to miss out on the fun. So I though I would add to the ravings Sorry, I try to avoid wikipedia :) You will have to use your own words to make your point. Firstly, your point about full control. The CAB is made up of 5 people. 2 from Sun, 2 from the pilot project, and 1 from the OSS community at large. That to me does not equate to full control or a dictatorship. I assume they aren't paying Rich :) Your point about a "profit" company should not be in sole control of a OSS. I ask why??? The is nothing in the words "Open" "Source" "Software", which would say Sun is doing anything wrong. There are many examples of this happening and working well. Don't try to tell me that Red Hat aren't pulling Fedora's strings, Canonical - Ubuntu, Novell - OpenSUSE etc. I don't think it is fair to make Sun jump through hoops, others don't. Especially considering they have produced more OSS and OSH than all of the above added together with IBM and HP Is there more Sun could do to open up OpenSolaris to the community. Yeah sure. Does it keep me awake at nights. No... They have come along way with OpenSolaris in just over a year. Lets not lose sight of the progress, and die with the negative perceptions. I don't know of any other commercial product the size of OpenSolaris being changed to OSS by any other company. To add to that they have netbeans, openoffice, parts of the JES stack, Java etc. That is a lot of effort and pain for a company which has been up to recently been making losses, and reducing their workforce. Doug This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
Yes, I miss the point. I trust greed modified by even the least bit of long-term view (like not getting into legal trouble) in most cases far more than either idealism or community as a predictable motivator, because idealism has excused more harm than greed, and neighborhood busybodies have hurt more people than corporations. I also distrust those who distrust a for-profit organization that's doing _everything_it_said_it_would_ just because it's a for-profit organization. There are _already_ outsiders participating at all levels. If that's not good enough, too bad. At this time, I see no practical benefit from what you want except that it would make you and those who feel similarly perhaps _feel_ better; indeed, I suspect many would still find other excuses not to participate. Because when it comes down to it, regarding OpenSolaris, I trust what's been _done_ so far more than I trust either me or you. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
On 2/4/07, S Destika <[EMAIL PROTECTED]> wrote: http://en.wikipedia.org/wiki/Conflict_of_interest - Read on it please. I keep re-iterating the sole aim is to get rid of that and let the community act in their own interests. BTW community people are grown up adults and can decide what is best for them. for the record MySQL is on the same boat isn't it? but that hasnt stopped them from becoming a mainstream database among little projects nacho ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
http://en.wikipedia.org/wiki/Conflict_of_interest - Read on it please. I keep re-iterating the sole aim is to get rid of that and let the community act in their own interests. BTW community people are grown up adults and can decide what is best for them. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
If you continue to repeatedly miss the point it becomes frustrating for me to repeat it over and over. OSS people value it to no ends that for-profit organization should not be in sole control and dictatorship of any OSS project for simple reasons. That simply cannot be a good thing - there is something called conflict of interest - go read about it - http://en.wikipedia.org/wiki/Conflict_of_interest . This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
> Here is what I think should be done for the project > as a whole to succeed as a open source project > thriving on its own agendas, passion, direction and > innovation. > > Job #1 - Get rid of the conflict of interest > Sun wants to make certain changes by following > certain processes and community has other interests > and wants to do things their way. Sun cannot act in > community's interest solely and equally fairly > community must not be forced to act in Sun's > interests (whatever they may be and however noble the > cause). I don't work for Sun, but except for a bit of streamlining, some more progress on getting SCM out, and some few trusted non-Sun committers, I'm just fine with the process, and indeed have learned a few things from it (I hope). > The presence of conflict of interests is evident from > the tensions and uncertainty that the ksh93 > integration project has created. Tensions and uncertainty? Huh. I bet some internal stuff was at least as ugly, just that nobody ever got to see the details. And I think you're forgetting that it's also a learning experience for all participants, from which I'd expect future externally-initiated projects will benefit. > So create an independent OpenSolaris.org foundation > and let reasonable non-Sun people head and drive it. > (You want level headed folks here - not the hot head > techies.) > > Job #2 - Have the foundation create infrastructure, > processes and other things for setting up a platform > for people to collaborate. (Mailing lists, SCM, > Commit process, patch management, reviews, etc.) > > Let the community decide what is good and what is bad > for them. Let them define the processes. Let them > start and manage sub-projects based on meritocracy. > > Let the foundation have a source tree of their own > separate from Sun's. The idea is to let community > drive everything. Benefit will be that people will > feel ownership of the projects and the freedom to > make their own decisions without conflict of interest > and other bureaucracy will bring in lots of amazing > things. > > Job #3 - Establish a protocol for sharing and > collaborating between the foundation and Sun. > > This will include things such as open bug database > for the foundation which apart from being fed by the > community will also have a link from Sun's bug > database. Sun employees could for instance publish > the bugs they deem fit for the community to be able > to help with to the open bug database. No one gets > to live with a ridiculous bug database! > > Establish how and when code drops will occur from Sun > to the foundation and vice-versa. Sun can take the > changes from foundation code base as and when they > wish. Community can benefit from the changes that > happen within Sun. > > Idea is to build a bridge so things could flow to and > fro without stepping on each other's toes and without > generating conflicts. Sun can do whatever they want > to their code base and make it available at the end > of the day to the foundation. Community need not be > burdened with Sun's own processes and interests and > they can do what they like and care about. Sun can > still choose what community changes go in to their > code base and when. Of course Sun employees would > hang out on the foundation's mailing lists and have > their say and community would have a open dialogue > with them to sort things out so everyone benefits. > > I know this places a lot of burden and importance on > getting the bridge and protocols right and there may > be a little rework involved but in the end it is the > right thing to do. It will bring in lot more > contributors, lot more progress all at an amazing > pace. To your 2nd and 3rd points, while that's happening now in some sense (with the PowerPC port), I just don't _care_ who runs the show, as long as things get done. You don't think things are getting done fast enough, or that you have enough influence on how they get done. I think the pace at which they're getting done is generally improving, and am satisfied that _how_ they get done is mostly correct (and open to _constructive_ criticism, even if not necessarily with regard to who runs things). So I just don't see _anything_ you could do if things were different that you can't do _now_ if you actually _wanted_ to do more and talk less. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
> > > > > x86 hardware support has been steadily improving > over > > the last couple of > > years and the rate of improvement has accelerated > in > > the past year. I > > have only failed to install on one x64 system (and > I > > have done a lot of > > installs) and that was an HP DL380. > > > > So the answer is x86 hardware support is being > very > > actively fixed. > > Well - Sigh. I am saying that the rate at which > things (every thing where Sun doesn't have active > business interest but community can grow and benefit > from it) are improving is too excruciatingly slow > compared to what happens with other Open OSes and we > got to figure out a way to speed it up and the only > way is to involve the community actively. AFAIK, Sun doesn't _make_ any laptops (although I think they resell a Tadpole or somesuch). Yet there's been a lot of laptop support added (although there's still lots more to do). There is simply no way to look at each individual thing that's been done already and say it was only done to make $$ for Sun. Now obviously they want to make $$ somewhere, or they won't be around forever. But I think just maybe they've realized that mindshare now pays off in $$ later. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
On 2/4/07, S Destika <[EMAIL PROTECTED]> wrote: Here is what I think should be done for the project as a whole to succeed as a open source project thriving on its own agendas, passion, direction and innovation. Job #1 - Get rid of the conflict of interest Sun wants to make certain changes by following certain processes and community has other interests and wants to do things their way. Sun cannot act in community's interest solely and equally fairly community must not be forced to act in Sun's interests (whatever they may be and however noble the cause). Why do you think "the community" and "Sun" are separate? This is supposed to be a single community, with Sun being an inclusive member and having the same rights and privileges as anybody else. I don't think in terms of us and them, I think in terms of "we" - all, as one. The presence of conflict of interests is evident from the tensions and uncertainty that the ksh93 integration project has created. So create an independent OpenSolaris.org foundation and let reasonable non-Sun people head and drive it. (You want level headed folks here - not the hot head techies.) So you're suggesteing that Sun be deliberately excluded from any input into the direction of OpenSolaris, despite the fact that it is Sun who gave us the code in the first place, are responsible for the financial and personnel resources sustaining it, and are - currently - the main consumer? Sorry, but people from Sun mustn't be excluded from the processes. Job #2 - Have the foundation create infrastructure, processes and other things for setting up a platform for people to collaborate. (Mailing lists, SCM, Commit process, patch management, reviews, etc.) Why do you insist on having an external entity create a closed system that duplicates what we already have, when the intention is that the current system is opened to *all*? And note that there is NOTHING WHATSOEVER to prevent you - or anybody else for that matter from doing this. It's one of the fundamental principles of open source that anyone can fork the code and create their community around it if they wish. If you want to do this, go right ahead, rool up your sleeves, and get on with it. Let the community decide what is good and what is bad for them. Let them define the processes. Let them start and manage sub-projects based on meritocracy. The community does. That's exactly how it works now. Anyone can propose a project. Sun and external members equally. The project creation process is deliberately lightweight so as to impose no barriers to entry. There is still a grey area here that needs to be resolved, in that there is no guaranteed right to integrate. There will be projects that certain sections of the wider comunity feel are important that Sun are unable to accept (and I would expect their reasons to be entirely valid) as part of Solaris proper, and we need to find a way to deal with that. Let the foundation have a source tree of their own separate from Sun's. The idea is to let community drive everything. Benefit will be that people will feel ownership of the projects and the freedom to make their own decisions without conflict of interest and other bureaucracy will bring in lots of amazing things. Why enforce separation and exclude Sun from their own source code? We're trying to build an all-inclusive community here, and bring down the barriers, not erect new walls that prevent people from contributing. Job #3 - Establish a protocol for sharing and collaborating between the foundation and Sun. Why bother? Why require two organizations and a load of bureaucratic and process complexity between the two when we can have a single open organization and just get on with the job of making the product better? This will include things such as open bug database for the foundation which apart from being fed by the community will also have a link from Sun's bug database. Sun employees could for instance publish the bugs they deem fit for the community to be able to help with to the open bug database. No one gets to live with a ridiculous bug database! No, you're suggesting we have two incompatible bug databases, which just makes matters worse. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
UNIX admin wrote: Job #2 - Have the foundation create infrastructure, processes and other things for setting up a platform for people to collaborate. (Mailing lists, SCM, Commit process, patch management, reviews, etc.) But that's exactly what's being worked on. What do you think the whole SCM switch from Teamware to Mercurial is? That's only for OpenSolaris - Solaris retains the internal mechanisms. That isn't true. The plan is for everyone to use the same gate, the same SCM. That's a large part of why the work is taking so long. It's not setting up a new system for new people, it's migrating a very large number of existing people and tools to a new (and substantially different) system. It's also worth noting that while people keeping saying that the SCM "isn't there", it *IS* there for two consolidations (JDS and the CCD) both of whom have their live, one-and-only, real gate on opensolaris.org, on the outside, visible to all. -- Rich ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
> Job #2 - Have the foundation create infrastructure, > processes and other things for setting up a platform > for people to collaborate. (Mailing lists, SCM, > Commit process, patch management, reviews, etc.) But that's exactly what's being worked on. What do you think the whole SCM switch from Teamware to Mercurial is? That's only for OpenSolaris - Solaris retains the internal mechanisms. > Let the community decide what is good and what is bad > for them. Let them define the processes. Let them > start and manage sub-projects based on meritocracy. Isn't that what we're doing? Or is your problem actually with the fact that OpenSolaris is being protected from "make it look and behave like Linux at the expense of compatibility" changes? > Let the foundation have a source tree of their own > separate from Sun's. The idea is to let community > drive everything. Benefit will be that people will > feel ownership of the projects and the freedom to > make their own decisions without conflict of interest > and other bureaucracy will bring in lots of amazing > things. But it does -- OpenSolaris is separate from Solaris. And the CAB does drive OpenSolaris. Yes, the fact is that lots of people in the community are Sun engineers, but we actually need them to head the effort -- there are extremely few people outside of Sun that know the product well enough to be able to effectively contribute. > This will include things such as open bug database > for the foundation which apart from being fed by the > community will also have a link from Sun's bug > database. Sun employees could for instance publish > the bugs they deem fit for the community to be able > to help with to the open bug database. No one gets > to live with a ridiculous bug database! That's exactly how it works right now. What exactly are your issues with the current bug database? Do you have any concrete suggestions? "A rediculous bug database" doesn't actually detail what your issue with her (the database) is. I know that I've been involved in several cases where I've made suggestions and those were either filed *for me* as RFEs (I didn't feel competent enough to work on them myself), or the people from the community got involved and solicited me for more feedback. And most of the suggestions I've made so far have either been accepted and will be implemented, and some of those I will be implementing myself. I've even made arrangements for a sponsor. I'm still unclear on whether you actually tried to contribute to OpenSolaris, and whether or not you have any code contributions and fixes. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
> I'd be pleased to hear your process suggestions, but > I'm afraid a > process of some sort is inevitable. All non-trivial > FOSS communities > have a process that ensures commits are only made by > people the > community trusts. > That's right. No one (that includes me) here is saying allow commits from everyone no matter what. I think that impression has been created by people to ignore the other real heart burning issues. Currently I think Sun is getting bogged down with having to do everything including taking decisions on behalf of the community. I don't think that should be the job of a for-profit organization. We clearly have a case of misplaced responsibilities here. And there open source projects that work this way. SuSE, Redhat do not act on community's behalf. Community does their things and RedHat and SuSe share and collaborate with them without imposing any structure or decisions of their own onto the community. There is also an dictatorship (Sun controls and they are here with business interest which may not necessarily be the same as community's) vs. Democracy (community controls everything and everyone benefits) analogy here but that would be going a little too far. Here is what I think should be done for the project as a whole to succeed as a open source project thriving on its own agendas, passion, direction and innovation. Job #1 - Get rid of the conflict of interest Sun wants to make certain changes by following certain processes and community has other interests and wants to do things their way. Sun cannot act in community's interest solely and equally fairly community must not be forced to act in Sun's interests (whatever they may be and however noble the cause). The presence of conflict of interests is evident from the tensions and uncertainty that the ksh93 integration project has created. So create an independent OpenSolaris.org foundation and let reasonable non-Sun people head and drive it. (You want level headed folks here - not the hot head techies.) Job #2 - Have the foundation create infrastructure, processes and other things for setting up a platform for people to collaborate. (Mailing lists, SCM, Commit process, patch management, reviews, etc.) Let the community decide what is good and what is bad for them. Let them define the processes. Let them start and manage sub-projects based on meritocracy. Let the foundation have a source tree of their own separate from Sun's. The idea is to let community drive everything. Benefit will be that people will feel ownership of the projects and the freedom to make their own decisions without conflict of interest and other bureaucracy will bring in lots of amazing things. Job #3 - Establish a protocol for sharing and collaborating between the foundation and Sun. This will include things such as open bug database for the foundation which apart from being fed by the community will also have a link from Sun's bug database. Sun employees could for instance publish the bugs they deem fit for the community to be able to help with to the open bug database. No one gets to live with a ridiculous bug database! Establish how and when code drops will occur from Sun to the foundation and vice-versa. Sun can take the changes from foundation code base as and when they wish. Community can benefit from the changes that happen within Sun. Idea is to build a bridge so things could flow to and fro without stepping on each other's toes and without generating conflicts. Sun can do whatever they want to their code base and make it available at the end of the day to the foundation. Community need not be burdened with Sun's own processes and interests and they can do what they like and care about. Sun can still choose what community changes go in to their code base and when. Of course Sun employees would hang out on the foundation's mailing lists and have their say and community would have a open dialogue with them to sort things out so everyone benefits. I know this places a lot of burden and importance on getting the bridge and protocols right and there may be a little rework involved but in the end it is the right thing to do. It will bring in lot more contributors, lot more progress all at an amazing pace. I am tired atm - it's possible I wrote something which is not clear enough - I am open for a discussion on this, tomorrow! This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
S Destika wrote: >As I said I tried on 8 different boxes without luck. I don't even have any >place to (except paid Sun support which I cannot afford) ask for help. (I >analyzed where the issues posted on these forums go and didn't feel like it >would help me posting here. Same goes with bug reports.) > > > You never did detail the "8 different boxes". Your analysis is flawed, there's always plenty of help with hardware issues either here or more often on the [EMAIL PROTECTED] alias. Ian. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
On 2/3/07, S Destika <[EMAIL PROTECTED]> wrote: As I said I tried on 8 different boxes without luck. I don't even have any place to (except paid Sun support which I cannot afford) ask for help. (I analyzed where the issues posted on these forums go and didn't feel like it would help me posting here. Same goes with bug reports.) sorry to hear that, neither of these boxes actually booted? have you run the Sun Device Detection Tool[1]? if you need help with solaris there is #opensolaris and #solaris in freenode (irc) and there are lots and lots of mailing lists including those in opensolaris.org you can always submit a bug report or rfc about your problem, the opensolaris community is trying hard to solve issues and it has improved significantly in many ways, people are running nexenta and other distros in their laptops these days, we also have a modern gnome desktop that matches any linux offering but we dont have a crystal ball we cannot know whether there is a problem or not with a device if there is no user complaining about it, and there is no reason to invest time ( remember time = money) in a device when there is no user demand nacho [1] http://www.sun.com/bigadmin/hcl/hcts/device_detect.html ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
As I said I tried on 8 different boxes without luck. I don't even have any place to (except paid Sun support which I cannot afford) ask for help. (I analyzed where the issues posted on these forums go and didn't feel like it would help me posting here. Same goes with bug reports.) This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
Dennis Clarke wrote: >>The client was consolidating all their old windows boxes on a couple of >>8 core Opteron boxes with VMWare ESX, so we just built a Solaris virtual >>machine and ran with that. Cop out, but pragmatic! >> >> > >How did you get past the insane costs ? > > > They're a windows shop, which probably says it all. If you want virtualisation and windows, you have to pay through the nose. Ian ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
> Bob Palowoda wrote: > >>>x86 hardware support has been steadily improving over >>>the last couple of >>>years and the rate of improvement has accelerated in >>>the past year. I >>>have only failed to install on one x64 system (and I >>>have done a lot of >>>installs) and that was an HP DL380. >>> >>>So the answer is x86 hardware support is being very >>>actively fixed. >>> >>> >>> >> >> Just for those who don't know. What was the fix for the HP DL380? >> >> >> > The client was consolidating all their old windows boxes on a couple of > 8 core Opteron boxes with VMWare ESX, so we just built a Solaris virtual > machine and ran with that. Cop out, but pragmatic! How did you get past the insane costs ? Dennis Clarke ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
Bob Palowoda wrote: >>> >>> >>x86 hardware support has been steadily improving over >>the last couple of >>years and the rate of improvement has accelerated in >>the past year. I >>have only failed to install on one x64 system (and I >>have done a lot of >>installs) and that was an HP DL380. >> >>So the answer is x86 hardware support is being very >>actively fixed. >> >> >> > > Just for those who don't know. What was the fix for the HP DL380? > > > The client was consolidating all their old windows boxes on a couple of 8 core Opteron boxes with VMWare ESX, so we just built a Solaris virtual machine and ran with that. Cop out, but pragmatic! Ian ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
> S Destika wrote: > > >>Do you have a specific device that is really > >>preventing you from using > >>Solaris/OpenSolaris? > >> > >> > > > >About 8 different x86/64 boxes - and I am not alone > by any means. Only place where it works reasonably is > VMware. Has Sun any interest in fixing x86 hardware > support? When? If there is genuine interest in fixing > this I can file bug reports. You lost one community > member - Sun won't fix x86 h/w support and community > is not even expected to fix it. > > > > > > > > > x86 hardware support has been steadily improving over > the last couple of > years and the rate of improvement has accelerated in > the past year. I > have only failed to install on one x64 system (and I > have done a lot of > installs) and that was an HP DL380. > > So the answer is x86 hardware support is being very > actively fixed. > Just for those who don't know. What was the fix for the HP DL380? ---Bob This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Re: Re: Community participation (was GPLv3 ravings)
> > > x86 hardware support has been steadily improving over > the last couple of > years and the rate of improvement has accelerated in > the past year. I > have only failed to install on one x64 system (and I > have done a lot of > installs) and that was an HP DL380. > > So the answer is x86 hardware support is being very > actively fixed. Well - Sigh. I am saying that the rate at which things (every thing where Sun doesn't have active business interest but community can grow and benefit from it) are improving is too excruciatingly slow compared to what happens with other Open OSes and we got to figure out a way to speed it up and the only way is to involve the community actively. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
