2007/6/30, Shawn Walker <[EMAIL PROTECTED]>:
On 29/06/07, Alberto Ruiz <[EMAIL PROTECTED]> wrote: > 2007/6/30, Alan Coopersmith <[EMAIL PROTECTED]>: > > Alan Coopersmith wrote: > > > So, now that I've bored everyone to sleep, this leaves us with these > > > possibilities for Indiana on SPARC: > > > > > > 1) Ship Xsun binaries & existing SPARC Xsun driver binaries (all closed > > > source) > > > > > > 2) Ship Xorg & use Martux's SPARC graphics drivers (all open source) > > > with existing SPARC kernel driver binaries (all closed source) > > > > There is also a third choice I forgot to mention, probably since it's > > the least desirable of all: > > > > 3) Ship Xorg with only the drivers provided by SPARC graphics (of which > > only XVR-2500 is likely to be done by your October proposed timeline), > > and leave those with older SPARCs unable to run X in Indiana. > > > > Also, Garrett reminded me of another issue in a message to ogb-discuss [1] > > - my prior description only covered 2D graphics, and ignored OpenGL. For > > OpenGL, a similar choice will have to be made: > > > > 1) Ship existing SPARC OpenGL, with accelerated modules for existing > > SPARC graphics cards (closed source - and I don't know if it's > > redistributable) - with Xsun, this has acceleration for most of the > > mid-to-high end SPARC graphics cards, with Xorg, only XVR-2500 is > > known to have usable hardware acceleration - I don't know if the > > others will easily work with Xorg or not once the framework is in > place. > > > > 2) Ship open source Mesa OpenGL, as we do on x86 (and virtually all other > > open source OS'es do), accepting that we'll have no hardware > acceleration > > and break compatibility with existing SPARC OpenGL applications > > > I think that keeping the opensource flag on indiana is more important. > However, (as pointed in a recent mail in other thread), we can focus on make > the retrieving through internet of those binary bits rocking easy after live > session or install. Does this idea make sense? More important than giving users fully working hardware out of the box? That doesn't seem reasonable. Users don't care about "open source," they care about supported, working hardware.
Yes, it is more important that the work that we do, don't depend on closed source bits. If we deliver closed source bits, derivative distributions will have problems. However, note that I pointed, that whenever a closed source bit is needed, it should be easy to install, but I think that we should keep the closed source bits as far as the main distribution as possible. If the "open" option is fully functional and supported, sure, it can
be used in place of the other. But as long as there is a better, redistributable option, that's the one we should be using to give the user the best experience possible "out-of-the-box."
I've already said that, for instance, flash plugin should be easy to be retrieved online and installed on demand, the same applies to the JRE if we cannot get something like IcedTea in the distribution. I'm not saying that we shouldn't allow closed source bits in the distribution, I'm saying, that we should not ship them in the default distribution (CD, DVD, whatever), since that would stop others to reuse our work. The same applies to closed codecs, but there are simple workarounds. This is not an hypothetical situation, the freedom of redistribution is a key value for lots of people out there, not only philosophical, but practical. As an example, there's been a lot of pressure to remove the closed source bits on ubuntu, that were included with the same rationale as you "users care about functionality", well, it happened that the most successful distribution in the average joe target space, has been the most controversial. Sometimes, normal users, do care. --
Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ "Beware of bugs in the above code; I have only proved it correct, not tried it. " --Donald Knuth
-- Un saludo, Alberto Ruiz
_______________________________________________ indiana-discuss mailing list [email protected] http://opensolaris.org/mailman/listinfo/indiana-discuss
