Learn about three new features coming to Enterprise Linux (D-BUS, HAL & Network Manager) that are designed to make hardware “just work.” The technologies that make this possible were inspired by Havoc Pennington’s paper on this topic.
Coming soon to Red Hat Enterprise Linux
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
HAL is at 0.4 and D-Bus is at 0.23, how is this close to 1.0?
How can they ship something at such an incipient stage? What about stability, none of these even have a stable API yet and have never undergone serious real world testing.
Fedora is Red Hat’s testing ground for new technologies. I’m sure this stuff will make it into Fedora first where it will certainly get tested.
> How can they ship something at such an incipient stage?
Already in FC3 :
$ rpm -q -a | egrep -i “(dbus)|(hal)”
dbus-0.22-10
dbus-python-0.22-10
dbus-x11-0.22-10
dbus-glib-0.22-10
hal-cups-utils-0.5.2-8
hal-0.4.6-1.FC3
hal-gnome-0.4.6-1.FC3
Ubuntu also have dbus/hal.
I want seLinux in ES and 2.6 You’re usually putting this on GOOD HARDWARE, not crap.
0.4 doesn’t mean that it is in beta, it just means that it doesn’t have the amount of features in it to justify a 1.0 tag. I am sure they’ve got a list of features they wish to implement before 1.0’ing it, but until then, the current HAL is quite stable in its current form.
HAL is very useful for desktop usage (i would not trust it on a server, besides servers shoould not run unneccery software). i would love to just plug and pray my different hardware 🙂
the d-bus system makes sense, too. kudos to the rad hat team 🙂
$ rpm -qa | egrep -i “(dbus)|(hal)(networkmanager)”
(as above, plus)
dbus-devel-0.22-10 (I should erase this package)
NetworkManager-gnome-0.3.3-1.cvs20050112.1.fc3
NetworkManager-0.3.3-1.cvs20050112.1.fc3
My Fedora box is stable – I dont think Red Hat would include something inherently unstable into RHEL – the support costs of such an action would be significant.
And will they be included in other distros that use automatic hardware setup tools from Red Hat?
How can they ship something at such an incipient stage?
Redhat develops these programs themselves. I’m pretty sure they know a little better than you is it on incipient stage or not.
No.
> And will they be included in other distros that use automatic hardware setup tools from Red Hat?
They are upstream project (freedesktop.org).
HAL, D-BUS, and Network Manager are all GNOME 2.8 components. After three releases and months of use in other distros, GNOME 2.8 is more than ready for RHEL.
If the new components fail, admins will have to fallback on command-line network tools and manually mounting optical media and pluggable storage. Big deal. It’s not like RedHat is replacing any existing tools. This is new functionality.
The people who would worry about these new programs threatening stability wouldn’t be running GNOME on a server anyway, so I really don’t see how this is anything but an improvement for desktop users.
Thanks for the info my_name.
Do HAL ( http://freedesktop.org/wiki/Software_2fhal ), Kudzu ( http://rhlinux.redhat.com/kudzu/ ) and Discover ( http://componentizedlinux.org/discover/downloads/ ) all do the same job? Could any of them be ported to other OSes? Why does Red Hat use both Kudzu and HAL?
Kudzu and discover have the same goals. to discover and (auto) configure devices.
hal however is completely different. its a hardware abstraction layer so that applications can access hardware properties in a OS independant (unix and unix-like systems) manner from a single source
hal however is currently linux specific (not by design) and not ported to freebsd or solaris thou work is on the way.
gnome already uses hal to a good extend and kde support is expected on version 4.0
A bit late isn’t it?
are there any known plans for SUSE 9.3/10.0 to include Hal and Dbus, and what about SELinux too?
Kudzu run at boot time (configure /etc/modprobe.conf eth0, …). Kudzu is not design for hotplug devices.
HAL is a deamon. HAL (with hotplug) is mostly for hotplug devices.
So from whose point of view does HAL make “hardware just work”? The software engineer? The user? Both? To me, hardware just working usually means autoconfiguration.
Does GNOME 2.8 work properly on non-Linux OSes, if HAL is only supported on Linux ATM?
HAL (with hotplug) is mostly for hotplug devices.
—-
not true. hal is not limited to hotplug devices in anyway. its a generic hardware abstraction layer
“So from whose point of view does HAL make “hardware just work”?”
user. for the developers its a convenience library
“Does GNOME 2.8 work properly on non-Linux OSes, if HAL is only supported on Linux ATM?”
the major portion is gnome volume manager which is a module of gnome 2.8 which wouldnt work as expected without the *bsd and other OS developers port hal to the respective systems
Mockup will use DBUS and HAL
http://www.osnews.com/story.php?news_id=9289
http://www.mockup.org
RE: new features
<<HAL, D-BUS, and Network Manager are all GNOME 2.8 components.>>
NetworkManager isnt part of Gnome 2.8
RE: @godbert
<<gnome already uses hal to a good extend and kde support is expected on version 4.0>>
KDE 3.4 will use HAL (media:/)
Another IPC mechanism? There’s probably a dozen already available, and some are even portable. D-BUS sounds like an NIH project.
dbus is an attempt to fix the problems with ORBit and DCOP so that both KDE and GNOME can use the same IPC/messagebus libraries and have a hope of talking to each other, and be lightweight at the same time. Changing DCOP or ORBit to do that would be much harder work, as woudl forcing either GNOME or KDE to use the other’s technology.
Furthermore, neither DCOP or ORBit really take advantage of features like SELinux for enhanced security.
and:
d bus, is being jointly developed between KDE and Gnome core devs
-Nex6