I kept this question inside of me but it is bursting out.
Why would anyone change the name of gnome-key-manager (a name with some meaning) to seahorse (seemingly meaningless)? -- ======================================================================= "This is a job for BOB VIOLENCE and SCUM, the INCREDIBLY STUPID MUTANT DOG." -- Bob Violence ======================================================================= Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net
On Fri, 16 Apr 2010 08:25:27 -0500 Aaron Konstam wrote:
Why would anyone change the name of gnome-key-manager (a name with some meaning) to seahorse (seemingly meaningless)?
I think this falls under my theory:
http://home.comcast.net/~tomhorsley/wisdom/braindump/darwin.html
:-).
On Fri, Apr 16, 2010 at 6:55 PM, Aaron Konstam akonstam@sbcglobal.net wrote:
I kept this question inside of me but it is bursting out.
Why would anyone change the name of gnome-key-manager (a name with some meaning) to seahorse (seemingly meaningless)?
SO you see, a trojan horse was _kinda_ like a key to the city of Troy. The seahorse is the god of horses[1]... so you see the connection? ;)
[1] http://en.wikipedia.org/wiki/Hippocamp
On 04/16/2010 07:05 PM, Tom Horsley wrote:
On Fri, 16 Apr 2010 08:25:27 -0500 Aaron Konstam wrote:
Why would anyone change the name of gnome-key-manager (a name with some meaning) to seahorse (seemingly meaningless)?
I think this falls under my theory:
http://home.comcast.net/~tomhorsley/wisdom/braindump/darwin.html
I assume this is written in a tongue in cheek manner but this is a a rather common misconception. Seahorse has replaced gnome-keyring-manager and it is not a simple rename but a different project and done by a team of volunteers. Let's look at the business rationale: First of all, not every company relies on the support and services model. There is a wide variety of business models built around free and open source software. The second misunderstanding is what support and services actually mean. Red Hat, for example does assist customers to setup the environment to meet particular needs but that hardly covers everything. Support also involves developing new features or in many cases, development entirely new projects to meet customer needs and also elevation of bug fixes. Red Hat has a fairly large content services team which is responsible for pretty good documentation in http://redhat.com and some of the documentation in http://docs.fedoraproject.org not to mention http://kbase.redhat.com and content for the Red Hat certification courses.
Rahul
On Sun, 2010-04-18 at 11:40 +0530, Rahul Sundaram wrote:
On 04/16/2010 07:05 PM, Tom Horsley wrote:
On Fri, 16 Apr 2010 08:25:27 -0500 Aaron Konstam wrote:
Why would anyone change the name of gnome-key-manager (a name with some meaning) to seahorse (seemingly meaningless)?
I think this falls under my theory:
http://home.comcast.net/~tomhorsley/wisdom/braindump/darwin.html
I assume this is written in a tongue in cheek manner but this is a a rather common misconception. Seahorse has replaced gnome-keyring-manager and it is not a simple rename but a different project and done by a team of volunteers. Let's look at the business rationale: First of all, not every company relies on the support and services model. There is a wide variety of business models built around free and open source software. The second misunderstanding is what support and services actually mean. Red Hat, for example does assist customers to setup the environment to meet particular needs but that hardly covers everything. Support also involves developing new features or in many cases, development entirely new projects to meet customer needs and also elevation of bug fixes. Red Hat has a fairly large content services team which is responsible for pretty good documentation in http://redhat.com and some of the documentation in http://docs.fedoraproject.org not to mention http://kbase.redhat.com and content for the Red Hat certification courses.
Rahul
As I sometimes am, I am confused by what you say Rahul. The question is not whether Red Hat has a right to replace programs by new ones created by another different team of volunteers. They do.
My question is why call the new project seahorse a name which would be hard to associate with what the program does. Is there some reason that the new program could not keep the same name or at least a more meaningful name? -- ======================================================================= "It doesn't much signify whom one marries for one is sure to find out next morning it was someone else." -- Rogers ======================================================================= Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net
On 04/18/2010 07:06 PM, Aaron Konstam wrote:
As I sometimes am, I am confused by what you say Rahul. The question is not whether Red Hat has a right to replace programs by new ones created by another different team of volunteers. They do.
I wasn't answering you. It was a reply to Tom Horsley.
My question is why call the new project seahorse a name which would be hard to associate with what the program does. Is there some reason that the new program could not keep the same name or at least a more meaningful name?
Two projects obviously can't have the same name. The name is a word play. Developers can pick whatever name they want. If you don't like it, feel free to talk to them. Downstream distributions have no say on that.
Rahul
On Sun, 2010-04-18 at 19:24 +0530, Rahul Sundaram wrote:
On 04/18/2010 07:06 PM, Aaron Konstam wrote:
As I sometimes am, I am confused by what you say Rahul. The question is not whether Red Hat has a right to replace programs by new ones created by another different team of volunteers. They do.
I wasn't answering you. It was a reply to Tom Horsley.
My question is why call the new project seahorse a name which would be hard to associate with what the program does. Is there some reason that the new program could not keep the same name or at least a more meaningful name?
Two projects obviously can't have the same name. The name is a word play. Developers can pick whatever name they want. If you don't like it, feel free to talk to them. Downstream distributions have no say on that.
On the other hand, we do have control over the descriptions in the RPM packages. When this issue came up last fall, I filed a bug to make sure that the word "keyring" appeared in the description field for seahorse, so that it would at least show up in the results of 'yum search keyring'. That bug has not been acted on since I filed it. I just updated the version to 12.
https://bugzilla.redhat.com/show_bug.cgi?id=536945
Rahul
On Sun, 2010-04-18 at 08:36 -0500, Aaron Konstam wrote:
My question is why call the new project seahorse a name which would be hard to associate with what the program does. Is there some reason that the new program could not keep the same name or at least a more meaningful name?
It's a fair comment, people fall in love with the idea of branding something with their pet name, but fail to see how pointless their name is if you're not already familiar with their brand name.
Seahorse doesn't occur to me as a logical name for key management. Nor does Firefox sound like the name for a web browser, or Thunderbird for email...
On the other hand, when it's referred to as the Firefox web browser, then I know it's *a* web browser, and *which* one. Likewise for the other applications I mentioned, but that (full identification) rarely seems to be the case.
Better use of the menu system helps in this regards, but only for what's already installed. If it comes to adding more software, much of the stuff listed in the add/remove list of thingies is completely obscure. KDE seems to be the worst for that sort of thing, coming up with kutesy names that start with a k, but mean nothing to you unless you've already heard of the program.
On 04/19/2010 12:52 AM, Matthew Saltzman wrote:
On the other hand, we do have control over the descriptions in the RPM packages. When this issue came up last fall, I filed a bug to make sure that the word "keyring" appeared in the description field for seahorse, so that it would at least show up in the results of 'yum search keyring'. That bug has not been acted on since I filed it. I just updated the version to 12.
You are right. I just resolved it with a updated description.
Rahul
On Mon, 2010-04-19 at 23:22 +0530, Rahul Sundaram wrote:
On 04/19/2010 12:52 AM, Matthew Saltzman wrote:
On the other hand, we do have control over the descriptions in the RPM packages. When this issue came up last fall, I filed a bug to make sure that the word "keyring" appeared in the description field for seahorse, so that it would at least show up in the results of 'yum search keyring'. That bug has not been acted on since I filed it. I just updated the version to 12.
You are right. I just resolved it with a updated description.
Thanks!
Rahul
Hi: 2ยข
On Tue, 2010-04-20 at 03:00 +0930, Tim wrote:
On Sun, 2010-04-18 at 08:36 -0500, Aaron Konstam wrote:
On the other hand, when it's referred to as the Firefox web browser, then I know it's *a* web browser, and *which* one. Likewise for the other applications I mentioned, but that (full identification) rarely seems to be the case.
Better use of the menu system helps in this regards, but only for what's already installed. If it comes to adding more software, much of the stuff listed in the add/remove list of thingies is completely obscure. KDE seems to be the worst for that sort of thing, coming up with kutesy names that start with a k, but mean nothing to you unless you've already heard of the program.
Just to add another dimension to this naming discussion. The name often has nothing to do with the command line run command and there is no easy way to find what command to use on the command line if or when you want to run an application from there instead of a menu icon. The only successful way I have found is to drag a copy of the icon from the menu to the desktop and then look at the properties on the desktop icon. Surely there could be a field in the menu properties that shows the /bin or /sbin command.
On 19 April 2010 19:30, William Case billlinux@rogers.com wrote:
Just to add another dimension to this naming discussion. The name often has nothing to do with the command line run command and there is no easy way to find what command to use on the command line if or when you want to run an application from there instead of a menu icon.
I do this often enough, that I have a bash shell function that takes the Display Name as the argument and finds the program run:
[sam@samlap ~ ]$ desktop_menu_exec "AisleRiot Solitaire" /usr/bin/sol
[sam@samlap ~ ]$ tail -n4 .bash_profile function desktop_menu_exec { FILES=`grep -l "$1" /usr/share/applications/*` grep Exec $FILES | cut -d= -f2 | xargs -n1 which }
-- Sam
On Mon, 19 Apr 2010 14:30:19 -0400 William Case wrote:
The only successful way I have found is to drag a copy of the icon from the menu to the desktop and then look at the properties on the desktop icon.
I do grep -r in the /usr/share/applications directory to find the .desktop file for the thing I'm searching for, then look at it to see what the Exec= line says :-).
-
Aaron Konstam -
Bill Case -
Matthew Saltzman -
Rahul Sundaram -
Sam Sharpe -
Siddhesh Poyarekar -
Tim -
Tom Horsley