Other distributions use hal, dbus, to manage hardware. I am a little
lost about that.

Does someone knows what are the real purpose of these programs. Is it
usefull only for Gnome programs? Does it make sense to just compile and
install it or have we to recompile / make aware other applications?
Doesn't the hotplug system present in Slackware offers similar
functionality?

Thanks for your help,

Olive

HAL is for support hardware-events and dbus is a message-handler that
can be used by applications. Have a look at :
DBus: http://freedesktop.org/wiki/Software_2fdbus
HAL: http://freedesktop.org/wiki/Software_2fhal

The major Problem on HAL is that it is broken on Slackware and you have
to do some tricky things to get it compiled. It also requires a Kernel
>2.6. Also Gnome wants a higher version then KDE supports (KDE 3.5.1 =<0.4.8, Gnome >0.5). So you can't have HAL for both (that's what i know so far, maybe someone want to correct me).

If you are happy without HAL+DBUS then you do not need 'em ;-)

DV

On 22 Mar 2006 05:51:10 -0800, "DarkVision" <darkvision@gmx.org> wrote:

>HAL is for support hardware-events and dbus is a message-handler that
>can be used by applications. Have a look at :
>DBus: http://freedesktop.org/wiki/Software_2fdbus
>HAL: http://freedesktop.org/wiki/Software_2fhal

DBus messaging looks like the windoze technique seeking a home in
the GNU/Linux desktop. I have no idea why anybody wants to reinvent
message-handling in user-space over an OS that already provides
several methods for inter-process communications.
>
>The major Problem on HAL is that it is broken on Slackware and you have

HAL is broken on any distro that doesn't massage kernel source to
match HAL. The trouble is that HAL development lags linux-kernel,
but is dependent on the kernel.

AFAIK l-k is moving to a cleaner event notifier (udev + friends) but
they still working through it, slowly... (Linux kernel development
is evolutionary, so some major changes take several releases)

Grant.
--
WinXP: Access Start->Turn Off Computer, then while holding Ctrl-Alt-Shift,
left click on Cancel. This terminates Windows Explorer...

On Thu, 23 Mar 2006 06:35:56 +1100, Grant <bugsplatter@gmail.com> wrote:

>HAL is broken on any distro that doesn't massage kernel source to
>match HAL. The trouble is that HAL development lags linux-kernel,
>but is dependent on the kernel.

More: just read a post elsewhere how HAL broke 'cos user ran yum
update with kernel* updates disabled --> mutual dependency.

Grant.
--
WinXP: Access Start->Turn Off Computer, then while holding Ctrl-Alt-Shift,
left click on Cancel. This terminates Windows Explorer...

olive wrote:

> Other distributions use hal, dbus, to manage hardware. I am a little
> lost about that.

Another poster told you where you can find more info about these.

On my Debian installs (which is most of my computers except a few laps where
I have Slack) both hal and udev work fine. Same with dbus. The concepts of
hal and udev are praised by engineers as a great improvement over what
Linux has been using (hotplug (which is incorporated into udev). However in
the deb world there seems to be an update every week to these programs
which some folks point to as evidence that they are always broken. Indeed,
lots of folks have had problems with them when plugging in pen drives.

From what I read udev (and hal) are touted as one of the magic bullets that
will help make Linux on the desktop a reality... in that it will mitigate a
lot of problems Linux has had in the past working with new plugin hardware.

However, while I'm sure P.V. will standardize on a 2.6 kernel in Slack 11, I
rather doubt he will go with hal and udev for another year or so... 11.1 or
11.2. Slackware is not known for being on the cutting edge. If you want all
the new stuff you need to run a more 'dynamic' distro such as one of the
Debian derivatives or Fedora. Slackware is targeted to those seeking a more
stable environment... along with RHEL/CentOS, Suse/Novell Enterprise, and
Debian Sarge (which is really stable... and really OLD!)

anc

Grant wrote:
> On 22 Mar 2006 05:51:10 -0800, "DarkVision" <darkvision@gmx.org> wrote:
>
>
>>HAL is for support hardware-events and dbus is a message-handler that
>>can be used by applications. Have a look at :
>>DBus: http://freedesktop.org/wiki/Software_2fdbus
>>HAL: http://freedesktop.org/wiki/Software_2fhal
>
>
> DBus messaging looks like the windoze technique seeking a home in
> the GNU/Linux desktop. I have no idea why anybody wants to reinvent
> message-handling in user-space over an OS that already provides
> several methods for inter-process communications.
>
>>The major Problem on HAL is that it is broken on Slackware and you have
>
>
> HAL is broken on any distro that doesn't massage kernel source to
> match HAL. The trouble is that HAL development lags linux-kernel,
> but is dependent on the kernel.

Even on a distro supporting HAD/dbus in a maintained way, like Gentoo,
it's functionality is, well... a Bit problematic.
I've had only 1½ month on a new job to play Gentoo, and haven't invested
too much time on the 'automatic hotplug' feature. It seems to detect
some devices, but I still depend upon creating fstab entries.
Maybe it's just me, what do I know...
I still haven't worked out how it'll solve multiple hotplug mounts
automatically. I mean, there's only one /mnt/hotplug (or /media)
mountpoint, unless one creates own entries - but that kinda is a bit
against the idea that it should all be tranparent to da user...

I'll need to peek closer at resent comments on a.o.l.g about the
hotplug/coldplug combo.

--
Kind regards,
Mogens V.

On 2006-03-22, Mogens V. <NOSPAMmogensv@vip.cybercity.dk> wrote:
> I still haven't worked out how it'll solve multiple hotplug mounts
> automatically. I mean, there's only one /mnt/hotplug (or /media)
> mountpoint, unless one creates own entries - but that kinda is a bit
> against the idea that it should all be tranparent to da user...

The idea of /media is to make multiple mountpoints, e.g. /media/usbdisk,
/media/usbdisk2, etc. This is what Red Hat and others do.

-- Daniel

On 2006-03-22, ANC <anc@not_to_beadams-blake.not_tobe.com> wrote:
> I have Slack) both hal and udev work fine. Same with dbus. The concepts of
> hal and udev are praised by engineers as a great improvement over what
> Linux has been using (hotplug (which is incorporated into udev).

Back in the days when I worked for Libranet I read a lot of HAL code to
solve issues. Back then it was quite ugly (there was mounting code in
an hardware abstraction layer), and not very secure (it ran as root,
and provided services to random applications). I am sure that it has
improved a lot since then, but it has never been clear to me
what problem it is trying to solve. The goal of HAL is to provide a
generic abstraction layer for applications; somebody still has to
point me to an application that needs a *generic* layer (with a lot
of different attributes). For instance, for a user-friendly desktop it
is important to know what block devices are plugged or unplugged, but
it does not really matter whether a USB authentication token is plugged.
Besides that the same thing can be archieved by the current event
notification mechanisms: e.g. by using a hotplug script or connecting
to a netlink socket for hardware events. From my point of view, it
looks like the whole udev/HAL/D-BUS system is overdesign.

At this point it would probably be best to make standardized kernel
notification framework for all widely used Unices.

Of course, your mileage may vary.

> From what I read udev (and hal) are touted as one of the magic bullets that
> will help make Linux on the desktop a reality... in that it will mitigate a
> lot of problems Linux has had in the past working with new plugin hardware.

Rather a hack to work around the problems that exists between the keyboard
and the display . And if Linux/UNIX really wants to go down that road,
it is no problem to do it through hotplug scripts. In fact, this is what
Debian's usbmount script does. It looks a lot like Windows: whenever
you plug a drive it is mounted and visible. And it is a lot simpler and
cleaner than HAL and GNOME Volume Manager (or the KDE equivalent).

> However, while I'm sure P.V. will standardize on a 2.6 kernel in Slack 11, I
> rather doubt he will go with hal and udev for another year or so... 11.1 or
> 11.2. Slackware is not known for being on the cutting edge.

It is a stable and safe haven that users can build their systems on.
That's why the Slackware Linux community is constantly expanding, maybe
not in percentage, but in absolute numbers. There are a lot more Slack
users on many forums out there than a few years ago.

The difference with Slack and cutting edge distributions is that the
current and next stable version will work well without brokenness
everywhere. It will work tomorrow, in a year, and in five years.

> the new stuff you need to run a more 'dynamic' distro such as one of the
> Debian derivatives or Fedora. Slackware is targeted to those seeking a more
> stable environment... along with RHEL/CentOS, Suse/Novell Enterprise, and
> Debian Sarge (which is really stable... and really OLD!)

Jikes, sorry for starting to rant, we seem to agree on this point .
Oh, well. So many years, systems, and graphical envirnments have gone
by. How many of us do still use CDE? UNIX stayed the same. Slackware
Linux is the best 1970, 1995, and 2020 has to offer.

-- Daniel

Grant wrote:
> On 22 Mar 2006 05:51:10 -0800, "DarkVision" <darkvision@gmx.org> wrote:
>
>>HAL is for support hardware-events and dbus is a message-handler that
>>can be used by applications. Have a look at :
>>DBus: http://freedesktop.org/wiki/Software_2fdbus
>>HAL: http://freedesktop.org/wiki/Software_2fhal
>
> DBus messaging looks like the windoze technique seeking a home in
> the GNU/Linux desktop. I have no idea why anybody wants to reinvent
> message-handling in user-space over an OS that already provides
> several methods for inter-process communications.
>
>>The major Problem on HAL is that it is broken on Slackware and you have
>
> HAL is broken on any distro that doesn't massage kernel source to
> match HAL. The trouble is that HAL development lags linux-kernel,
> but is dependent on the kernel.
>
> AFAIK l-k is moving to a cleaner event notifier (udev + friends) but
> they still working through it, slowly... (Linux kernel development
> is evolutionary, so some major changes take several releases)
>
> Grant.

Yeah, that's why I miss the 2.5.X kernel. Today, the 2.6.X is both
"production" and "testing". This is bad, and why I continue to use
2.4.X kernels.

Thanks for your answers. From rour answers; I believe I do not need
these features.

Olive