[PATCH_ES_] New storage methods for partitioning and formatting

Richard Hughes hughsient at gmail.com
Sat Nov 18 01:42:43 PST 2006


On Fri, 2006-11-17 at 22:31 -0500, Doug Goldstein wrote:
> S.Çağlar Onur wrote:
> > 18 Kas 2006 Cts 03:56 tarihinde, Doug Goldstein şunları yazmıştı: 
> >> Well then I don't want HAL on my desktop.... nor server... nor any system.
> > 
> > Then maybe you should not use hal on your desktop, nor on your server nor on 
> > your any server, but be sure others will do.
> 
> And unfortunately if other applications (like GNOME) require it, then
> you have to have it. HAL does not need to be everything + the kitchen sink.

No, but it's a nice Abstraction Layer.
 
> >> No person should have their hands held and the system restricted from
> >> them. You can wrap them with a pretty shiny interface within
> >> Gnome/KDE/*desktop but leave this out of HAL... It's ENTIRELY unnecessary.
> > 
> > There is no need to duplicate the same work on all single desktop environment.
> > 
> > 
> 
> What's duplicated? "$ mke2fs -j /dev/hda3"

How do you do that if you are not root? How do I specify on the desktop
"User is allowed to format floppies but not hard disks"? How do I
know /dev/hda3 is not my swap partition? How do I know if the command
succeeded or failed? How do I translate that error to the user in a
localised way?

My girlfriend just wants to put a floppy in the drive, right click, and
format. She doesn't want to enter the root password (which she doesn't
know BTW) just to do this.

> If you're talking about UIs (which is what I was saying) then every
> desktop will still need a UI to the HAL API rather then to standard
> system() call-outs.

Which is trivial and lightweight to do - you can do it in any DBUS
binding for pretty much any language. Also define "standard system call
outs..." do you mean assuming mkfs.ext3 (version 1.39) is in sbin?

Say ext4 is released. Every desktop bit of formatting software has to
check for the existence of /sbin/mkfs.ext4 and if it exists, then use
the correct options (after the desktop program has made assumptions
about what options are sane), and then if it fails, scrape the stderr
output, try to find some common text, and try to localise it. Bad bad
bad.

>  So now it'll be more complicated by having to wrap a
> HAL & D-Bus connection then just calling system() with the proper
> parameters.

Not complicated at all - in fact it's easier. You don't want to know the
pain that comes of writing a desktop application that calls commands as
the root user. You get errors handled in a sane way, in a secure and
easy to audit channel. You write common code once in HAL (which can be
as complicated as hell) and then you can get a nice simple abstracted
method for normal desktop use. And you can still use your shell commands
if you know what you are doing. Win win win.

As a matter of point, I *am* a desktop component developer who finds HAL
very useful. I can understand your LFS attitude, but this is exactly
what the fdi files are meant to give you the freedom to change - you can
stop the cpu-freq addon from launching if you want to set policy
yourself, and you can prevent the formatting methods by commenting out
the method launcher code - or not even ship the fdi. If you are triply
paranoid, you can even remove the permissions on the DBUS connection for
that interface in /etc/dbus-1/system.d/hal.conf as they are all
different for this purpose.

I really don't understand your lack of understanding about desktop
console use - do you actually drop to the shell and type mkfs to floppy
disks? Or do you have to enter the root password in a GUI app? Or is
that GUI formatter you use setguid? Yuk.

Please think about desktop users who don't know shell. You can disable
as much as you like on gentoo (which is fine BTW, as you'll know what
you are doing) but please don't say feature X shouldn't be in Y without
better reasoning than "...just calling system() with the proper
parameters..."

Thanks,

Richard.




More information about the hal mailing list