Hi All,
I don't know if this has been posted on the list or not but situations like this need to be looked at because it can only hinder the progress of Fedora over time unfortunately.
http://distrocenter.linux.com/distrocenter/05/07/11/2327245.shtml?tid=107&am...
On Tue, 2005-07-19 at 09:15 +0800, Marc Wiriadisastra wrote:
Hi All,
I don't know if this has been posted on the list or not but situations like this need to be looked at because it can only hinder the progress of Fedora over time unfortunately.
http://distrocenter.linux.com/distrocenter/05/07/11/2327245.shtml?tid=107&am...
I don't think this has been posted, and we definitely appreciate postings to this list of all review of Fedora. Rahul, for one, takes the effort to contact writers and set them straight on the facts.
I can see what directions in that article I think need correction. I'm curious what you see?
* Worrying about OOo being beta. FC is specifically cutting edge. Mincing words about beta in a release is contrary to the spirit and history of highly advancing open source. Beta and release are subjective terms.
"While I've had no problems with it and no crashes, a beta release in what is considered to be a stable operating system feels out of place."
* Totally not understanding the story behind patent infringing technologies.
"Worse, Fedora Core 4 gets low marks for multimedia. I encountered an overwhelming number of bugs in this area. There is no support for proprietary formats such as Windows Media, DVD, and MP3, though having used past Red Hat/Fedora releases, I would expect nothing more. Previously, enabling these multimedia types was not a hard task, but this time, it's daunting."
* Not even attempting to understand the difference between what is in the distro and what is supplied by other repositories:
"I tried enabling these proprietary media files the same way I did this in previous Fedora releases, which was to install Apt4RPM, a great package management tool, and use that to install the necessary packages. That worked in previous Fedora releases, but not in Fedora Core 4."
All in all, a very annoying read. Thanks for sharing with us. :)
- Karsten
Hi All,
Although that was fairly constructive in relation to adding the wiki in the browsers for further clarification and helping out new users to links and the like could we possibly add fedora forum and maybe fedora faq. The only problem that might happen with adding those is that they suggest multimedia support and that might go against the grain of fedora or what fedora stands for.
I think Karsten listed all the major ones that I read and I thought that weren't right.
I installed FC4 and had no issues in fact I think its a major improvement granted there are bugs but being bleeding edge was the reason for me getting involved with fedora. I wonder whether he filled bug reports?
IMO most of the complaints centred around multimedia which I managed to get going very quickly anyway in my install. He's trying apt compared to yum albeit it worked before but the repositories take time to update for apt. Compared to yum which updates rapidly.
Also I believe the majority of apt repositories are NOT fedora-extras or the 'genuine' fedora repository correct me if I'm wrong.
The problem is this is a linux guy that has spread FUD and I'm not sure how many people believe him so I'm wondering how many people /won't/ try fedora because of this. Its hard enough facing other OS FUD let alone facing it from inside. I'm assuming that its a fine line between honest criticism and actual misinformation.
IMO as well is that articles like this need to be dealt with in some way by the 'marketing' group so that as a group we can progress towards people knowing exactly what fedora is and isn't. The long term users understand, but the new users don't understand and they would be reading articles like this and saying well thats a buggy os I'm definately not trying it now.
I don't feel that we want Fedora to become an experienced user distro because fresh blood is great for finding bugs as well as putting genuine ideas forward that people maybe have not considered.
On Tue, Jul 19, 2005 at 12:40:50PM +0800, Marc Wiriadisastra wrote:
The problem is this is a linux guy that has spread FUD and I'm not sure how many people believe him so I'm wondering how many people /won't/ try
Let's keep our own labels correct. This article doesn't appear to be FUD (which is by definition a malicious underhanded tactic) but rather an honest but somewhat ill-informed review.
fedora because of this. Its hard enough facing other OS FUD let alone facing it from inside. I'm assuming that its a fine line between honest criticism and actual misinformation.
Sure -- and both of those things are still on this side of the big line marked "FUD". :)
IMO as well is that articles like this need to be dealt with in some way by the 'marketing' group so that as a group we can progress towards people knowing exactly what fedora is and isn't. The long term users understand,
It's also important that articles like this are "dealt with" not just by "correcting" the reviewer -- it's also important to take a honest look at any *real* problems that are exposed, even if the complaint doesn't feel fair at first to an insider. For example, the gripe about OpenOffice warning that it's a beta version with no obvious explanation.....
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Marc Wiriadisastra wrote:
I don't know if this has been posted on the list or not but situations like this need to be looked at because it can only hinder the progress of Fedora over time unfortunately.
http://distrocenter.linux.com/distrocenter/05/07/11/2327245.shtml?tid=107&am...
If you mean the following:
<quote>
Worse, Fedora Core 4 gets low marks for multimedia.
</quote>
Most of them would be answered here:
http://fedoraproject.org/wiki/ForbiddenItems
Rgds SM
Sankarshan Mukhopadhay wrote:
Marc Wiriadisastra wrote:
I don't know if this has been posted on the list or not but situations like this need to be looked at because it can only hinder the progress of Fedora over time unfortunately.
http://distrocenter.linux.com/distrocenter/05/07/11/2327245.shtml?tid=107&am...
If you mean the following:
<quote>
Worse, Fedora Core 4 gets low marks for multimedia.
</quote>
Most of them would be answered here:
But obviously they weren't answered for the review author. So there is a problem in our getting the message out. What good is the wiki if its not helping our users?
On Tue, Jul 19, 2005 at 12:08:22AM -0400, Christopher Aillon wrote:
But obviously they weren't answered for the review author. So there is a problem in our getting the message out. What good is the wiki if its not helping our users?
Hmmm -- the default firefox bookmarks in uptates/testing/3 seem to still be "Red Hat, Inc.", "Red Hat Network", "Red Hat Linux Documentation", etc.
Maybe the Fedora Wiki could be there instead?
On Tue, Jul 19, 2005 at 12:16:14AM -0400, Matthew Miller wrote:
But obviously they weren't answered for the review author. So there is a problem in our getting the message out. What good is the wiki if its not helping our users?
Hmmm -- the default firefox bookmarks in uptates/testing/3 seem to still be "Red Hat, Inc.", "Red Hat Network", "Red Hat Linux Documentation", etc. Maybe the Fedora Wiki could be there instead?
PS: serious suggestion, not just being a smartass because you're the maintainer of that package. :)
On Tue, 2005-07-19 at 00:21 -0400, Matthew Miller wrote:
On Tue, Jul 19, 2005 at 12:16:14AM -0400, Matthew Miller wrote:
But obviously they weren't answered for the review author. So there is a problem in our getting the message out. What good is the wiki if its not helping our users?
Hmmm -- the default firefox bookmarks in uptates/testing/3 seem to still be "Red Hat, Inc.", "Red Hat Network", "Red Hat Linux Documentation", etc. Maybe the Fedora Wiki could be there instead?
PS: serious suggestion, not just being a smartass because you're the maintainer of that package. :)
It's a good suggestion.
AFAIK, we are now clear to link to fedorafaq.org and other sites that themselves link to information that is non-free or possibly infringing on patents. We cannot link directly to such possibly-infringing sites.
For these bookmarks, here are a few I'd add. Matt, do you want to file the RFE? :)
fedorafaq.org fedorausers.org fedoralinks.org fedora.redhat.com/docs fedoraproject.org/wiki fedoraproject.org/wiki/ForbiddenItems
On 07/19/2005 12:16 AM, Matthew Miller wrote:
On Tue, Jul 19, 2005 at 12:08:22AM -0400, Christopher Aillon wrote:
But obviously they weren't answered for the review author. So there is a problem in our getting the message out. What good is the wiki if its not helping our users?
Hmmm -- the default firefox bookmarks in uptates/testing/3 seem to still be "Red Hat, Inc.", "Red Hat Network", "Red Hat Linux Documentation", etc.
Maybe the Fedora Wiki could be there instead?
I've actually been considering this for a bit. It's probably too late for FC3 and FC4 (default installs will have the current default, and updates won't fix that.). We can do it for FC5 though, but I'd like to see it done in one shot rather than change a bookmark here, a bookmark there.... I'm not sure I want to get into suggestion war over this, either. I'll probably attempt to come up with a reasonable set of defaults one of these days with a few people and stick it in the rawhide packages.
On Tue, 19 Jul 2005, Christopher Aillon wrote:
But obviously they weren't answered for the review author. So there is a problem in our getting the message out. What good is the wiki if its not helping our users?
Um, it's helping our developers?
I will agree that we need to do a better of job at answering questions like "why doesn't Fedora do this or that?" and getting the word out. But the wiki is not necessarily the place to do that.
===
That said:
We've been arguing a lot about "what's our mission?" And that mission, in a nutshell, is "to communicate important information about Fedora to users."
Here's some pretty important information:
* Fedora is cutting-edge, because it's the best way to innovate. * Fedora is patent-free, because it's the RIGHT thing to do.
Specifically when it comes to the second message, I think we need to promote the idea AGGRESSIVELY. For instance:
"No audio? Funny, there's an ogg player in Fedora, and I play audio just fine with it. Why aren't you using it? Oh, because you're paying lip service to the importance of open standards? Ah, well then. I suppose if you have to have your mp3s, we'll never get anywhere as a community, now will we?"
Of course, it's better if we can boil that down to a sentence. How's this for some sloganeering? They'd make good bumperstickers:
* FEDORA: PATENT-FREE SINCE 2003. * MAKE OGG, NOT MP3. * IF YOU DON'T BELIEVE IN SOFTWARE PATENTS, DON'T USE PATENTED SOFTWARE.
People won't get it until we hit them over the head with it.
--g
_____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan
On 7/19/05, Greg DeKoenigsberg gdk@redhat.com wrote:
I will agree that we need to do a better of job at answering questions like "why doesn't Fedora do this or that?" and getting the word out. But the wiki is not necessarily the place to do that.
I personally, as a person, think that reviewers would most benefit from a guided tour experience where the nicer or newer things are highlighted and the consistently more contraversial items like the lack of mp3 support are explained. Other very new users would of course benefit from such a guided tour. Think of it as our highlight reel. Provide access to the highlight reel on firstboot and later via a menu item. Being able to do this in a livecd format would make some sense as well as providing the guided tour experience in the standard desktop install.
I quick an dirty way to mock up some guided segments is to just come up with a top ten list of tasks that we think 90% of "reviewers" going to want to perform as part of their review process.. and then do a quick video capture segment of starting with a default gnome desktop and performing the task. Using a small text editor or sticky note pad window to type in text notes as you go. We've seen some developers do this in blog entries already.. i think you can do it to theora or svg, I know you can do it with flash but we cant depend on flash since we dont ship flash support...yet. You could of course go further and do semi-professional video editting with audio and translations, but as a first cut the video captures of a desktop in use with simple text notes in the video serves the purpose pretty well.
Of course, some reviewers LOVE to base their reviews on the final test release so they can have their review out on the day of the final release. Getting guided segments out soon enough to stick into the face of the first reviewers is going to be tough.
-jef
On Tue, 19 Jul 2005, Jeff Spaleta wrote:
I personally, as a person, think that reviewers would most benefit from a guided tour experience where the nicer or newer things are highlighted and the consistently more controversial items like the lack of mp3 support are explained. Other very new users would of course benefit from such a guided tour. Think of it as our highlight reel. Provide access to the highlight reel on firstboot and later via a menu item. Being able to do this in a livecd format would make some sense as well as providing the guided tour experience in the standard desktop install.
This is a good idea. Potentially resource-intensive, and complicated, to do it right.
--g
_____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan
On 7/19/05, Greg DeKoenigsberg gdk@redhat.com wrote:
This is a good idea. Potentially resource-intensive, and complicated, to do it right.
Isn't everything? And who says we have to do it perfectly right the first time? Doing audio or text overlay or any editting at all is going to complicate things sure... but maybe we don't "need" that to make a positive impact compared to where we are now. Are rough theora video captures of desktop tasks better than nothing? Are rough video captures "good enough"? Initially just sticking them on the website and having the release notes and the default browser page list the rough.. "community provided" walk-through theora videos for the top 10 tasks could be a benefit. And from there if people with video editting experience in the community can volunteer to do a more polished second generation...fine.
-jef"I've always found that magic bullets tend to be expensive"spaleta
On Tue, 19 Jul 2005, Jeff Spaleta wrote:
On 7/19/05, Greg DeKoenigsberg gdk@redhat.com wrote:
This is a good idea. Potentially resource-intensive, and complicated, to do it right.
Isn't everything? And who says we have to do it perfectly right the first time? Doing audio or text overlay or any editting at all is going to complicate things sure... but maybe we don't "need" that to make a positive impact compared to where we are now. Are rough theora video captures of desktop tasks better than nothing? Are rough video captures "good enough"?
In the particular case of *video*, I think the answer is "it depends." Because bad video can, in fact, be worse than no video (cf. "FUDCon1").
Note: I'm not saying that we couldn't or shouldn't try it. Does anyone within the sound of our voices have the chops for this?
--g
_____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan
On 7/19/05, Greg DeKoenigsberg gdk@redhat.com wrote:
In the particular case of *video*, I think the answer is "it depends." Because bad video can, in fact, be worse than no video (cf. "FUDCon1").
unlike fudcon.. we arent talking about setting a camera or additional hardware.. all the capture stuff that I'm talking about is done in software.. i think some of the technics essentially act as a vnc client to a vnc session.
grrr i can't remember which of the gnome developers had their little videos on their blog....
-jef
If there's precedent for this being done easily and well, then let's steal, steal, steal. :)
--g
_____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan
On Tue, 19 Jul 2005, Jeff Spaleta wrote:
On 7/19/05, Greg DeKoenigsberg gdk@redhat.com wrote:
In the particular case of *video*, I think the answer is "it depends." Because bad video can, in fact, be worse than no video (cf. "FUDCon1").
unlike fudcon.. we arent talking about setting a camera or additional hardware.. all the capture stuff that I'm talking about is done in software.. i think some of the technics essentially act as a vnc client to a vnc session.
grrr i can't remember which of the gnome developers had their little videos on their blog....
-jef
-- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-marketing-list
On 7/19/05, Greg DeKoenigsberg gdk@redhat.com wrote:
If there's precedent for this being done easily and well, then let's steal, steal, steal. :)
bah...crap.. davidz used a flash based capture in his blog http://blog.fubar.dk/?p=56
-jef
On 7/19/05, Greg DeKoenigsberg gdk@redhat.com wrote:
If there's precedent for this being done easily and well, then let's steal, steal, steal. :)
thomasvs to the recue!!!!!
instanbul which j5 has packaged.... and is trying to get it into extras now. http://people.redhat.com/johnp/istanbul/
it encodes into theora by default... its a little cpu intensive on the encoding so i hear.. but for this purpose... that does not matter. Its soon to be an in Fedora tool, which means its available to the entire community to use... and by using it to build task videos we provide feedback on performance and additional testing of the theora encoding. As soon as j5 actually gets this into extras is pretty much the "good enough" solution to play with.
I think j5 even had a blog entry showing how it works...but i cant find it at the moment.
-jef
I'm seeing a new HOWTO for the docs team... "HOWTO make a video tutorial for Fedora..."
--g
_____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan
On Tue, 19 Jul 2005, Jeff Spaleta wrote:
On 7/19/05, Greg DeKoenigsberg gdk@redhat.com wrote:
If there's precedent for this being done easily and well, then let's steal, steal, steal. :)
thomasvs to the recue!!!!!
instanbul which j5 has packaged.... and is trying to get it into extras now. http://people.redhat.com/johnp/istanbul/
it encodes into theora by default... its a little cpu intensive on the encoding so i hear.. but for this purpose... that does not matter. Its soon to be an in Fedora tool, which means its available to the entire community to use... and by using it to build task videos we provide feedback on performance and additional testing of the theora encoding. As soon as j5 actually gets this into extras is pretty much the "good enough" solution to play with.
I think j5 even had a blog entry showing how it works...but i cant find it at the moment.
-jef
On Tue, 2005-07-19 at 10:41 -0400, Greg DeKoenigsberg wrote:
On Tue, 19 Jul 2005, Jeff Spaleta wrote: In the particular case of *video*, I think the answer is "it depends." Because bad video can, in fact, be worse than no video (cf. "FUDCon1").
Note: I'm not saying that we couldn't or shouldn't try it. Does anyone within the sound of our voices have the chops for this?
--g
The latest VMware Workstation has the ability to make a "video capture" of a Virtual Machine. While I have not used this feature yet I will give it a try. I also have not done any Video editing in Linux, There is no time like now to make that happen.
On Tue, 2005-07-19 at 10:35 -0400, Jeff Spaleta wrote:
On 7/19/05, Greg DeKoenigsberg gdk@redhat.com wrote:
This is a good idea. Potentially resource-intensive, and complicated, to do it right.
-jef"I've always found that magic bullets tend to be expensive"spaleta
These screencasts have been added to the list of acceptable documentation formats for Fedora. We've been researching solutions for several weeks. Our basic idea was to supplement our docs with screencasts. However, this idea of having multiple screencasts available during firstboot is awesome.
BTW, this is not rocket science, but details need to be resolved in the FOSS side. Tech journalists do this all the time, using proprietary tools, so it's not that difficult. :)
- Karsten
On 7/19/05, Karsten Wade kwade@redhat.com wrote:
BTW, this is not rocket science, but details need to be resolved in the FOSS side.
ive got istanbul building and installing on my smp rawhide box now, with minor modifications to j5's current spec file. Can't test it till i get home, but assuming it works I can post some examples of theora videos tomorrow. Name 3 specific tasks you'd like to see mockup theora videos created by istanbul.
-jef
On Tue, 2005-07-19 at 14:12 -0400, Jeff Spaleta wrote:
On 7/19/05, Karsten Wade kwade@redhat.com wrote:
BTW, this is not rocket science, but details need to be resolved in the FOSS side.
ive got istanbul building and installing on my smp rawhide box now, with minor modifications to j5's current spec file. Can't test it till i get home, but assuming it works I can post some examples of theora videos tomorrow. Name 3 specific tasks you'd like to see mockup theora videos created by istanbul.
1. Making MP3s play in XMMS
Just kidding!
I'll add this topic to the FDSCo meeting agenda for today (4 pm EDT), to see if anyone has any favorites there, and will post them back here.
- Karsten
On Tue, 2005-07-19 at 11:32 -0700, Karsten Wade wrote:
On Tue, 2005-07-19 at 14:12 -0400, Jeff Spaleta wrote:
On 7/19/05, Karsten Wade kwade@redhat.com wrote:
BTW, this is not rocket science, but details need to be resolved in the FOSS side.
ive got istanbul building and installing on my smp rawhide box now, with minor modifications to j5's current spec file. Can't test it till i get home, but assuming it works I can post some examples of theora videos tomorrow. Name 3 specific tasks you'd like to see mockup theora videos created by istanbul.
- Making MP3s play in XMMS
Just kidding!
/me runs away, gibbering and tearing out hair... :-D
What about a screencast of (1) navigating to, and (2) putting shortcuts to, good sources for official Fedora info? See previous thread on what's OK to link. This seems ludicrous unless you remember the "general user" category (*cough cough* f-devel-l thread o' doom *cough*).
On Tue, 19 Jul 2005 14:37:27 -0400, "Paul W. Frields" stickster@gmail.com said:
On Tue, 2005-07-19 at 11:32 -0700, Karsten Wade wrote:
On Tue, 2005-07-19 at 14:12 -0400, Jeff Spaleta wrote:
On 7/19/05, Karsten Wade kwade@redhat.com wrote:
BTW, this is not rocket science, but details need to be resolved in the FOSS side.
ive got istanbul building and installing on my smp rawhide box now, with minor modifications to j5's current spec file. Can't test it till i get home, but assuming it works I can post some examples of theora videos tomorrow. Name 3 specific tasks you'd like to see mockup theora videos created by istanbul.
Configuring the update applet is fairly common and easy task, since it doesn't have many decision points - you can basically just click "Next" if you don't have a proxy server. --
Stuart Ellis
stuart@elsn.org
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
GPG key ID: 7098ABEA GPG key fingerprint: 68B0 E291 FB19 C845 E60E 9569 292E E365 7098 ABEA
On 7/19/05, Karsten Wade kwade@redhat.com wrote:
I'll add this topic to the FDSCo meeting agenda for today (4 pm EDT), to see if anyone has any favorites there, and will post them back here.
well i got impatient and tried to start it via a vino session remotely... getting tracebacks from the 0.1.1 version i lifted from his directory so there might be some bugs that j5 needs to look at.
-jef"istanbul is such a tease"spaleta
On 7/19/05, Jeff Spaleta jspaleta@gmail.com wrote:
well i got impatient and tried to start it via a vino session remotely... getting tracebacks from the 0.1.1 version i lifted from his directory so there might be some bugs that j5 needs to look at.
Yep I just got confirmation about the problem from j5. My little experiment using istanbul or more primatively gst-launch is going to have to wait for a new version of gstreamer-plugins in rawhide that includes the ximagesrc plugin. As soon as j5 has the time( and this by no means is meant to make him feel rushed ) to push the update to gstreamer-plugins anyone running rawhide, including myself, will be able to follow up with some example raw theora videos either using gst-launch from the cmdline or with istanbul.
-jef"the real question is.. can I come up with a name better than 'monkey hoot' for my new video production endeavor"spaleta
On Tue, 2005-07-19 at 17:44 -0400, Jeff Spaleta wrote:
-jef"the real question is.. can I come up with a name better than 'monkey hoot' for my new video production endeavor"spaleta
Scapegoat Pictures. "Don't blame us, we didn't make it..."
On 7/19/05, Jesse Keating jkeating@j2solutions.net wrote:
Scapegoat Pictures. "Don't blame us, we didn't make it..."
niiiiiiiiiice.
And that names going to come in handy right away. The problem I was having.. has been fixed.. without needing to do any rebuilding of core packages. I ran gst-register as root and ximagesrc is now availalbe. The packages I made for istanbul work. With J5's blessing I'll try to maintain them in Extras for the development tree.
Now that the underlying problem is solved i can give you some mockup walk-through videos using gst-launch pipelines or with istanbul.
-jef
On Tue, 2005-07-19 at 19:25 -0400, Jeff Spaleta wrote:
On 7/19/05, Jesse Keating jkeating@j2solutions.net wrote:
Scapegoat Pictures. "Don't blame us, we didn't make it..."
niiiiiiiiiice.
And that names going to come in handy right away. The problem I was having.. has been fixed.. without needing to do any rebuilding of core packages. I ran gst-register as root and ximagesrc is now availalbe. The packages I made for istanbul work. With J5's blessing I'll try to maintain them in Extras for the development tree.
Now that the underlying problem is solved i can give you some mockup walk-through videos using gst-launch pipelines or with istanbul.
Even the mid-resolution one you did today looks good, it can expand to be much larger and was quite legible (considering).
If you want to rough out and write up the basic HOWTO for this, how about using the Wiki? We can take that and DocBookify it down the road, but having it be a living document that is not hidden in CVS would be good.
- Karsten
On 7/20/05, Karsten Wade kwade@redhat.com wrote:
If you want to rough out and write up the basic HOWTO for this, how about using the Wiki? We can take that and DocBookify it down the road, but having it be a living document that is not hidden in CVS would be good.
yeah i can do that. The big issue right now is dropped frames because the cpu can't keep up with the requested image grabbing rate in some situations. I'm hoping to come up with a standard prescription with regard to desktop resolution, framerate, encoded image size for all videos being produced. This will imply a minimum cpu requirement to ensure no frame-drops using what we have available for gstreamer-plugins right now in rawhide. I need to come up with a simple test for frame-dropping that aspiring video-makers can run quickly to see if their hardware is keeping up for the "standard" video configuration. The ximagesrc gst element should improve over time so some of the issues here with regard to frame dropping should evaporate as part of rawhide churn towards fc5.
I think long term you'll want to standardize on a low resolution desktop anyways so that you can encode to a reasonably sized image without loss of detail. 640x480 might be too small.. but 800x600 might be a reasonable desktop resolution to use when making task videos.
-jef
On Wed, 2005-07-20 at 10:27 -0400, Jeff Spaleta wrote:
On 7/20/05, Karsten Wade kwade@redhat.com wrote:
If you want to rough out and write up the basic HOWTO for this, how about using the Wiki? We can take that and DocBookify it down the road, but having it be a living document that is not hidden in CVS would be good.
yeah i can do that. The big issue right now is dropped frames because the cpu can't keep up with the requested image grabbing rate in some situations. I'm hoping to come up with a standard prescription with regard to desktop resolution, framerate, encoded image size for all videos being produced. This will imply a minimum cpu requirement to ensure no frame-drops using what we have available for gstreamer-plugins right now in rawhide. I need to come up with a simple test for frame-dropping that aspiring video-makers can run quickly to see if their hardware is keeping up for the "standard" video configuration. The ximagesrc gst element should improve over time so some of the issues here with regard to frame dropping should evaporate as part of rawhide churn towards fc5.
I think long term you'll want to standardize on a low resolution desktop anyways so that you can encode to a reasonably sized image without loss of detail. 640x480 might be too small.. but 800x600 might be a reasonable desktop resolution to use when making task videos.
That might be as big as you'd want it to get, since the video might be embedded in a web page that has to contain other bracketing information, such as the f.r.c web site, a locally-installed facsimile thereof, or just the user's screen if we have no way of predicting the resolution on the box. Font sizes, etc. may impact on the usability of the screenast, so those may be good things to consider as well.
On 7/20/05, Karsten Wade kwade@redhat.com wrote:
If you want to rough out and write up the basic HOWTO for this, how about using the Wiki? We can take that and DocBookify it down the road, but having it be a living document that is not hidden in CVS would be good.
http://www.fedoraproject.org/wiki/ScreenCasting
Instabul package is going through review now. As soon as i get approval for it and the Extras build process comes back up people should be able to play around with this by pulling istanbul and gstreamers-plugins from development... even on an fc4 box.
-jef
On 07/19/2005 09:50 AM, Greg DeKoenigsberg wrote:
On Tue, 19 Jul 2005, Christopher Aillon wrote:
But obviously they weren't answered for the review author. So there is a problem in our getting the message out. What good is the wiki if its not helping our users?
Um, it's helping our developers?
Yes. My sentence should have read "What good is the wiki for our users if its not helping them?" Expecting Joe User to find these answers on random websites is not really a good option.
Specifically when it comes to the second message, I think we need to promote the idea AGGRESSIVELY.
People won't get it until we hit them over the head with it.
Agreed. Besides, Greg, you know I'm always up for hitting people over the head. :-)
Am Dienstag, den 19.07.2005, 00:08 -0400 schrieb Christopher Aillon:
But obviously they weren't answered for the review author. So there is a problem in our getting the message out. What good is the wiki if its not helping our users?
I think what lacks is a solution. It is ok for Fedora to not distribute MP3 stuff. What i would like to see is to have an installer for enabling external yum repositories. So like from up2date one could choose: "add external sources". The list could be updated via web - and then there would be no problem, because only the enabling software is distributed. I do not understand why this opportunity is not provided. I guess this could be very easy.
I think in marketing the answer not always should be RTFM but do soemthing about things that are obviously problematic. So some discussion from marketing to development.
On 7/20/05, Thilo Pfennig tp@alternativ.net wrote:
So like from up2date one could choose: "add external sources". The list could be updated via web - and then there would be no problem, because only the enabling software is distributed.
I think you are wrong about where the grey line is. My personal understanding is that nothing distributed by default can pull in outside package sources to choose from or it has the potential to run afoul of the definition of "contributory infringement". You can't have up2date or any tool in the distro point to a list of external repos to choose from. Just like fedora.redhat.com can not link directly to a site like fedoratracker.
What would work would be a mimetype definition that 3rd party repos could use in a "Setup repository" link to install reponame-release package that contained the yum repo definitions and other items just like fedora-release package does and livna-release package does. But people would still have to google to find those repositories. Fedora can not link to a site explicitly meant to connect users to items Fedora itself can not legally distribute without risking "contributory infringement" claims if those outside repos trafficking in items not legally distributable under US law. You can provide a mechansim to easily point and click install the setup files needed to make an additional repository active once a user finds them.. but you can not point those users directly to additional repos. They must find them by other means.
-jef
On 7/20/05, Jeff Spaleta jspaleta@gmail.com wrote:
On 7/20/05, Thilo Pfennig tp@alternativ.net wrote:
So like from up2date one could choose: "add external sources". The list could be updated via web - and then there would be no problem, because only the enabling software is distributed.
I think you are wrong about where the grey line is. My personal understanding is that nothing distributed by default can pull in outside package sources to choose from or it has the potential to run afoul of the definition of "contributory infringement". You can't have up2date or any tool in the distro point to a list of external repos to choose from. Just like fedora.redhat.com can not link directly to a site like fedoratracker.
Couldn't the user add the repo names themselves? Adding third party repositories is a legit feature in and of itself, so we could have a list of repos of official Fedora mirrors and channels like Extras and Alternatives (and stable/test/release etc), that was autopolulated, and a field for a user to add other URLs. Then we're just talking about a GUI for repo management.
--jeremy
On 7/22/05, Jeremy Hogan jeremy.hogan@gmail.com wrote:
Couldn't the user add the repo names themselves? Adding third party repositories is a legit feature in and of itself, so we could have a list of repos of official Fedora mirrors and channels like Extras and Alternatives (and stable/test/release etc), that was autopolulated, and a field for a user to add other URLs. Then we're just talking about a GUI for repo management.
Its not simply one field. You'd have to add the name, the baseurl or mirrorlist url, whether or not you wanted gpgsig checking on, and then the gpgkey url and so on. The repo definition files have multiple settings that can be applied. Sure.. you could expose the full guts of creating a repo definition file via a gui and then require the users who create repo definitions that way to manually update those definitions by hand during upgrades to the next core release, but you might as well just give them instructions on how to use gedit at that point.
But that doesnt solve the problem of finding those repos. We can't tell users about those 3rd party repos anywhere inside Core or the official website. And for repos that offer reponame-release packages, it is far better to encourage people install that package to create the predefined repo configs which can be updated by the repo maintainer than it is to have users botching the writing of repo definitions by hand because they don't use things like the $releasever variables as appropriate to ease upgrade path to the next release.
The only users you really are going to help by exposing a full gui for creating a repo definition file are those users who are already know enough about which repos they want to actually edit a repo config by hand anyways. A mechanism to make it easy for users to click on a link on the 3rd party repo website to download and install the provided reponame-release.. serves all users. Users of a repo should be encouraged to use a repo config provided and updatable by the repo maintainer instead of making one by hand.
-jef
On Fri, 2005-07-22 at 12:35 -0400, Jeff Spaleta wrote:
The only users you really are going to help by exposing a full gui for creating a repo definition file are those users who are already know enough about which repos they want to actually edit a repo config by hand anyways. A mechanism to make it easy for users to click on a link on the 3rd party repo website to download and install the provided reponame-release.. serves all users. Users of a repo should be encouraged to use a repo config provided and updatable by the repo maintainer instead of making one by hand.
Instead of a package, could repos make their details available via RSS feeds? You would past an RSS URL into the GUI tool and it would pull down the latest details. If the repo maintainer needed to update something, they wouldn't have to roll and release a new package. The GUI could check for repo updates daily, weekly, whatever.
Yeah, I know, time to take this part of the conversation to f-devel-l. If anyone likes my idea, feel free to take it and champion it. :)
- Karsten
On 7/22/05, Karsten Wade kwade@redhat.com wrote:
Instead of a package, could repos make their details available via RSS feeds? You would past an RSS URL into the GUI tool and it would pull down the latest details.
Ugh.. horrid. You are asking a gui that has to be run by root to scrape configs out of an rss feed. Can you even provide a signed payload that way? Seems to me you are just re-inventing the wheel here. Just pull down a package and install it. Advertising "package links" via rss feeds is a good idea... but encoding the actual configs into an rss feed is not a good way to do this. At the end of the day.. you are installing config files that really should be managed by the rpm system just like what the fedora-release package does right now in Core....which means installing updates via a package. We do it for fedora-release, we should encourage 3rd parties to use the same mechanism. rpm -V is a good thing.. lets not invent something that shortcircuits the ability to verify that the configs you have are really the configs you are expected to have.
something, they wouldn't have to roll and release a new package. The GUI could check for repo updates daily, weekly, whatever.
Yeah we could provide all of files from all packages via an rss feed instead of via rpms. I'm really not seeing the advantage of providing a new mechanism to drop configs into a system. Can't people just advertise links to rpms in the rss feed and have the gui scrape for packages to install?
-jef
On Fri, 2005-07-22 at 13:51 -0400, Jeff Spaleta wrote:
On 7/22/05, Karsten Wade kwade@redhat.com wrote:
Instead of a package, could repos make their details available via RSS feeds? You would past an RSS URL into the GUI tool and it would pull down the latest details.
Ugh.. horrid. You are asking a gui that has to be run by root to scrape configs out of an rss feed. Can you even provide a signed payload that way? Seems to me you are just re-inventing the wheel here. Just pull down a package and install it. Advertising "package links" via rss feeds is a good idea... but encoding the actual configs into an rss feed is not a good way to do this. At the end of the day.. you are installing config files that really should be managed by the rpm system just like what the fedora-release package does right now in Core....which means installing updates via a package. We do it for fedora-release, we should encourage 3rd parties to use the same mechanism. rpm -V is a good thing.. lets not invent something that shortcircuits the ability to verify that the configs you have are really the configs you are expected to have.
Sure, that makes sense. I was just looking for something that was better than "type it in by hand". A feed would be moderately better at this. But, yeah, it sucks for security. I didn't think the idea through for all implications.
something, they wouldn't have to roll and release a new package. The GUI could check for repo updates daily, weekly, whatever.
Yeah we could provide all of files from all packages via an rss feed instead of via rpms. I'm really not seeing the advantage of providing a new mechanism to drop configs into a system. Can't people just advertise links to rpms in the rss feed and have the gui scrape for packages to install?
I feel end users might be confused by the idea of installing and updating a package in order to have the latest information on where packages are. But that is probably small minded of me. :) Otherwise, your shoot down of my idea is correct -- the security would be horrid and a reinvention. :)
It might help to make fedora-announce-list available as an RSS feed, then ask repo packagers to advertise their updates there.
- Karsten
On 7/22/05, Karsten Wade kwade@redhat.com wrote:
It might help to make fedora-announce-list available as an RSS feed, then ask repo packagers to advertise their updates there.
http://fedoraproject.org/infofeed/ http://fedoranews.org/blog/index.php?cat=1
-jef
On 7/22/05, Karsten Wade kwade@redhat.com wrote:
I feel end users might be confused by the idea of installing and updating a package in order to have the latest information on where packages are.
Having a specially crafted rss feed that can help a tool to import the repo key and then install the reponame-release package seemlessly for a repo is reasonable. Each post on to that rss feed would include 2 urls one for the repo key and one for the release package as well as some simple information describing the repo. The gui-tool could parse the structured posts to the rss feed and compile a list of additional repos from the user to select. On selection the keys for the repos are imported and then the signed packages which provide the configs are installed
You still run into the problem of how to advertise that feed. I don't think you can get away with turning on support for a feed like that by default. And then there are the murky issues about how to notify the users about the consequences of choosing to use repos which overlap with Core and Extras.. before they choose to install configs for those repos.
-jef
On 7/22/05, Karsten Wade kwade@redhat.com wrote:
I feel end users might be confused by the idea of installing and updating a package in order to have the latest information on where packages are.
Having a specially crafted rss feed that can help a tool to import the repo key and then install the reponame-release package seemlessly for a repo is reasonable. Each post on to that rss feed would include 2 urls one for the repo key and one for the release package as well as some simple information describing the repo. The gui-tool could parse the structured posts to the rss feed and compile a list of additional repos from the user to select. On selection the keys for the repos are imported and then the signed packages which provide the configs are installed
You still run into the problem of how to advertise that feed. I don't think you can get away with turning on support for a feed like that by default. And then there are the murky issues about how to notify the users about the consequences of choosing to use repos which overlap with Core and Extras.. before they choose to install configs for those repos.
-jef
I would have to agree with that last paragraph. When I first started using Fedora the only problems I ever had was mixing the repo's up. Now with a little bit of experience I know what repositories to mix and what not to.
If something like this is going to be implemented which I like the idea of it it really needs to be stressed that you may mess up your whole system. Although its rebuildable however it still takes awhile to rebuild it.
Marc
-- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-marketing-list
Am Mittwoch, den 20.07.2005, 12:46 -0400 schrieb Jeff Spaleta:
I think you are wrong about where the grey line is. My personal understanding is that nothing distributed by default can pull in outside package sources to choose from or it has the potential to run afoul of the definition of "contributory infringement".
So yumex must be escluded from fedora extras because it can import Repos? That can't be it.
But people would still have to google to find those repositories.
Why? Can't a Fedora application use the Google API to get the results? It can't be forbidden to help people. If he start here, where does this end? Do not provide bookmarks, because in China some news sites may be forbidden? I don't see an end of censorship if there can no be at least some hint. A tool to help to find repos must be Ok, we also provide browser that know Google - and Google is also a tool to find such repos. There must be at least some solution?
Fedora can not link to a site explicitly meant to connect users to items Fedora itself can not legally distribute without risking "contributory infringement" claims if those outside repos trafficking in items not legally distributable under US law.
Well then we should not provide network access or browsers at all... and no support for cd drives...
What about a page in a tool that describes what is not possible and links to a further page and this page links to a google search - and this google search gives the result of a rpm-package that enables toe possibility for enabling more repositories. (not to make it complicated ... ;-) ) So the information is not on the CD and not at the official Fedora site. A google search result can easily be interated into an application. That information than is provided by Google and not by Fedora.
Thilo
On Sat, Jul 23, 2005 at 12:00:01PM +0200, Thilo Pfennig wrote:
I think you are wrong about where the grey line is. My personal understanding is that nothing distributed by default can pull in outside package sources to choose from or it has the potential to run afoul of the definition of "contributory infringement".
So yumex must be escluded from fedora extras because it can import Repos? That can't be it.
No, but the default yumex configuration had to change so that it didn't list optional third-party repos.
On 7/23/05, Thilo Pfennig tp@alternativ.net wrote:
So yumex must be escluded from fedora extras because it can import Repos? That can't be it.
take a good long hard look at the yumex in extras. It no longer provides a static list of additional 3rd party repos in its install.
Why? Can't a Fedora application use the Google API to get the results?
1) Use of google's api is for personal use only and requires users obtain a license key from Google unless the you can get written consent from Google to do something different. The restrictions google places on access to its web api is pretty impractical for any open source client.
2) While Google is pretty good, its not fool-proof. I would absolutely not trust pulling system configs directly from a list of websites Google returns without human review. And well.. if you are going to do human review.. you might as well just open up a browser and use google. If someone does attempt to make a tool that scrapes Google outout for webpages with system configs and repo definitions.. I will delibrately try to create a false website that gets highly ranked to disrupt the tool's use of google.
A tool to help to find repos must be Ok, we also provide browser that know Google - and Google is also a tool to find such repos. There must be at least some solution?
Google is a tool to find anything... anywhere. A local user must initiate the communication with Google and must ask Google explicitly for things to search for. A tool designed only to find information about repos to help users obtain items we can't legally ship.. automatically... is totally different.
Well then we should not provide network access or browsers at all... and no support for cd drives...
Feel free to be as flippant as you want.. thats not going to change the fact that there are real legal issues here that Red Hat as the managing entity needs to be careful of. If you can't take this seriously.. then please.. just be quiet. Contributory infringement, involves a delibrate intent to knowingly aid others to infringe. I think its pretty damn clear that adding any tool that delibrately help users find additional repos and instantly configure them falls into the definition of contributory infringement. A tool that just handles repo configs is very narrowly defined, its not a general use tool. Most if not all of the popular 3rd party repos out there are popular specifically because they provide material that Fedora can not.
- and
this google search gives the result of a rpm-package that enables toe possibility for enabling more repositories. (not to make it complicated ... ;-) ) So the information is not on the CD and not at the official Fedora site. A google search result can easily be interated into an application.
I don't think you can get away with a pre-defined google search. Even if it was legally okay to do that, i think you can trust the accuracy of the pre-defined google search over the lifetime of a release. I'm pretty sure I'm not the only one who would delibrately attempt to corrupt the dynamic list of results to that google search, and I'm pretty sure the other people would put in pages far more malicious than mine.
-jef
A tool to help to find repos must be Ok, we also provide browser that know Google - and Google is also a tool to find such repos. There must be at least some solution?
Google is a tool to find anything... anywhere. A local user must initiate the communication with Google and must ask Google explicitly for things to search for. A tool designed only to find information about repos to help users obtain items we can't legally ship.. automatically... is totally different.
Well then we should not provide network access or browsers at all... and no support for cd drives...
Feel free to be as flippant as you want.. thats not going to change the fact that there are real legal issues here that Red Hat as the managing entity needs to be careful of. If you can't take this seriously.. then please.. just be quiet. Contributory infringement, involves a delibrate intent to knowingly aid others to infringe. I think its pretty damn clear that adding any tool that delibrately help users find additional repos and instantly configure them falls into the definition of contributory infringement. A tool that just handles repo configs is very narrowly defined, its not a general use tool. Most if not all of the popular 3rd party repos out there are popular specifically because they provide material that Fedora can not.
One thing that has frustrated me is that we seem before to have just turned a blind eye to the whole lot even though we know its there. Only now are we making it clearer as to the reasons why mp3's and the propietary software are not supported.
However let me ask this is it illegal to add a 3rd party repo or is it only illegal if the content on it is wrong?
I'm not being stupid I don't understand where the line is because I'm lucky we don't have that law in Australia at the moment I'm sure that will change. If it isn't illegal to supply a repo then what is the problem in for instance having a list of repo's for yumex like you said.
- and
this google search gives the result of a rpm-package that enables toe possibility for enabling more repositories. (not to make it complicated ... ;-) ) So the information is not on the CD and not at the official Fedora site. A google search result can easily be interated into an application.
I don't think you can get away with a pre-defined google search. Even if it was legally okay to do that, i think you can trust the accuracy of the pre-defined google search over the lifetime of a release. I'm pretty sure I'm not the only one who would delibrately attempt to corrupt the dynamic list of results to that google search, and I'm pretty sure the other people would put in pages far more malicious than mine.
-jef
-- Fedora-marketing-list mailing list Fedora-marketing-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-marketing-list
On Sun, 24 Jul 2005, Marc Wiriadisastra wrote:
One thing that has frustrated me is that we seem before to have just turned a blind eye to the whole lot even though we know its there. Only now are we making it clearer as to the reasons why mp3's and the propietary software are not supported.
Better late than never, and hard to do everything right the first time.
However let me ask this is it illegal to add a 3rd party repo or is it only illegal if the content on it is wrong?
It's *probably* illegal to add 3rd party repos that we know to include infringing content -- because that would be the same as *knowingly directing users to illegal content*. Because most 3rd party repos don't care much about these issues (largely because they don't have to), it's too risky for us to refer users directly to these repos.
I'm not being stupid I don't understand where the line is because I'm lucky we don't have that law in Australia at the moment I'm sure that will change.
Part of the problem is that the line isn't bright and clear. For that reason, we will be quite conservative in the decisions we make abut what might infringe.
--g
_____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan
On Sat, Jul 23, 2005 at 11:05:19PM -0400, Greg DeKoenigsberg wrote:
It's *probably* illegal to add 3rd party repos that we know to include infringing content -- because that would be the same as *knowingly directing users to illegal content*. Because most 3rd party repos don't care much about these issues (largely because they don't have to), it's too risky for us to refer users directly to these repos.
Although, a lot of the content isn't actually illegal -- just grey area.
Part of the problem is that the line isn't bright and clear. For that reason, we will be quite conservative in the decisions we make abut what might infringe.
Right. :)
Am Samstag, den 23.07.2005, 10:29 -0400 schrieb Jeff Spaleta:
Feel free to be as flippant as you want.. thats not going to change the fact that there are real legal issues here that Red Hat as the managing entity needs to be careful of.
Ok, but where do we stop? Is Red Hat banning packages from distribution and content that is illegal in Russia or Italy? Would it be a good idea to ask the user on installation where he lives? The installer than could than have a different setup for different countries (another sort of localization). I do not like this direction, because things get split up. Debian also had repos they called "non-us". They had higher enrcyption bit sizes etc.. Did anyone consider that?
Thilo
On 7/25/05, Thilo Pfennig tp@alternativ.net wrote:
Ok, but where do we stop?
RH has to stop short of violating existing copyright or patent law, no matter how they or we feel about it.
Is Red Hat banning packages from distribution and content that is illegal in Russia or Italy?
There's illegal content in Russia? ;-)
Would it be a good idea to ask the user on installation where he lives? The installer than could than have a different setup for different countries (another sort of localization). I do not like this direction, because things get split up. Debian also had repos they called "non-us". They had higher enrcyption bit sizes etc.. Did anyone consider that?
Yes, RH is a US based company, and the US is where most of the users live. Enabling something overseas would cause forks in the code they'd not like to maintain, and would send mixed messages to the users. And RH did have alternate encryption for countries where it was legal -- note that "legal" and "not declared illegal" and "tolerated" are all very different, at patent and copyright is all over the map.
But, it's not just the considerably tricky legalities, it's the principle.
The real issue is that US copyright is broken and software patents are for suckers. So rather than allow people gray area end-arounds to using patent of bully infringed code, we should instead advocate for things like Ogg, Theora and FLAC. And continue to go way out of our way to make sure that people understand the real reasons why RH can't ship that stuff, and it's not that they can't afford the royalties on MP3 codecs.
IMHO, since Fedora has not been declared a general purpose stable desktop, telling folks to Google it will get them buy if they insist on using dubious or flat out illegal code. Our target users either understand what's going on, or are adept enough at installingpackages to go and get the tools they need. Anyone who expects Fedora to be an out-of-the-box Mac-mini-killing entertainment desktop will probably be disappointed, but they'll live, and RH won;t get sued into the bedrock.
--jeremy
On Mon, 25 Jul 2005, Jeremy Hogan wrote:
The real issue is that US copyright is broken and software patents are for suckers. So rather than allow people gray area end-arounds to using patent of bully infringed code, we should instead advocate for things like Ogg, Theora and FLAC. And continue to go way out of our way to make sure that people understand the real reasons why RH can't ship that stuff, and it's not that they can't afford the royalties on MP3 codecs.
"Software patents are for suckers."
There's another good slogan for the list. Leave it to Slogan Hogan.
--g
_____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan
On Mon, 2005-07-25 at 17:28 -0400, Greg DeKoenigsberg wrote:
There's another good slogan for the list. Leave it to Slogan Hogan.
http://fedoraproject.org/wiki/Marketing/Slogans
Keep 'em coming.
On Mon, 2005-07-25 at 17:55 -0700, Karsten Wade wrote:
Added:
* Fedora: More freedom than you can shake a patent lawyer at!
* Fedora: No patent lawyers were harmed in the making of this product.
* Fedora: No patent lawyers profited due to the making of this product.
* Fedora: All the fun you can have without a patent laywer.
Jeremy Hogan wrote:
Yes, RH is a US based company, and the US is where most of the users live.
I challenge the second part of this affirmation, I am sure most of the Fedora users live outside US.
I think the fact that RH sponsors in the corporate environment Fedora then its a target whether or not the majority of the users are outside the USA. Its basically the fact that Fedora is linked to redhat so we have to abide by the US laws whether we agree or not.
Thats depressing I know however its life and as I had discussions in my business today about this I find certain aspects of laws in different countries silly, including my own but thats an off-topic discussion for a different day.
On Tue, 2005-07-26 at 08:45 +0300, Nicu Buculei wrote:
Jeremy Hogan wrote:
Yes, RH is a US based company, and the US is where most of the users live.
I challenge the second part of this affirmation, I am sure most of the Fedora users live outside US.
do either of you have any numbers for this discussion to matter? no. does it matter? no.
-sv
On 7/26/05, seth vidal skvidal@phy.duke.edu wrote:
On Tue, 2005-07-26 at 08:45 +0300, Nicu Buculei wrote:
Jeremy Hogan wrote:
Yes, RH is a US based company, and the US is where most of the users live.
I challenge the second part of this affirmation, I am sure most of the Fedora users live outside US.
do either of you have any numbers for this discussion to matter?
I was referring to RH users. They're mostly in the US. I don't have exact numbers, but it wouldn't matter re: the point I was actually making.
--jeremy
On Tue, 2005-07-26 at 08:45 +0300, Nicu Buculei wrote:
Yes, RH is a US based company, and the US is where most of the users live.
I challenge the second part of this affirmation, I am sure most of the Fedora users live outside US.
Nonetheless, if we include things w/software patents (making it illegal in the US), we've lost a huge user base
marketing@lists.fedoraproject.org
-
Christopher Aillon -
Colin Charles -
Greg DeKoenigsberg -
Jef Spaleta -
Jeremy Hogan -
Jesse Keating -
Karsten Wade -
Marc Wiriadisastra -
Matthew Miller -
Nicu Buculei -
Paul W. Frields -
Robert 'Bob' Jensen -
Sankarshan Mukhopadhyay -
seth vidal -
Stuart Ellis -
Thilo Pfennig