Red Hat, which started the HAL project many years ago, has deprecated it in favor of a new initiative called DeviceKit. David Zeuthen, primary developer of DeviceKit, has posted on his blog about the work done by the Red Hat Desktop team in Fedora 11 for improving the storage layer in GNOME by taking advantage of DeviceKit. This includes desktop notification if your hard disk is failing, a desktop utility to handle RAID and LVM storage, a replacement for the venerable gfloppy, and many others. Look at his blog for a number of screenshots showing the details. “The GNOME 2.26 release in Fedora 11 will ship with a completely different stack for handling storage devices. The plan is to land all this work in the upstream GNOME 2.28 release and most of that work is done already.”
But I like this. I know it’s kind of reinventing the wheel… but since this technology is likely to be embraced by other distros (I know Ubuntu will), the time might come where GNU/Linux finally features a set of nice, unified system APIs to develop with.
Maybe I’m being too optimist?
I completely misundesrtood what DeviceKit actually is. And I hate the edit time limit with the passion of a small star. Please disregard my stupidity.
What can DeviceKit do that HAL cannot, due to the latter’s “design limitations” ?
If it’s just to make disk diagnostics easier this seems like quite a radical change. OTOH, if the main impetus is to shift more power management functionality to a lower level in order to be more desktop-agnostic, there’s more value in that.
As a Gentoo user, I wonder what headaches I might enjoy in the future because of this; ESD/ALSA-to-PulseAudio is already looming on the horizon …
I think you should read
http://lists.freedesktop.org/archives/hal/2008-May/011560.html
Thanks for the link.
Poor scaling and Linux-centrism are definitely problems.
Definately, hopefully what we’ll see is OpenSolaris and the *BSD’s scrap HAL in favour of getting behind DeviceKit. OpenSolaris has implemented HAL, but I do think that the best thing they could do is move to DeviceKit due to the buggy nature of HAL that I’ve experienced in the past.
I had a look just then:
http://blogs.sun.com/jeffcai/entry/device_kit_will_replace_hal
It appears that GNOME is also behind DeviceKit so as HAL is gradually wound down, DeviceKit is coming in and gradually replacing HAL so that eventually HAL can be fully removed. I for one welcome our new DeviceKit overlords
Back ontopic, when one uses powertop from Intel, you can see the power sucking effect of HAL doing its polling constantly. Once HAL has been replaced with DeviceKit, hopefully we’ll see improvements in battery power management.
Edit: According to their official website:
http://www.freedesktop.org/wiki/Software/DeviceKit
it is designed to fully replace HAL – so I guess HAL right now is in a state of ‘treading water’ until DeviceKit is ready to fully take over and replace it.
Edited 2009-05-09 04:16 UTC
Yeah, HAL is pretty much in maintenance mode, has been for a while now – the last ‘release’ was a candidate build just before Christmas, mostly fixing things like compatibility with newer udev and kernel…
Looking forward to seeing DeviceKit become production-ready…
It sure sounds like DeviceKit is the step in the right direction,and it probably won’t take long for it to catch on and get spread to other distros.
DeviceKit, PackageKit, ConsoleKit, babyKit,…
is redhat trying to standardize Linux, or to imitate Apple ? (IOKit, …)
But I want less headache with the sound in my Linux…
The kits came from BeOS originally I believe.
http://en.wikipedia.org/wiki/BeOS_API
Its about time they built some storage management tools into Red Hat. Large disk support needs work. It works out of the box, but it isn’t very well layed out. You sometimes have to drop to command line to do things. Anaconda will let me set up raid, yet I dont think there is a tool to do it once the OS is loaded.
The current release of Ubuntu, 9.04, is the first I can remember in a long time that didn’t ship with some sort of HAL problem. It seems that, now that HAL is finally working properly from the get-go, it’s being replaced with something different.
If DeviceKit is going to be an improvement, then that’s great. We’ll have to wait and see.
Yup, welcome to the world of Linux.
Weren’t we just discussing Pulse Audio the other day?
Edited 2009-05-11 04:33 UTC
Not the other day… more like last month, I think it was… and I never said Pulseaudio was production ready in any case, in fact I said it had a lot of potential but it should have been held off for a while longer imho. I would think then that you’re only supporting my comment above by bringing that up, so thanks.
To some extent, yes. The kernel has pretty well stabilized. The most reckless and annoying instances of the “New and Shiny” syndrome are now mostly a user space thing. And there, mostly confined to the desktop realm. But it *is* a real issue, nontheless. Just when sound, or hotplug, or whatever, becomes stable enough to trust, Fedora invents a new problem and releases a new, buggy, and incompatible software layer to “fix” the “problem”, generally accompanied by much self-congratulations and back-patting.
Remember, I administer 80 or so Linux business desktops, and get
caught in these quagmires when they ooze in my direction.
Edited 2009-05-11 20:59 UTC
Fedora didn’t invent PulseAudio. PulseAudio was developed by Lennart as a student and was already being used by distributions as a independent upstream project before Red Hat hired him to continue development on it.
Individual distributions choose to make PulseAudio the default on their own and if you think your distribution of choice made the wrong decision, talk to them instead. It is very silly to blame Fedora because you don’t like it being the default in Ubuntu.
Desktop is hardly the only place where there is ongoing new developments and reimplementations. Just this week, LWN covered a reimplementation of devfs that is going into the Linux kernel soon. In fact, compared to amount of new development in the Linux kernel, desktop is small potatoes. It is usually just more visible. That’s all.
Yes, I read that article with some dismay. Devfs again, just when udev has settled down. And for what? A second or two of boot time. And Arjan, who is something of an expert on that topic, says it is absolutely unnecessary even for that. At any rate, I was left with the impression that it was not a done deal, and may or may not end up in the kernel. And I was rather hoping for *not*.
Edited 2009-05-12 02:15 UTC
Arjan may well be right but I doubt it is going to prevent the code from going on. Generally, subsystem maintainers get to decide and it seems they are in favor of it.
My long standing opinion is that “no policy in the kernel” was a stupid reason and it is not good enough to deny devfs. Sure, the original implementation was crappy but somebody did come up with a much better one. Linux kernel developers should have just merged that. udev only helps to override existing kernel default device names. Every other Unix/Unix like system seems to have a devfs. Linux can’t be that special.
I’m all for bringing devfs back, personally I found it one of the better features of the initial 2.4.xx series of kernels especially when most drivers were devfs-ready (before that, it wasn’t as easy to work with). It’s more than a second or so of boot time, it avoids wear and tear on the disk from creating and removing device nodes, especially good for SSDs. Why should device nodes be physical files on the disk? Almost every other *NIX (FreeBSD, Solaris, etc) had moved beyond that ages ago, and Linux seemed well on its way to doing the same until Old Greg “arsehole” KH stuck his nose in and basically all but forced the devfs developer to leave by being his usual self and thrust udev upon us. That, in my opinion, was the reverse of a good decision, and if they bring devfs back I will most certainly be pleased.
And before anyone mentions it… yes, I know you can mount /dev in a ramdisk and let udev work there, but why? There’s little point to that when it should all be in ram to begin with and still requires /dev to have inodes in it for basic operations.
Yep. You’ve now discovered the reason why a desktop like KDE uses abstraction layers like Phonon and Solid. They might say that it is stable but this will take quite a while to get stable and working in a practical sens.