Hi, folks. Just want to flag up this blocker bug:
https://bugzilla.redhat.com/show_bug.cgi?id=629192
as it stands, the whole pino / oauth mess blocks F14 release; apps that are on the desktop spin / default desktop install which don't basically work (so that includes pino at present) block the release.
So, as I see it, there's three options here:
* ship a fixed pino * ship something else * don't ship a twitter client by default
Just wanted to start a thread to flag up the issue and prompt a discussion of an appropriate resolution. thanks!
On Fri, 2010-10-01 at 11:13 -0700, Adam Williamson wrote:
So, as I see it, there's three options here:
- ship a fixed pino
- ship something else
- don't ship a twitter client by default
Just wanted to start a thread to flag up the issue and prompt a discussion of an appropriate resolution. thanks!
I'd vote for option #3 - don't ship a twitter client by default, and put something in the release notes regarding the available options for folks that want to install one.
Later, /B
Brian Pepple (bpepple@fedoraproject.org) said:
So, as I see it, there's three options here:
- ship a fixed pino
- ship something else
- don't ship a twitter client by default
Just wanted to start a thread to flag up the issue and prompt a discussion of an appropriate resolution. thanks!
I'd vote for option #3 - don't ship a twitter client by default, and put something in the release notes regarding the available options for folks that want to install one.
I would just include gwibber, personally (assuming it fits.)
Bill
On Fri, 2010-10-01 at 14:44 -0400, Bill Nottingham wrote:
Brian Pepple (bpepple@fedoraproject.org) said:
So, as I see it, there's three options here:
- ship a fixed pino
- ship something else
- don't ship a twitter client by default
Just wanted to start a thread to flag up the issue and prompt a discussion of an appropriate resolution. thanks!
I'd vote for option #3 - don't ship a twitter client by default, and put something in the release notes regarding the available options for folks that want to install one.
I would just include gwibber, personally (assuming it fits.)
Yeah, if we want to ship one, gwibber is pretty much the only option, since it's most likely too late to fix pino before F14 is released. The big cons about gwibber, in my opinion is the fairly poor performance I've experienced with it (tho I last used it about 2 months ago) and the number of dependencies it would pull into the livecd.
Later, /B
On Fri, Oct 01, 2010 at 03:01:25PM -0400, Brian Pepple wrote:
On Fri, 2010-10-01 at 14:44 -0400, Bill Nottingham wrote:
Brian Pepple (bpepple@fedoraproject.org) said:
So, as I see it, there's three options here:
- ship a fixed pino
- ship something else
- don't ship a twitter client by default
Just wanted to start a thread to flag up the issue and prompt a discussion of an appropriate resolution. thanks!
I'd vote for option #3 - don't ship a twitter client by default, and put something in the release notes regarding the available options for folks that want to install one.
I would just include gwibber, personally (assuming it fits.)
Yeah, if we want to ship one, gwibber is pretty much the only option, since it's most likely too late to fix pino before F14 is released. The big cons about gwibber, in my opinion is the fairly poor performance I've experienced with it (tho I last used it about 2 months ago) and the number of dependencies it would pull into the livecd.
Doesn't post-Beta seem too late to do this? Better to have people simply use their browser I'd think.
On Fri, 2010-10-01 at 16:07 -0400, Paul W. Frields wrote:
Yeah, if we want to ship one, gwibber is pretty much the only option, since it's most likely too late to fix pino before F14 is released. The big cons about gwibber, in my opinion is the fairly poor performance I've experienced with it (tho I last used it about 2 months ago) and the number of dependencies it would pull into the livecd.
Doesn't post-Beta seem too late to do this? Better to have people simply use their browser I'd think.
well, we have to make *some* kind of post-beta change here, since as I said the current situation blocks the release. I don't think subbing in gwibber for pino is a particularly scary change, all we'd have to check is if it goes over the size limit, and if it works, which is about half an hour of effort.
On Fri, Oct 1, 2010 at 4:19 PM, Adam Williamson awilliam@redhat.com wrote:
well, we have to make *some* kind of post-beta change here, since as I said the current situation blocks the release. I don't think subbing in gwibber for pino is a particularly scary change, all we'd have to check is if it goes over the size limit, and if it works, which is about half an hour of effort.
Hm, is the only reason that gwibber works is because of the Canonical exception?
On Fri, Oct 01, 2010 at 01:19:52PM -0700, Adam Williamson wrote:
On Fri, 2010-10-01 at 16:07 -0400, Paul W. Frields wrote:
Yeah, if we want to ship one, gwibber is pretty much the only option, since it's most likely too late to fix pino before F14 is released. The big cons about gwibber, in my opinion is the fairly poor performance I've experienced with it (tho I last used it about 2 months ago) and the number of dependencies it would pull into the livecd.
Doesn't post-Beta seem too late to do this? Better to have people simply use their browser I'd think.
well, we have to make *some* kind of post-beta change here, since as I said the current situation blocks the release. I don't think subbing in gwibber for pino is a particularly scary change, all we'd have to check is if it goes over the size limit, and if it works, which is about half an hour of effort.
Right, the uncertainty I have is really around the functionality of the new suggested default client, as opposed to "let's not do anything." My preference would be a simple removal of pino for no other reason than least disturbance of the Force.
On Fri, Oct 1, 2010 at 10:44 PM, Paul W. Frields stickster@gmail.com wrote:
On Fri, Oct 01, 2010 at 01:19:52PM -0700, Adam Williamson wrote:
On Fri, 2010-10-01 at 16:07 -0400, Paul W. Frields wrote:
Yeah, if we want to ship one, gwibber is pretty much the only option, since it's most likely too late to fix pino before F14 is released. The big cons about gwibber, in my opinion is the fairly poor performance I've experienced with it (tho I last used it about 2 months ago) and the number of dependencies it would pull into the livecd.
Doesn't post-Beta seem too late to do this? Better to have people simply use their browser I'd think.
well, we have to make *some* kind of post-beta change here, since as I said the current situation blocks the release. I don't think subbing in gwibber for pino is a particularly scary change, all we'd have to check is if it goes over the size limit, and if it works, which is about half an hour of effort.
Right, the uncertainty I have is really around the functionality of the new suggested default client, as opposed to "let's not do anything." My preference would be a simple removal of pino for no other reason than least disturbance of the Force.
I am not sure that this is a good idea, we found that a certain app isn't working and we have a suitable replacement so we should opt for using the later rather than *nothing*.
On Fri, Oct 1, 2010 at 5:41 PM, drago01 drago01@gmail.com wrote:
I am not sure that this is a good idea, we found that a certain app isn't working and we have a suitable replacement so we should opt for using the later rather than *nothing*.
The suitable replacement is still available in the repositories. The release note can say:
An application installed by default in Fedora 13, "pino" was removed because the site no longer allows access. For more information, see: http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-t...
As a replacement, you can access previously supported sites (identi.ca, Twitter, etc.) via their respective web sites, or by installing one of several replacement applications such as "gwibber".
On Fri, 2010-10-01 at 17:45 -0400, Colin Walters wrote:
On Fri, Oct 1, 2010 at 5:41 PM, drago01 drago01@gmail.com wrote:
I am not sure that this is a good idea, we found that a certain app isn't working and we have a suitable replacement so we should opt for using the later rather than *nothing*.
The suitable replacement is still available in the repositories. The release note can say:
An application installed by default in Fedora 13, "pino" was removed because the site no longer allows access. For more information, see: http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-t...
As a replacement, you can access previously supported sites (identi.ca, Twitter, etc.) via their respective web sites, or by installing one of several replacement applications such as "gwibber".
+1. I would much prefer to see us do this then add gwibber to the LiveCD.
Later, /B
On Fri, 2010-10-01 at 16:44 -0400, Paul W. Frields wrote:
On Fri, Oct 01, 2010 at 01:19:52PM -0700, Adam Williamson wrote:
On Fri, 2010-10-01 at 16:07 -0400, Paul W. Frields wrote:
Yeah, if we want to ship one, gwibber is pretty much the only option, since it's most likely too late to fix pino before F14 is released. The big cons about gwibber, in my opinion is the fairly poor performance I've experienced with it (tho I last used it about 2 months ago) and the number of dependencies it would pull into the livecd.
Doesn't post-Beta seem too late to do this? Better to have people simply use their browser I'd think.
well, we have to make *some* kind of post-beta change here, since as I said the current situation blocks the release. I don't think subbing in gwibber for pino is a particularly scary change, all we'd have to check is if it goes over the size limit, and if it works, which is about half an hour of effort.
Right, the uncertainty I have is really around the functionality of the new suggested default client, as opposed to "let's not do anything." My preference would be a simple removal of pino for no other reason than least disturbance of the Force.
I agree that removing pino, together with a suitable note in the release notes, is the safest route at this point.
On Fri, Oct 01, 2010 at 11:48:07PM -0400, Matthias Clasen wrote:
On Fri, 2010-10-01 at 16:44 -0400, Paul W. Frields wrote:
On Fri, Oct 01, 2010 at 01:19:52PM -0700, Adam Williamson wrote:
On Fri, 2010-10-01 at 16:07 -0400, Paul W. Frields wrote:
Yeah, if we want to ship one, gwibber is pretty much the only option, since it's most likely too late to fix pino before F14 is released. The big cons about gwibber, in my opinion is the fairly poor performance I've experienced with it (tho I last used it about 2 months ago) and the number of dependencies it would pull into the livecd.
Doesn't post-Beta seem too late to do this? Better to have people simply use their browser I'd think.
well, we have to make *some* kind of post-beta change here, since as I said the current situation blocks the release. I don't think subbing in gwibber for pino is a particularly scary change, all we'd have to check is if it goes over the size limit, and if it works, which is about half an hour of effort.
Right, the uncertainty I have is really around the functionality of the new suggested default client, as opposed to "let's not do anything." My preference would be a simple removal of pino for no other reason than least disturbance of the Force.
I agree that removing pino, together with a suitable note in the release notes, is the safest route at this point.
Adding the docs@ list to the cc so that they are aware of the need for a release note for this. Docs folks, feel free to ask questions here on desktop@ as needed to figure out the best text.
This is definitely scope creeping the discussion here, but I'm coming round to the viewpoint that Fedora shoudn't ship any application in the default install whose primary purpose is to connect to proprietary web services, or at least not ones configured by default to do so. (All apps are of course free to be in the repositories).
This would dovetail nicely with making it not suck to install applications.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/1/10 11:52 AM, Colin Walters wrote:
This is definitely scope creeping the discussion here, but I'm coming round to the viewpoint that Fedora shoudn't ship any application in the default install whose primary purpose is to connect to proprietary web services, or at least not ones configured by default to do so. (All apps are of course free to be in the repositories).
This would dovetail nicely with making it not suck to install applications.
- From what I understand, pino also works with identi.ca, and there is no issues with the current version in F14 for doing that. Whether identa.ca or twitter is the default I don't know.
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Jesse Keating (jkeating@redhat.com) said:
This is definitely scope creeping the discussion here, but I'm coming round to the viewpoint that Fedora shoudn't ship any application in the default install whose primary purpose is to connect to proprietary web services, or at least not ones configured by default to do so. (All apps are of course free to be in the repositories).
This would dovetail nicely with making it not suck to install applications.
- From what I understand, pino also works with identi.ca, and there is no
issues with the current version in F14 for doing that. Whether identa.ca or twitter is the default I don't know.
According to the bug, identi.ca support is broken too.
Bill
-----Original Message----- From: Bill Nottingham notting@redhat.com To: Discussions about development for the Fedora desktop desktop@lists.fedoraproject.org Sent: Fri, Oct 1, 2010 11:47 am Subject: Re: F14: what to do about pino / twitter
Jesse Keating (jkeating@redhat.com) said:
This is definitely scope creeping the discussion here, but I'm coming round to the viewpoint that Fedora shoudn't ship any application in the default install whose primary purpose is to connect to proprietary web services, or at least not ones configured by default to do so. (All apps are of course free to be in the repositories).
This would dovetail nicely with making it not suck to install applications.
- From what I understand, pino also works with identi.ca, and there is no
issues with the current version in F14 for doing that. Whether identa.ca or twitter is the default I don't know.
According to the bug, identi.ca support is broken too.
Bill
On Fri, Oct 1, 2010 at 8:52 PM, Colin Walters walters@verbum.org wrote:
This would dovetail nicely with making it not suck to install applications.
Which still is the case in F14 (app installation suck).
On Fri, 2010-10-01 at 14:52 -0400, Colin Walters wrote:
This is definitely scope creeping the discussion here, but I'm coming round to the viewpoint that Fedora shoudn't ship any application in the default install whose primary purpose is to connect to proprietary web services, or at least not ones configured by default to do so. (All apps are of course free to be in the repositories).
This would dovetail nicely with making it not suck to install applications.
I don't think this is a useful direction to take the F14/pino problem into. If we stop installing applications that are useful for users, then the users will go somewhere else.
'Its not pure enough for us, but you _can_ install this shit if you really insist' is not a good enough answer...
On Fri, 2010-10-01 at 15:50 -0400, Matthias Clasen wrote:
On Fri, 2010-10-01 at 14:52 -0400, Colin Walters wrote:
This is definitely scope creeping the discussion here, but I'm coming round to the viewpoint that Fedora shoudn't ship any application in the default install whose primary purpose is to connect to proprietary web services, or at least not ones configured by default to do so. (All apps are of course free to be in the repositories).
This would dovetail nicely with making it not suck to install applications.
I don't think this is a useful direction to take the F14/pino problem into. If we stop installing applications that are useful for users, then the users will go somewhere else.
This is the same argument you can make with proprietary hardware drivers. Ultimately we've always agreed with the FSF position that encouraging the use of proprietary software just makes it less likely that free software will be written, so we shouldn't do it.
The situation here is exactly analogous. If we choose to, say, ship a client configured to connect to identi.ca by default instead, we're putting our weight behind freedom in a very important area, just as important as hardware support.
I'd say we shouldn't adopt contradictory policies here.
On Fri, 2010-10-01 at 13:03 -0700, Adam Williamson wrote:
On Fri, 2010-10-01 at 15:50 -0400, Matthias Clasen wrote:
On Fri, 2010-10-01 at 14:52 -0400, Colin Walters wrote:
This is definitely scope creeping the discussion here, but I'm coming round to the viewpoint that Fedora shoudn't ship any application in the default install whose primary purpose is to connect to proprietary web services, or at least not ones configured by default to do so. (All apps are of course free to be in the repositories).
This would dovetail nicely with making it not suck to install applications.
I don't think this is a useful direction to take the F14/pino problem into. If we stop installing applications that are useful for users, then the users will go somewhere else.
This is the same argument you can make with proprietary hardware drivers. Ultimately we've always agreed with the FSF position that encouraging the use of proprietary software just makes it less likely that free software will be written, so we shouldn't do it.
The situation here is exactly analogous. If we choose to, say, ship a client configured to connect to identi.ca by default instead, we're putting our weight behind freedom in a very important area, just as important as hardware support.
I'd say we shouldn't adopt contradictory policies here.
I concur.
-sv
On Fri, Oct 1, 2010 at 4:03 PM, Adam Williamson awilliam@redhat.com wrote:
The situation here is exactly analogous. If we choose to, say, ship a client configured to connect to identi.ca by default instead, we're putting our weight behind freedom in a very important area, just as important as hardware support.
Both pino and gwibber support identi.ca. Gwibber also supports generic StatusNet services. Neither app seems to show preferential treatment to a particular service.
On Fri, 01 Oct 2010 13:03:51 -0700, you wrote:
On Fri, 2010-10-01 at 15:50 -0400, Matthias Clasen wrote:
On Fri, 2010-10-01 at 14:52 -0400, Colin Walters wrote:
This is definitely scope creeping the discussion here, but I'm coming round to the viewpoint that Fedora shoudn't ship any application in the default install whose primary purpose is to connect to proprietary web services, or at least not ones configured by default to do so. (All apps are of course free to be in the repositories).
This would dovetail nicely with making it not suck to install applications.
I don't think this is a useful direction to take the F14/pino problem into. If we stop installing applications that are useful for users, then the users will go somewhere else.
This is the same argument you can make with proprietary hardware drivers. Ultimately we've always agreed with the FSF position that encouraging the use of proprietary software just makes it less likely that free software will be written, so we shouldn't do it.
The situation here is exactly analogous. If we choose to, say, ship a client configured to connect to identi.ca by default instead, we're putting our weight behind freedom in a very important area, just as important as hardware support.
Pino does not connect to anything be default, you need an account in order to connect to either twitter or identi.ca with a dedicated client like pino.
The bigger question this brings up is where does Fedora draw the line.
Binary drivers are an easy case, they are bad in several ways for Fedora. Bugs can't be fixed, they make figuring out what component is at fault difficult, and most importantly if allowed to expand can lead to a situation where a free, open source operating system is impossible.
When you start talking about restricting software based on what it connects to you are going into a very grey area.
If we ban Pino because it connects to proprietary twitter, then do we also ban all the email clients? They can be used to connect to proprietary mail servers.
How about Samba? Its purpose is to network with Windows.
How about Network Manager? Its used to connect to network devices that are usually running proprietary software.
What about web browsers? Likely 90% of what users connect to are based at least partially on proprietary software.
It would be somewhat ironic if Fedora, having just taken steps to improve the user experience by creating rules regarding disruptive updates, makes all the effort irrelevant by removing the software that makes Fedora usuable by those users.
On Fri, 2010-10-01 at 20:29 -0400, Gerald Henriksen wrote:
On Fri, 01 Oct 2010 13:03:51 -0700, you wrote:
On Fri, 2010-10-01 at 15:50 -0400, Matthias Clasen wrote:
On Fri, 2010-10-01 at 14:52 -0400, Colin Walters wrote:
This is definitely scope creeping the discussion here, but I'm coming round to the viewpoint that Fedora shoudn't ship any application in the default install whose primary purpose is to connect to proprietary web services, or at least not ones configured by default to do so. (All apps are of course free to be in the repositories).
This would dovetail nicely with making it not suck to install applications.
I don't think this is a useful direction to take the F14/pino problem into. If we stop installing applications that are useful for users, then the users will go somewhere else.
This is the same argument you can make with proprietary hardware drivers. Ultimately we've always agreed with the FSF position that encouraging the use of proprietary software just makes it less likely that free software will be written, so we shouldn't do it.
The situation here is exactly analogous. If we choose to, say, ship a client configured to connect to identi.ca by default instead, we're putting our weight behind freedom in a very important area, just as important as hardware support.
Pino does not connect to anything be default, you need an account in order to connect to either twitter or identi.ca with a dedicated client like pino.
In that case, IMHO, it's fine.
The bigger question this brings up is where does Fedora draw the line.
Yeah, indeed. There's a big fuzzy area.
2010/10/1 Adam Williamson awilliam@redhat.com:
On Fri, 2010-10-01 at 15:50 -0400, Matthias Clasen wrote:
On Fri, 2010-10-01 at 14:52 -0400, Colin Walters wrote:
This is definitely scope creeping the discussion here, but I'm coming round to the viewpoint that Fedora shoudn't ship any application in the default install whose primary purpose is to connect to proprietary web services, or at least not ones configured by default to do so. (All apps are of course free to be in the repositories).
This would dovetail nicely with making it not suck to install applications.
I don't think this is a useful direction to take the F14/pino problem into. If we stop installing applications that are useful for users, then the users will go somewhere else.
This is the same argument you can make with proprietary hardware drivers. Ultimately we've always agreed with the FSF position that encouraging the use of proprietary software just makes it less likely that free software will be written, so we shouldn't do it.
The situation here is exactly analogous. If we choose to, say, ship a client configured to connect to identi.ca by default instead, we're putting our weight behind freedom in a very important area, just as important as hardware support.
I'd say we shouldn't adopt contradictory policies here.
With that in mind. What about Rhythmbox, being installed by default, defaults to having the Last.fm plugin enabled. Last.fm is proprietary and there is a FaiF alternative, Libre.fm, available. There is a way for Rhythmbox to use Libre.fm in stead, however that require you to edit a GConf key. Proprietary and FaiF services are not given equal opportunities here.
What to do about that? Have Rhythmbox preconfigured to Libre.fm by default? Turn the Last.fm plugin off by default? Perhaps investing some time making the plugin more agnostic to which services and have it give users a fair choice.
As it is now, Libre.fm is pretty undiscoverable.
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
On Mon, Oct 4, 2010 at 11:39 AM, Torstein Adolf Winterseth torswin@gmail.com wrote:
With that in mind. What about Rhythmbox, being installed by default, defaults to having the Last.fm plugin enabled.
Basically applications like this would need to provide a "Search for plugins" interface.
On Oct 1, 2010, at 14:53, Colin Walters walters@verbum.org wrote:
This is definitely scope creeping the discussion here, but I'm coming round to the viewpoint that Fedora shoudn't ship any application in the default install whose primary purpose is to connect to proprietary web services, or at least not ones configured by default to do so. (All apps are of course free to be in the repositories).
This would dovetail nicely with making it not suck to install applications.
How would you define a "proprietary web service"?
Is google such a service ? The only open protocol used by connecting any app to any of their servers is http, xmpp etc. Everything behind is closed. So we remove firefox ?
Lars
On Fri, Oct 1, 2010 at 8:36 PM, herrmann@redhat.com wrote:
How would you define a "proprietary web service"?
Is google such a service ? The only open protocol used by connecting any app to any of their servers is http, xmpp etc. Everything behind is closed. So we remove firefox ?
Exactly. We've been down this road. Anything which can view arbitrary content can be used to interact with proprietary services. Do we not ship the Exchange support for Evolution? Do we not include f-spot (I realize it's not in the default spin) because it's able to export to Flickr (Shotwell can too, BTW)? Where does it stop?
I think that based upon our (upcoming) vision statement, all of these things fit. People are in control of the content with all of these programs, and have to make a conscious choice to use the external service. . Eliminating choices of what to do with that content in fact explicitly goes against that vision, since the user is no longer in control.
When you think longer term, about what's good for Fedora, it becomes clear that restricting users to interact solely with free services does not further our goal of attracting more users to the platform, therefore increasing the pool of potential contributors. I *do* think that for applications which support a mixture of free and non-free services, the free services should be presented as defaults.
On Fri, 2010-10-01 at 20:51 -0400, Jon Stanley wrote:
On Fri, Oct 1, 2010 at 8:36 PM, herrmann@redhat.com wrote:
How would you define a "proprietary web service"?
Is google such a service ? The only open protocol used by connecting any app to any of their servers is http, xmpp etc. Everything behind is closed. So we remove firefox ?
Exactly. We've been down this road. Anything which can view arbitrary content can be used to interact with proprietary services. Do we not ship the Exchange support for Evolution? Do we not include f-spot (I realize it's not in the default spin) because it's able to export to Flickr (Shotwell can too, BTW)? Where does it stop?
Those aren't the same thing. When it comes to a twitter client we're not talking about 'arbitrary content', we're talking about an app whose sole purpose is to provide *specific* content to a *specific* service. If pino is neutral between twitter and identi.ca by default, as someone suggested, then I think it's clearly fine.
On Fri, 01 Oct 2010 19:37:11 -0700, you wrote:
On Fri, 2010-10-01 at 20:51 -0400, Jon Stanley wrote:
On Fri, Oct 1, 2010 at 8:36 PM, herrmann@redhat.com wrote:
How would you define a "proprietary web service"?
Is google such a service ? The only open protocol used by connecting any app to any of their servers is http, xmpp etc. Everything behind is closed. So we remove firefox ?
Exactly. We've been down this road. Anything which can view arbitrary content can be used to interact with proprietary services. Do we not ship the Exchange support for Evolution? Do we not include f-spot (I realize it's not in the default spin) because it's able to export to Flickr (Shotwell can too, BTW)? Where does it stop?
Those aren't the same thing. When it comes to a twitter client we're not talking about 'arbitrary content', we're talking about an app whose sole purpose is to provide *specific* content to a *specific* service. If pino is neutral between twitter and identi.ca by default, as someone suggested, then I think it's clearly fine.
So, to explore this line in the sand further, are we saying for a user of Fedora:
1) it is okay to use twitter via a web browser (Firefox, Epiphany, etc.)
2) it is not okay to use twitter via a dedicated client like Pino?
How exactly is this going to help the goal of freedom?
If anything this kind of arbitrary banning could end up hurting freedom by encouraging people trying Fedora to instead either just go back to an entirely proprietary system, or go with another distribution that doesn't care about freedom as much.
On Fri, 2010-10-01 at 23:49 -0400, Gerald Henriksen wrote:
Those aren't the same thing. When it comes to a twitter client we're not talking about 'arbitrary content', we're talking about an app whose sole purpose is to provide *specific* content to a *specific* service. If pino is neutral between twitter and identi.ca by default, as someone suggested, then I think it's clearly fine.
So, to explore this line in the sand further, are we saying for a user of Fedora:
- it is okay to use twitter via a web browser (Firefox, Epiphany,
etc.)
- it is not okay to use twitter via a dedicated client like Pino?
How exactly is this going to help the goal of freedom?
That's not the right way of looking at it. It's not about whether it's 'okay' or not. We hardly send stormtroopers out to people's houses to investigate what software they use, after all. We don't shoot people for using nvidia. We just don't *provide* it. Don't move the goalposts.
If anything this kind of arbitrary banning could end up hurting freedom by encouraging people trying Fedora to instead either just go back to an entirely proprietary system, or go with another distribution that doesn't care about freedom as much.
That's a very limited, short-term view.
On Fri, Oct 1, 2010 at 8:51 PM, Jon Stanley jonstanley@gmail.com wrote:
When you think longer term, about what's good for Fedora, it becomes clear that restricting users to interact solely with free services
People - stop reading what I didn't write. I said *installed by default*, nothing more. There's a world of difference.
The point is to get Fedora out of the business of implicitly endorsing these services. If you install a twitter/facebook/whatever app, it's *your* call, not Fedora's.
Again - let me make this super big and bold:
* REMOVING ANYTHING FROM THE REPOSITORIES IS NOT UNDER DISCUSSION HERE
desktop@lists.fedoraproject.org
-
Adam Williamson -
Bill Nottingham -
Brian Pepple -
Colin Walters -
drago01 -
Gerald Henriksen -
goineasy9＠aol.com -
Jesse Keating -
Jon Stanley -
Lars Herrmann -
Matthias Clasen -
Mike McLean -
Paul W. Frields -
Seth Vidal -
Torstein Adolf Winterseth