Spread desktop on television - 4.6.0 problems

[Duncan]

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.