I have a few ideas that IMO would make Fedora more usable as a general desktop and developer platform:
What? :
1. have gnome-terminal shortcut on gnome panel (as firefox and evolution)
2. have gnome clipboard manager installed by default (glipper gnome applet)
3. have /usr/sbin and /sbin in PATH for regular users
Why? :
1. because gnome-terminal is the second most used [1] application on gnome desktop and this would make it more accessible for users.
2. because any desktop needs a good clipboard manager, it enhances usability enormously.
3. I personally need it only for some commands - like /sbin/ifconfig and /sbin/iwconfig are there any down sides to putting new /sbin and /usr/sbin in every users PATH variable? What do you think is this a good or bad idea?
Cheers, Valent.
[1] http://online.gnome.org/applications
Valent Turkovic escribió:
I have a few ideas that IMO would make Fedora more usable as a general desktop and developer platform:
What? :
have gnome-terminal shortcut on gnome panel (as firefox and evolution)
have gnome clipboard manager installed by default (glipper gnome applet)
I agree with these two.
- have /usr/sbin and /sbin in PATH for regular users
I don't agree with this one...
Why? :
- because gnome-terminal is the second most used [1] application on
gnome desktop and this would make it more accessible for users.
- because any desktop needs a good clipboard manager, it enhances
usability enormously.
These two indeed make sense, though some people might think that having a shortcut for the terminal in the panel by default may be against the purpose of the desktop usability guidelines.
- I personally need it only for some commands - like /sbin/ifconfig
and /sbin/iwconfig are there any down sides to putting new /sbin and /usr/sbin in every users PATH variable? What do you think is this a good or bad idea?
Maybe a better approach for those commands in particular would be to add aliases for them in /usr/bin? I can think of a couple more commands that may benefit from being also available in their restricted mode to regular users (lspci, lsusb, lsof, etc), but being as /sbin paths are meant for administrative tasks, I actually do see having them as part of a regular user's PATH a potential security risk.
Cheers, Valent.
Gian Paolo Mureddu gmureddu@prodigy.net.mx writes:
but being as /sbin paths are meant for administrative tasks, I actually do see having them as part of a regular user's PATH a potential security risk.
Right, we keep them from trying to run dangerous commands by putting those commands into a separate directory. Let's just hope they never learn to type /sbin/ in front of anything. Maybe we should remove the / key from their keyboards, but then they might copy/paste it... What to do...
/Benny
On Wed, Mar 26, 2008 at 12:44 PM, Benny Amorsen benny+usenet@amorsen.dk wrote:
Gian Paolo Mureddu gmureddu@prodigy.net.mx writes:
but being as /sbin paths are meant for administrative tasks, I actually do see having them as part of a regular user's PATH a potential security risk.
Right, we keep them from trying to run dangerous commands by putting those commands into a separate directory. Let's just hope they never learn to type /sbin/ in front of anything. Maybe we should remove the / key from their keyboards, but then they might copy/paste it... What to do...
/Benny
LOL
+1
You can pull out "/" just leave the "anykey" button :)
Cheers, Valent.
On Tue, 2008-03-25 at 12:02 -0600, Gian Paolo Mureddu wrote:
but being as /sbin paths are meant for administrative tasks, I actually do see having them as part of a regular user's PATH a potential security risk.
That's completely bogus. A "hidden path" offers 0 security. If you don't want your users running them, set the permissions on the binary, or better yet, have the binary check the EUID of the caller. If non-root, display that the command is for root users, but also allow the user to get --help and other usage or informational output from the command. Just don't allow non-root users to apply anything. There really is no reason I can think of to hide this crap in a different directory. It just adds needless complication and confusion.
On Wed, 2008-03-26 at 08:42 -0400, Jesse Keating wrote:
On Tue, 2008-03-25 at 12:02 -0600, Gian Paolo Mureddu wrote:
but being as /sbin paths are meant for administrative tasks, I actually do see having them as part of a regular user's PATH a potential security risk.
That's completely bogus. A "hidden path" offers 0 security. If you don't want your users running them, set the permissions on the binary, or better yet, have the binary check the EUID of the caller. If non-root, display that the command is for root users, but also allow the user to get --help and other usage or informational output from the command. Just don't allow non-root users to apply anything. There really is no reason I can think of to hide this crap in a different directory. It just adds needless complication and confusion.
+1 -sv
On Wed, Mar 26, 2008 at 1:55 PM, seth vidal skvidal@fedoraproject.org wrote:
On Wed, 2008-03-26 at 08:42 -0400, Jesse Keating wrote:
On Tue, 2008-03-25 at 12:02 -0600, Gian Paolo Mureddu wrote:
but being as /sbin paths are meant for administrative tasks, I actually do see having them as part of a regular user's PATH a potential security risk.
That's completely bogus. A "hidden path" offers 0 security. If you don't want your users running them, set the permissions on the binary, or better yet, have the binary check the EUID of the caller. If non-root, display that the command is for root users, but also allow the user to get --help and other usage or informational output from the command. Just don't allow non-root users to apply anything. There really is no reason I can think of to hide this crap in a different directory. It just adds needless complication and confusion.
+1 -sv
I'll post a RFE in BZ regarding this issue. What component should I choose?
Valent.
On Wed, 2008-03-26 at 14:13 +0100, Valent Turkovic wrote:
I'll post a RFE in BZ regarding this issue. What component should I choose?
Theoretically "distribution" but Will Woods is already working on a Feature proposal for Fedora 10 to fix this sillyness.
2008/3/26 Jesse Keating jkeating@redhat.com:
On Tue, 2008-03-25 at 12:02 -0600, Gian Paolo Mureddu wrote:
but being as /sbin paths are meant for administrative tasks, I actually do see having them as part of a regular user's PATH a potential security risk.
That's completely bogus. A "hidden path" offers 0 security. If you don't want your users running them, set the permissions on the binary, or better yet, have the binary check the EUID of the caller. If non-root, display that the command is for root users, but also allow the user to get --help and other usage or informational output from the command. Just don't allow non-root users to apply anything. There really is no reason I can think of to hide this crap in a different directory. It just adds needless complication and confusion.
Is Fedora committed to the FHS? Or is Red Hat still committed to it?
The purpose was for root only programs of a certain class to be located in /sbin for example but including non-root programs there does muddy the experience for the end user. However I do think it is cleaner to make those programs available to a user by means other than adding /sbin to the default path of a normal user. A few links are cheap. Would links for those in /usr/bin clash with the FHS?
John
On Wed, 2008-03-26 at 08:18 -0500, inode0 wrote:
Is Fedora committed to the FHS? Or is Red Hat still committed to it?
The purpose was for root only programs of a certain class to be located in /sbin for example but including non-root programs there does muddy the experience for the end user. However I do think it is cleaner to make those programs available to a user by means other than adding /sbin to the default path of a normal user. A few links are cheap. Would links for those in /usr/bin clash with the FHS?
I think the idea is to place symlinks in (/usr)/sbin as par of a fhs-compat package. Otherwise the bins actually go in (/usr)/bin. "root only" is extremely muddy these days, especially because as non-root I'd like to explore syntax options and usage statements before I invoke the command with sudo.
Jesse Keating (jkeating@redhat.com) said:
On Wed, 2008-03-26 at 08:18 -0500, inode0 wrote:
Is Fedora committed to the FHS? Or is Red Hat still committed to it?
The purpose was for root only programs of a certain class to be located in /sbin for example but including non-root programs there does muddy the experience for the end user. However I do think it is cleaner to make those programs available to a user by means other than adding /sbin to the default path of a normal user. A few links are cheap. Would links for those in /usr/bin clash with the FHS?
I think the idea is to place symlinks in (/usr)/sbin as par of a fhs-compat package. Otherwise the bins actually go in (/usr)/bin. "root only" is extremely muddy these days, especially because as non-root I'd like to explore syntax options and usage statements before I invoke the command with sudo.
Why not just change the path rather than litter the world with symlinks?
(Also, this is getting offtopic for -desktop rather fast.)
Bill
On Wed, 2008-03-26 at 08:18 -0500, inode0 wrote:
2008/3/26 Jesse Keating jkeating@redhat.com:
On Tue, 2008-03-25 at 12:02 -0600, Gian Paolo Mureddu wrote:
but being as /sbin paths are meant for administrative tasks, I actually do see having them as part of a regular user's PATH a potential security risk.
That's completely bogus. A "hidden path" offers 0 security. If you don't want your users running them, set the permissions on the binary, or better yet, have the binary check the EUID of the caller. If non-root, display that the command is for root users, but also allow the user to get --help and other usage or informational output from the command. Just don't allow non-root users to apply anything. There really is no reason I can think of to hide this crap in a different directory. It just adds needless complication and confusion.
Is Fedora committed to the FHS? Or is Red Hat still committed to it?
The purpose was for root only programs of a certain class to be located in /sbin for example but including non-root programs there does muddy the experience for the end user. However I do think it is cleaner to make those programs available to a user by means other than adding /sbin to the default path of a normal user. A few links are cheap. Would links for those in /usr/bin clash with the FHS?
1. The FHS makes no rules about the default PATH setting for users/root 2. The FHS has no problems with symlinks for the files it requires in /sbin and /usr/sbin
So changing the defaults away from a 'hidden' /sbin and /usr/sbin would not violate the FHS.
-sv
On Wed, Mar 26, 2008 at 8:30 AM, seth vidal skvidal@fedoraproject.org wrote:
On Wed, 2008-03-26 at 08:18 -0500, inode0 wrote:
Is Fedora committed to the FHS? Or is Red Hat still committed to it?
The purpose was for root only programs of a certain class to be located in /sbin for example but including non-root programs there does muddy the experience for the end user. However I do think it is cleaner to make those programs available to a user by means other than adding /sbin to the default path of a normal user. A few links are cheap. Would links for those in /usr/bin clash with the FHS?
- The FHS makes no rules about the default PATH setting for users/root
Oh, I did not mean to imply that it did. My minor objection to getting rid of /sbin abstractly is that as a normal user I just don't really want to be exposed to the programs I can't execute in a meaningful way as a normal user.
- The FHS has no problems with symlinks for the files it requires
in /sbin and /usr/sbin
I was wondering about whether the FHS objected to "cross linking" programs that are used by both root and normal users that reside in /sbin with symlinks in /usr/bin which is in the user's path already?!
John
On Wed, 2008-03-26 at 08:55 -0500, inode0 wrote:
On Wed, Mar 26, 2008 at 8:30 AM, seth vidal skvidal@fedoraproject.org wrote:
On Wed, 2008-03-26 at 08:18 -0500, inode0 wrote:
Is Fedora committed to the FHS? Or is Red Hat still committed to it?
The purpose was for root only programs of a certain class to be located in /sbin for example but including non-root programs there does muddy the experience for the end user. However I do think it is cleaner to make those programs available to a user by means other than adding /sbin to the default path of a normal user. A few links are cheap. Would links for those in /usr/bin clash with the FHS?
- The FHS makes no rules about the default PATH setting for users/root
Oh, I did not mean to imply that it did. My minor objection to getting rid of /sbin abstractly is that as a normal user I just don't really want to be exposed to the programs I can't execute in a meaningful way as a normal user.
- The FHS has no problems with symlinks for the files it requires
in /sbin and /usr/sbin
I was wondering about whether the FHS objected to "cross linking" programs that are used by both root and normal users that reside in /sbin with symlinks in /usr/bin which is in the user's path already?!
Unless there's an addendum I missed they make no comments about it whatsoever.
-sv
That's completely bogus. A "hidden path" offers 0 security. If you [...] really is no reason I can think of to hide this crap in a different directory. It just adds needless complication and confusion.
+1
Why was this (/sbin, /usr/sbin) arrangement used in the first place?
Cheers, Debarshi
Jesse Keating escribió:
On Tue, 2008-03-25 at 12:02 -0600, Gian Paolo Mureddu wrote:
but being as /sbin paths are meant for administrative tasks, I actually do see having them as part of a regular user's PATH a potential security risk.
That's completely bogus. A "hidden path" offers 0 security. If you don't want your users running them, set the permissions on the binary, or better yet, have the binary check the EUID of the caller. If non-root, display that the command is for root users, but also allow the user to get --help and other usage or informational output from the command. Just don't allow non-root users to apply anything. There really is no reason I can think of to hide this crap in a different directory. It just adds needless complication and confusion.
Sarcastic disclaimer.
Why not install all binaries into /bin, /usr/bin, /usr/local/bin and be done with it, then? Why EVEN have another path, anyway? Better yet, why don't we follow Ubuntu and make sudo the default, make regular users have admin rights! Why do we even need root? What's that? Geeze, I mean why even keep an ancient file system layout?
On Wed, 2008-03-26 at 15:12 -0600, Gian Paolo Mureddu wrote:
Sarcastic disclaimer.
Why not install all binaries into /bin, /usr/bin, /usr/local/bin and be done with it, then? Why EVEN have another path, anyway? Better yet, why don't we follow Ubuntu and make sudo the default, make regular users have admin rights! Why do we even need root? What's that? Geeze, I mean why even keep an ancient file system layout?
Believe it or not, these are all pretty useful suggestions.
Links to (/usr)/sbin can be maintained for legacy or FHS compliance. However due to shortcomings in RPM this isn't feasible. Instead we'll just munge the normal user's path so that (s)he doesn't have to go hunting for useful tools.
Sudo should (optionally) be the default for the first user added, like say through firstboot. A checkbox that would have to be cleared that will drop the user in the wheel group which by default has sudo rights (that way we don't have to munge the sudors file).
"root" is a legacy concept. Either the local user is also the admin, or the admin is a site wide admin where local root accounts are just jokes and instead things are done as sudo, or through config management systems.
I also agree that ancient filesystem layouts are needless confusion. They (almost) made since way back in the day, but fear of chance has kept them coming forward into modern day operating systems where they're just not needed, and only add confusion and frustration. "Where do I install this binary into? What level man page do I give this?" etc...
On Wed, 2008-03-26 at 20:29 -0400, Jesse Keating wrote:
I also agree that ancient filesystem layouts are needless confusion. They (almost) made since way back in the day, but fear of chance has kept them coming forward into modern day operating systems where they're just not needed, and only add confusion and frustration. "Where do I install this binary into? What level man page do I give this?" etc...
Indeed the manpage level stuff is just chock full of crazy
-sv
seth vidal escribió:
On Wed, 2008-03-26 at 20:29 -0400, Jesse Keating wrote:
I also agree that ancient filesystem layouts are needless confusion. They (almost) made since way back in the day, but fear of chance has kept them coming forward into modern day operating systems where they're just not needed, and only add confusion and frustration. "Where do I install this binary into? What level man page do I give this?" etc...
Indeed the manpage level stuff is just chock full of crazy
-sv
I thought info was meant to obsolete man?
On Thu, 2008-03-27 at 03:50 -0600, Gian Paolo Mureddu wrote:
seth vidal escribió:
On Wed, 2008-03-26 at 20:29 -0400, Jesse Keating wrote:
I also agree that ancient filesystem layouts are needless confusion. They (almost) made since way back in the day, but fear of chance has kept them coming forward into modern day operating systems where they're just not needed, and only add confusion and frustration. "Where do I install this binary into? What level man page do I give this?" etc...
Indeed the manpage level stuff is just chock full of crazy
-sv
I thought info was meant to obsolete man?
I wouldn't hold my breath.
-s
On Thu, 2008-03-27 at 09:11 -0400, seth vidal wrote:
I thought info was meant to obsolete man?
I wouldn't hold my breath.
Can I get an info viewer that's as simple to use as man? I always seem to get rather lost in info, and have to quit, start over just to get back to the freaking menu. Forgive me for not being an emacs user...
On Thu, 2008-03-27 at 09:15 -0400, Jesse Keating wrote:
On Thu, 2008-03-27 at 09:11 -0400, seth vidal wrote:
I thought info was meant to obsolete man?
I wouldn't hold my breath.
Can I get an info viewer that's as simple to use as man? I always seem to get rather lost in info, and have to quit, start over just to get back to the freaking menu. Forgive me for not being an emacs user...
same issue here.
-sv
2008/3/27 Jesse Keating jkeating@redhat.com:
On Thu, 2008-03-27 at 09:11 -0400, seth vidal wrote:
I thought info was meant to obsolete man?
I wouldn't hold my breath.
Can I get an info viewer that's as simple to use as man? I always seem to get rather lost in info, and have to quit, start over just to get back to the freaking menu. Forgive me for not being an emacs user...
pinfo is about as simple as lynx
John
2008/3/27 Jesse Keating jkeating@redhat.com:
Can I get an info viewer that's as simple to use as man? I always seem to get rather lost in info, and have to quit, start over just to get back to the freaking menu. Forgive me for not being an emacs user...
+20,000
On Thu, 2008-03-27 at 09:15 -0400, Jesse Keating wrote:
On Thu, 2008-03-27 at 09:11 -0400, seth vidal wrote:
I thought info was meant to obsolete man?
I wouldn't hold my breath.
Can I get an info viewer that's as simple to use as man? I always seem to get rather lost in info, and have to quit, start over just to get back to the freaking menu. Forgive me for not being an emacs user...
yelp supports man,info,and docbook.
2008/3/26 Jesse Keating jkeating@redhat.com:
"root" is a legacy concept. Either the local user is also the admin, or the admin is a site wide admin where local root accounts are just jokes and instead things are done as sudo, or through config management systems.
I'm still dropping to root on systems that I'm not sitting in front of when I need to troubleshoot hardware. We'd have to make sure that all the devices which get dynamically created get the correct permissions such that an admin group such as 'wheel' can make use of them by default.
-jef
On Thu, 2008-03-27 at 08:45 -0800, Jeff Spaleta wrote:
2008/3/26 Jesse Keating jkeating@redhat.com: "root" is a legacy concept. Either the local user is also the admin, or the admin is a site wide admin where local root accounts are just jokes and instead things are done as sudo, or through config management systems.
I'm still dropping to root on systems that I'm not sitting in front of when I need to troubleshoot hardware. We'd have to make sure that all the devices which get dynamically created get the correct permissions such that an admin group such as 'wheel' can make use of them by default.
I don't disagree.
On Wed, 2008-03-26 at 20:29 -0400, Jesse Keating wrote:
On Wed, 2008-03-26 at 15:12 -0600, Gian Paolo Mureddu wrote:
Sarcastic disclaimer.
Why not install all binaries into /bin, /usr/bin, /usr/local/bin and be done with it, then? Why EVEN have another path, anyway? Better yet, why don't we follow Ubuntu and make sudo the default, make regular users have admin rights! Why do we even need root? What's that? Geeze, I mean why even keep an ancient file system layout?
Believe it or not, these are all pretty useful suggestions.
Links to (/usr)/sbin can be maintained for legacy or FHS compliance. However due to shortcomings in RPM this isn't feasible. Instead we'll just munge the normal user's path so that (s)he doesn't have to go hunting for useful tools.
Hm. Most of the commands found in {/usr,}/sbin only make sense for a user with elevated privileges, i.e. root. Those that also make sense for normal users (e.g. tools which provide read-only access as well like ip/ifconfig, sysctl, etc.) could easily be hardlinked into the bin directories on the same level without much hassle on the RPM side of things.
Sudo should (optionally) be the default for the first user added, like say through firstboot. A checkbox that would have to be cleared that will drop the user in the wheel group which by default has sudo rights (that way we don't have to munge the sudors file).
Sudo is all fine and dandy if you think about the command line, but this is still a "legacy" way of doing things. Mind that as long as they're in good order I'm all for keeping "legacy" as "legacy" often also means "tried and true". I also don't see a reason why "legacy" and new ways can't coexist.
"root" is a legacy concept. Either the local user is also the admin, or the admin is a site wide admin where local root accounts are just jokes and instead things are done as sudo, or through config management systems.
"root" is only a legacy concept inasmuch as UIDs are seen as users, not as roles that someone assumes temporarily, e.g. by way of sudo or PolicyKit/dbus proxies. Keeping the privileged role separate from the normal role, even for the primary user of a system, is one line of defense against malware.
I also agree that ancient filesystem layouts are needless confusion. They (almost) made since way back in the day, but fear of chance has kept them coming forward into modern day operating systems where they're just not needed, and only add confusion and frustration. "Where do I install this binary into? What level man page do I give this?" etc...
Man pages are a particularly bad example, as it's not only "What level man page do I give this?" but also "What level is this man page I want to read?" -- "man foo" almost always displays the wrong one if there are multiple.
Other than that, the distinction and compartmentalization between / and /usr is quite sound -- the former contains the basic set of tools and libraries to bootstrap the system, regardless of where from the rest comes. If disaster strikes, a small root volume is much less likely to be than a giant single volume and it gives me the tools necessary to salvage what is salvageable.
Nils
On Wed, Mar 26, 2008 at 10:12 PM, Gian Paolo Mureddu gmureddu@prodigy.net.mx wrote:
Jesse Keating escribió:
On Tue, 2008-03-25 at 12:02 -0600, Gian Paolo Mureddu wrote:
but being as /sbin paths are meant for administrative tasks, I actually do see having them as part of a regular user's PATH a potential security risk.
That's completely bogus. A "hidden path" offers 0 security. If you don't want your users running them, set the permissions on the binary, or better yet, have the binary check the EUID of the caller. If non-root, display that the command is for root users, but also allow the user to get --help and other usage or informational output from the command. Just don't allow non-root users to apply anything. There really is no reason I can think of to hide this crap in a different directory. It just adds needless complication and confusion.
Sarcastic disclaimer.
Why not install all binaries into /bin, /usr/bin, /usr/local/bin and be done with it, then? Why EVEN have another path, anyway? Better yet, why don't we follow Ubuntu and make sudo the default, make regular users have admin rights! Why do we even need root? What's that? Geeze, I mean why even keep an ancient file system layout?
sudo adds also security so that is also a bonus.
Valent.
Valent Turkovic escribió:
On Wed, Mar 26, 2008 at 10:12 PM, Gian Paolo Mureddu gmureddu@prodigy.net.mx wrote:
Jesse Keating escribió:
On Tue, 2008-03-25 at 12:02 -0600, Gian Paolo Mureddu wrote:
but being as /sbin paths are meant for administrative tasks, I actually do see having them as part of a regular user's PATH a potential security risk.
That's completely bogus. A "hidden path" offers 0 security. If you don't want your users running them, set the permissions on the binary, or better yet, have the binary check the EUID of the caller. If non-root, display that the command is for root users, but also allow the user to get --help and other usage or informational output from the command. Just don't allow non-root users to apply anything. There really is no reason I can think of to hide this crap in a different directory. It just adds needless complication and confusion.
Sarcastic disclaimer.
Why not install all binaries into /bin, /usr/bin, /usr/local/bin and be done with it, then? Why EVEN have another path, anyway? Better yet, why don't we follow Ubuntu and make sudo the default, make regular users have admin rights! Why do we even need root? What's that? Geeze, I mean why even keep an ancient file system layout?
sudo adds also security so that is also a bonus.
Valent.
Not much... users more often than not use very, very weak passwords easily crackable. With sudo enabled by default that imposes a serious security risk. Also there are things that can't be done with sudo like quick scripting of the CLI (say a one liner for-in loop with file operations, or at least I haven't found an efficient enough way to use them in sudo, hence I much rather prefer a dedicated root account). Certainly the paradigm of root is that of the system administrators, but it certainly is better to have the users and administrative tasks separated. Policy Kit looks like a more robust solution than sudo and still allows for a full blown root account. I guess the bottom line is with each paradigm there are compromises that have to be made... The point is "which compromises does Fedora want to do make"?
On Tue, Mar 25, 2008 at 11:27 PM, Christopher Aillon caillon@redhat.com wrote:
On 03/25/2008 06:30 AM, Valent Turkovic wrote:
I have a few ideas that IMO would make Fedora more usable as a general desktop and developer platform:
You want to look at the development spin, and propose changes there.
IMO this would be beneficial also for Fedora DVD and Fedora Live CD spin also. Why only developers spin?
Valent.
On Tue, 2008-03-25 at 11:30 +0100, Valent Turkovic wrote:
I have a few ideas that IMO would make Fedora more usable as a general desktop and developer platform:
- have gnome clipboard manager installed by default (glipper gnome applet)
This causes all sorts of bad problems. See e.g.: http://mail.gnome.org/archives/gtk-devel-list/2008-March/msg00053.html
On Wed, Mar 26, 2008 at 11:54 AM, Alexander Larsson alexl@redhat.com wrote:
On Tue, 2008-03-25 at 11:30 +0100, Valent Turkovic wrote:
I have a few ideas that IMO would make Fedora more usable as a general desktop and developer platform:
- have gnome clipboard manager installed by default (glipper gnome applet)
This causes all sorts of bad problems. See e.g.: http://mail.gnome.org/archives/gtk-devel-list/2008-March/msg00053.html
Can you explain this in plain english for non-developers. I have been using klipper and glipper on gnome for years without any issues so I don't get that "all sorts of bad problems" is causes because it works perfectly for me.
Valent.
On Wed, 2008-03-26 at 12:42 +0100, Valent Turkovic wrote:
On Wed, Mar 26, 2008 at 11:54 AM, Alexander Larsson alexl@redhat.com wrote:
On Tue, 2008-03-25 at 11:30 +0100, Valent Turkovic wrote:
I have a few ideas that IMO would make Fedora more usable as a general desktop and developer platform:
- have gnome clipboard manager installed by default (glipper gnome applet)
This causes all sorts of bad problems. See e.g.: http://mail.gnome.org/archives/gtk-devel-list/2008-March/msg00053.html
Can you explain this in plain english for non-developers. I have been using klipper and glipper on gnome for years without any issues so I don't get that "all sorts of bad problems" is causes because it works perfectly for me.
The thread I linked to contains a couple of real-life examples.
Basically it forces every selection change to be copied to another process, and the selection changes all the time and can be large. This can be very slow. It also means you're not able to do smart things when you cut and paste inside an application (which is the common operation, and which basically every application uses).
Alexander Larsson <alexl <at> redhat.com> writes:
The thread I linked to contains a couple of real-life examples.
Basically it forces every selection change to be copied to another process, and the selection changes all the time and can be large. This can be very slow. It also means you're not able to do smart things when you cut and paste inside an application (which is the common operation, and which basically every application uses).
So, what is the *proper* solution to this? Something changed in X? Or would just limiting the size of the object to be put into glipper be enough?
Matěj
On Fri, 2008-05-02 at 16:41 +0000, Matěj Cepl wrote:
Alexander Larsson <alexl <at> redhat.com> writes:
The thread I linked to contains a couple of real-life examples.
Basically it forces every selection change to be copied to another process, and the selection changes all the time and can be large. This can be very slow. It also means you're not able to do smart things when you cut and paste inside an application (which is the common operation, and which basically every application uses).
So, what is the *proper* solution to this? Something changed in X? Or would just limiting the size of the object to be put into glipper be enough?
I'm pretty well convinced by now that the only way to do c&p sanely is to do it with something other than X selections. There's just no way to overload selections with sensible behaviour while preserving all the semantics that unix nerds are used to. Take off and nuke the site from orbit.
I'm happy to add the feature to X if we know what we want it to act like in Gnome.
- ajax
desktop@lists.fedoraproject.org
-
Adam Jackson -
Alexander Larsson -
Benny Amorsen -
Bill Nottingham -
Christopher Aillon -
Colin Walters -
Debarshi Ray -
Gain Paolo Mureddu -
inode0 -
Jef Spaleta -
Jesse Keating -
Jesse Keating -
Jon Stanley -
Matej Cepl -
Nils Philippsen -
Seth Vidal -
Valent Turkovic