On 30/06/07, Alberto Ruiz <[EMAIL PROTECTED]> wrote:
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
It is? Maybe to you, perhaps, or a few others. However, most of the
world runs Windows, etc. so obviously they don't care about "open
source" that much.
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.
Unless those closed bits are necessary to ensure certain functionality
works out-of-the-box.
The excuse of, "sorry, you're going to have a slow, crappy
unaccelerated video in X until you install this other driver because
our ideas and philosophy don't allow us to redistribute it" sounds
really pathetic.
> 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
Yes, it is hypothetical. It is also unproven.
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.
Yes, there was a lot of pressure. However, they did not do it, did
they? And what was the reason? The users. They are the most important,
not philosophy.
I would theorise that most of that pressure was merely because of
Ubuntu's association with Debian.
There was also a lot of pressure to *not* give into the demands of not
including these bits from people that just wanted to use their system.
It does go both ways...
--
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
_______________________________________________
indiana-discuss mailing list
[email protected]
http://opensolaris.org/mailman/listinfo/indiana-discuss
