8:21 a.m.
On 05/19/2010 11:39 AM, Chris wrote:
http://fedoraproject.org/wiki/User_base
I think it's fantastic Fedora has that page, it's a great example of
the projects transparency. The main concern I tried to convey in the
review, is I'm concerned Fedora has a unique kind of new Linux user
finding them. This user, who just for this example, is someone who's
maybe a IT guy who just got tasked with a bunch of RHEL servers and
wants to jump into Desktop Linux to learn. He's going to search for
Red Hat's desktop Linux, and eventually will come to find the Fedora
project. His first impressions of Fedora will be his impressions of
desktop Linux. So whatever Fedora gets right, or wrong, has a very
specific type of important new eye looking at it - despite what the
project's personal user base target might be.
As you are already aware, Red Hat does invest very heavily on desktop
technologies and has a Red Hat Desktop product. While Red Hat as a
sponsor of the Fedora has significant influence, Fedora a project can
and does have different goals from Red Hat and with the help of
governing communities like the Fedora Board has set its own direction.
We are transparent about our goals and focus which is different from
being a end user desktop product. We are focussed on free and open
source software. Aside from that, the legal restrictions around being a
US based entity involves having to deal with the unfortunate situation
of software patents. Taking all this into consideration, I think it
would be better to hold us up against what we focus on and evaluate how
well we do. Not every distribution has the same focus and goals and we
cannot fit a square peg into a round hole. I personally use Fedora as
my desktop for the last several but us technical users of course have
different expectations from a typical consumer. One of the things, that
came up in your show and something that the desktop team has discussed
is including some content by default on the desktop so it is even more
obvious what we do and do not do within Fedora.
Totally makes sense, and I think we said as much on the show about
it
being a Live CD. Our focus on Btrfs is because that's what
the audience is very excited about, that's what desktop Linux really
care about. It's what Fedora 13 is going to be known for. At least
until the version of Fedora that ships with it as the default. :-)
Btrfs being the default is some ways away. Red Hat has a full time
developer working on stabilizing the filesystem and we will get there
when it is ready. Meanwhile, we have been working on several features
related to Btrfs. I recommend downloading a non-live image, passing
btrfs as a option during installation and try it out. Take a look at
the yum plugin we have included as well. More details at
https://fedoraproject.org/wiki/Btrfs_in_Fedora_13. I look forward to a
review on that.
I do, and it looks good. I still find telling your users to go Google
their problem is a bit tacky. It seems to come from a inherent bias
against even wanting to support or enable the user to acquire the
codecs on their own terms. I find it so odd when a brilliant community
all about openness, self starting, and sharing acts this way. In my
view, your making a platform to enable them to create and enjoy
content on their computer as part of a normal function of a desktop
system.
I'm not even saying you must do more, I think a link to the FAQ, and
the third party repos (sans that warning you axed) is sufficient. I
think you -could- do more if you really wanted to, ala give CodecBuddy
some love and better integration with media apps, etc etc.
I will have to ask Linux Action Show to assume good will on our part.
We of course want to help users and replaced Codec Buddy with a
distribution independent PackageKit codec plugin that uses Gstreamer to
find and enable codecs. If you enable a repo with additional codecs,
PackageKit will find it with the right integration in place but enabling
additional repos is NOT a technical problem. It is a legal issue. Red
Hat being a successful and profitable US entity is subject to certain
restrictions and higher risks that other distributions might not have.
As I already explained in the software patents page, we simply cannot
link to third party codecs and provide specific details. Our legal team
tells us that we might face contributory infringement charges and just
cannot take that risk. I am not a lawyer and cannot talk on behalf of
Red Hat but you would note that this risk is not theoretical anymore.
Red Hat only a couple of weeks back won a patent case filed against it
after years of fighting through court. If we can do anything more, we
certainly will. Now that I have explained the limitations we have, I
hope you read the page completely and let us know if you have any
suggestions on what we can do better.
That's really cool, I'd love to cover that on LAS, I'll
starting
following that asap. I noticed the mock ups and demos were down, I'd
love to have a chance to see those.
The project was dormant for quite sometime and it has picked up some
interest recently. The basic idea is that package installation is
different from application installation and we need to provide different
interfaces to cover different use cases. PackageKit currently has a
pretty good interface for managing packages but not so much for handling
applications and Richard Hughes from Red Hat, developer of PackageKit is
working on a different UI for that. One big benefit from our work on
this is that whatever we do on top of PackageKit will remain
distribution independent and can be easily adopted by other
distributions. That's one of the things we place a high value on.
Thank you, if it's ok with you, will cover your points on the
next
episode.
Absolutely. If you have questions or concerns before the next show and
need some answers, do feel free to get in touch with me or press AT
fedoraproject.org anytime.
Rahul