John Woodhouse posted on Sun, 08 May 2011 10:33:50 -0700 as excerpted:
> Thanks Duncan.
> Does anyone know of a source of a sort of overview on what hal, udev and
> what ever do for kde.
I suppose there's articles on it, but I don't know of them. However, I
can tell you, in a general, rather hand-wavy kind of way, at least.
hal was a piece of system software that formerly (and still on those
systems where it isn't fully replaced as yet) gave user-level access to
various hardware devices. As such, it incorporated various functions such
as hotplug detection of removable drives, auto-mount of the same, hotplug
detection and plugging for input devices (mouse/keyboard/etc) for xorg,
interfacing with the system reboot/shutdown/hibernate controls, and
brokering all the normally superuser permissions required for these
functions such that a mere user could access them.
The biggest problem with hal from a user/admin perspective was the
difficulty in configuring all this. Configuration was done thru not
necessarily well documented XML based *.fdi files, so if one wanted to
change a security policy for auto-mounting devices or feed it non-default
options for the xorg input drivers (say you had a touchpad or multimedia/
internet keyboard and wanted to use its advanced functionality), not ONLY
was the user forced to do the usual google for appropriate config
information, but they were ALSO expected to be able to edit the XML based
*.fdi files to accomplish their desired config changes, WITHOUT screwing
up the XML formattting, thus potentially leaving themselves without ANY
keyboard/mouse in xorg. While this is certainly an irritation for geeks,
it made the configuration effectively hard-coded to distribution defaults
for ordinary users, who had no hope at all of being able to properly edit
an XML formatted file. All this for a bit of infrastructure that was
SUPPOSED to make things EASIER for normal users, automating hotplugging,
etc.
>From a developer perspective hal ended up similarly inflexible, very
likely because it forsook the tried and true Unix design philosophy of do
one thing and do it well (and make the config simple-to-document and
simple-to-edit plain text files in something similar to the standard *.ini
file format, sections, key=value pairs, etc).
But even as hal was being forced sideways down the gullets of various
distros, admins and users, udev was already duplicating much of hal's
device detection and hotplugging, with *FAR* easier to manage
configuration files. As it became clear how impossibly horrible hal was
to actually do anything with, simpler solutions for its other components
popped up as well. At the time Apple-mania seemed to be affecting many of
the folks working on these projects, and they ended up with *kit names,
similar to Apple's. We still have polkit (shortened from an earlier
generation policykit), to manage permissions and policies, but devicekit
foundered and was replaced by udisks and upower, patterned after the udev
name.
So now we have multiple much simpler components interacting together to do
what hal did. polkit enforces security policies. udev in cooperation with
the kernel manages device detection and low-level hotplugging (creating
the device nodes and triggering plug-events that the other components
listen for). udisks manages disk automounting. upower manages sleep/
hibernate/reboot/shutdown. And dbus messages are used for communication
between many of these components and the (kde in our context) front-ends
that form the user-facing management interface.
Now for Unix traditionalists like me, many of these functions,
particularly the auto-mount functions, aren't really necessary and in fact
may be considered security holes at some level. If we want something
mounted, we'll very well tell the system we want it mounted, thank you
very much! And if we want ordinary users to be able to be able to mount a
device, that's a simple enough setting in /etc/fstab. So we don't need
and in some cases deliberately disable some of this functionality. But
it's nice for the ever-clicky and malware-prone (l)users...
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
