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 -- marketing mailing list marketing@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/marketing
