New standard proposal

[David Zeuthen]

On Fri, 2003-09-26 at 19:26, Carlos Perelló Marín wrote:
> The option to mount devices in their home directory is something
> difficult and really insecure... The main problem here is, you will not
> be able to mount anything inside an NFS home if you have the root-squash
> option enabled. Also, you should check carefully that the mount is done
> where it should (symbolic links pointing to core directories, for
> example).
> 

Yes.. but it is only an example; in retrospect maybe a bad one. The
draft spec lets the desktop environment (or another application) decide
where to do this.

FWIW, I regard where to mount devices (cf. the other discussion) a pure
desktop environment decision (and the HAL draft spec reflects this). The
important point is really that if GNOME wants to mount a CD or
USB-storage somewhere, then KDE applications can still reliably find out
by using libhal (and vice versa). 

(GNOME and KDE are of course only examples)

And of course there will be an (optional) Storage.VolumeName property
for storage devices that support this - the thing is that I (and others
I suspect) just rarely think in terms of volume names of CDs etc. so I
forgot it in my the spec. My bad.

In general, I really don't like hard-coded paths like /Volumes or /tmp -
it leads to #ifdef hell in DE application land unless you fully control
the OS (or use an abstraction layer ;-)).. 
Which, for GNOME, XFCE, KDE, Mozilla, OO.org, Java etc., isn't the case.
MS and Apple are whole different story though.

And finally - if users are clever enough to use a console, they are also
clever enough to type lshal and get the information. Or search the
filesystem themselves. I agree it would be good to standardize moint
points amongs DE's, but only in form of recommendations.

Your points about Hybrid CD's, in another thread, are interesting. You
should formulate it in relation to the HAL draft spec under category
Storage - more work on this is very welcome.

> > > Sorry I did not start to look at it, but I know about a script [1] that
> > > tries to automatically mount usb-storage devices.
> > > 
> > 
> > I'll look into this, but I still fear that we will have to ask the user
> > to tell what device to mount in the initial version of the GUI.. But for
> > a proof of concept as this is, I suppose that is fine enough. After all,
> > before this is production ready, distros will already be shipping 2.6 (I
> > hope).
> 
> Hey, I want the Volume Manager daemon working soon (soon == no more than
> a year), you cannot hope that GNOME/KDE/XFCE/others will use HAL
> assuming they are always under Linux 2.6, it should work without
> problems under *BSD and other Unix.
> 

Hey, I want this working on 2.4 as well! And soon.. And of course
support of other OS'es was also a prime objective from the beginning -
and it still is. It's kind of in the freedesktop.org mission statement.

But what I have learned up until now is that it's impossible to get that
/dev/sda1 that represents e.g. my Lexar CF Reader in a generic, sane and
reliable way using Linux Kernel 2.4. It kind of sucks. I will be a very
happy man if someone can prove me wrong.

So, right now I ask the user to select the /dev/sda1 (or whatever) in a
GUI application (the gnome_hal_watcher I'm currently working on), simply
because of this. I'd rather ship software with limitations than software
with annoying bugs that only may run on certain distros and/or PC's. It
kind of sucks.
(I run OS'es with a Linux 2.4 kernel on most of my boxes like most other
people.)

But hey, there are other kernels than Linux out there! The FreeBSD
kernel should do the right thing I've been told. (haven't checked myself
though - yet!).

Importantly, supporting FreeBSD and others should be easy: it's simply
modifying the device info file to put hal_freebsd_mount_usb_storage.sh
into BootProgram instead of hal_linux_mount_usb_storage.sh.. 

(and ofcourse porting the HAL code to FreeBSD, but that should be
doable)

And since these device info files support if/then/else stuff we can
still ship a single file per device. Which I think is nice.

Cheers,
David