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."
Post a Comment
Member since:
2006-09-22
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?
Member since:2006-09-22
Member since:
2008-11-19
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 ...
Member since:2005-07-06
I think you should read
http://lists.freedesktop.org/archives/hal/2008-May/011560.html
Member since:2008-11-19
Member since:2005-07-06
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
Member since:2008-08-19
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...
Member since:2006-02-15
http://lists.freedesktop.org/archives/hal/2008-May/011560.html
A very helpful link, thanks 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.
Member since:
2009-04-18
Member since:2005-06-29
The kits came from BeOS originally I believe.
http://en.wikipedia.org/wiki/BeOS_API
Member since:
2006-01-14
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.
Member since:
2008-05-26
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.
Member since:2008-07-15
Member since:2005-07-24
Member since:2008-07-15
Weren't we just discussing Pulse Audio the other day? "
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.
Member since:2005-07-24
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
Member since:2005-07-06
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.
Member since:2005-07-24
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
Member since:2005-07-06
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.
Member since:2005-07-06