From owner-freebsd-questions@FreeBSD.ORG Wed Dec 31 04:16:02 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53D36175 for ; Wed, 31 Dec 2014 04:16:02 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F366B3E58 for ; Wed, 31 Dec 2014 04:16:01 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id sBV4FtOh085369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Dec 2014 21:15:56 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id sBV4Ftc6085366; Tue, 30 Dec 2014 21:15:55 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 30 Dec 2014 21:15:55 -0700 (MST) From: Warren Block To: Polytropon Subject: Re: Xwindow advise needed In-Reply-To: <20141231044147.fe7a9983.freebsd@edvax.de> Message-ID: References: <55358.128.135.70.2.1419874589.squirrel@cosmo.uchicago.edu> <20141229235045.b8156cdf.freebsd@edvax.de> <20141231044147.fe7a9983.freebsd@edvax.de> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Tue, 30 Dec 2014 21:15:56 -0700 (MST) Cc: freebsd-questions@freebsd.org, galtsev@kicp.uchicago.edu X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 04:16:02 -0000 On Wed, 31 Dec 2014, Polytropon wrote: > The problem is not the automounter itself. It's its > integration with the GUI elements, in two ways: > > 1st, when the automounter mounts a device which has > been appearing, either by a label or by a device name, > this new mountpoint must be "picked up" by the GUI > and be shown on the desktop. > > 2nd, there must be a desktop action to unmount the > device, and for those which support it, eject it. At one point, I wrote my own automounter. xfce or Thunar can add menu entries, and I added one for unmount. > This is what "ordinary users" seem to expect. > > I didn't get that working in Xfce, and also failed > with Gnome 2 (even though I followed the advice on > the project page exactly). I somehow got the additional > port automounter to do what HAL + DBUS were unable > to do. To perform the umount, I still had to replace > the _binary_ with a script, including a terrible tale > of sudo, -f, and camcontrol eject. That was the time > when I stopped worrying and love the insanity. :-) > > I'm quite confident that, given a proper configuration > and permissions, this _won't_ be neccessary in Xfce. > > By the way, how about suggesting Lumina, the upcoming > "unified" GUI project for FreeBSD? Does it integrate > already with automounter or autofs? No idea, have not even looked at it. > Just to add a short note about automounting in general: > While this is a useful feature for most _personal_ desktop > computer usage, there might be situations where it can > cause immense trouble, like people stealing data, or > putting (incriminating) data on your system. It's also > dangerous when you attach a device that you want to > perform forensic analysis or data recovery on - one > stupid write, and you're out of luck. That's why I'd > like to see a more differentiated approach in _any_ of > the desktop environments supporting mounts: > > a) signal the appearing of a new device to the user, > who can then select to mount it or just to leave > it as is; or > > b) automatically mount a new device and show an icon > shortcut to the mountpoint. The first could work for all users, really. > The user should be able to select which policy to apply. > For optical media, _blank_ optical media, it gets even > more funny, let alone music CDs... :-) file(1) can be used to detect many kinds of filesystems and binaries. It could be used to at least suggest mounting or playing options. How important this is really depends on the user. Some would say that a GUI for wireless/wired network configuration would be more useful.