HAL deprecation

Anonymo · 2009-05-14 16:45:20

http://www.ubuntu.com/testing/karmic/alpha1

hal deprecation started
Karmic Alpha 1's underlying technology for power management and laptop Fn key maps was moved from "hal" (which is going to be deprecated soon) to "DeviceKit-power" and "udev-extras". When testing Alpha 1, please pay particular attention to regressions in those two areas and report bugs.

Is this going to happen in Arch?

mike_93 · 2009-05-14 17:13:15

Isn't this the kernel team's decision? And therefore likely to get to Arch pretty quickly (bleeding edge and all that)?

Zariel · 2009-05-14 18:21:17

Interesting, being moved to inside the kernel? Couldnt find anything about it via google, anyone have any more info?

scio · 2009-05-14 18:21:36

DeviceKit and DeviceKit-power are already in extra (http://www.archlinux.org/packages/?q=devicekit), feel free to use them. udev-extras (http://git.kernel.org/?p=linux/hotplug/ … ;a=summary) I assume we will get as soon as the kernel does.

The changes in Ubuntu are due to patching gnome applications to use it as Fedora did (http://fedoraproject.org/wiki/Features/ … ent_status)

Edited for links.

Edit: Oops, looks like gnome-power-manager already uses DeviceKit in upstream (http://www.archlinux.org/packages/extra … r-manager/) check out the dependencies.

Last edited by scio (2009-05-14 18:24:20)

dolby · 2009-05-14 20:25:09

What are you talking about? Arch doesnt even have hal.

ammon · 2009-05-14 21:27:47

Yeah, HAL sucks. We should move to devkit

anrxc · 2009-05-14 21:31:29

I hate the very idea, and I can't stand Ubuntu exactly for this - as a leader on the desktop others just follow blindly no matter what they come up with. I can't imagine what pain it will be to get rid of all this *kit crap.

lucke · 2009-05-14 21:38:09

Not an expert here, but it seems that DeviceKit will simplify things while providing additional features, like convenient access to SMART data.

bernarcher · 2009-05-14 22:43:07

I don't know if I'll like it. I wouldn't do if it only adds another level of abstraction, leading even further away from the real machine at hand. I already hate hal and all those 'kits around nowadays. But Xorg and Gnome and the like do force me into all this crap. (At least until I could afford more time to get things running the real KISS way.)

All this stuff might be worthwhile if you had to manage larger conglomerates of different systems. Or when you decide to keep your machine "just running". But I like to get to know all about my machine and remain hands-on in control.

Last edited by bernarcher (2009-05-14 22:44:23)

scio · 2009-05-14 23:06:44

anrxc wrote:

I hate the very idea, and I can't stand Ubuntu exactly for this - as a leader on the desktop others just follow blindly no matter what they come up with. I can't imagine what pain it will be to get rid of all this *kit crap.

Fedora and RedHat started this not Ubuntu. Gnome is adopting it upstream from their work, so Ubuntu is taking it.

anrxc · 2009-05-15 00:04:32

scio wrote:

Gnome is adopting it upstream from their work, so Ubuntu is taking it.

Soon after all others. With the notable exception of Slackware which threw the crap out years ago.
My function keys work just fine without HAL and without DeviceKit. They worked 10 years ago, they work today. But if I choose to ignore both of them my software will not work. I'm so sick of conforming the Windows converts, it's not making my enviroment any better. Where would the world be if RMS decided to write a free Windows clone.

Lexion · 2009-05-15 01:24:38

I just took hal out of my system. If you don't use a DE it's not hard. Just a quick edit to the xorg-server PKGBUILD in the abs and a 'sudo pacman -R hal'
So far, works fine.

@anrxc: +1

kensai · 2009-05-15 02:00:27

If that is the way the desktop Linux is going then I will follow through, is not like my system is going to break. We always go crazy about how Linux is implementing this, and blah, blah, but at the end it gets implemented, everyone forgets about it and no one cares anymore until another new technology is about to be implemented. That is the time the cycle starts all over again, go crazy, gets implemented, accept it, forget it.

iBertus · 2009-05-15 04:56:07

I guess there is always BSD for those that don't like the changes coming to Linux. Let's face it though, Linux will be pretty much OS X in a few years. That seems to be what the majority of DE devs want and the freedesktop project also fuels this by pushing invasive chages into Xorg and pressuring other projects to follow standards that are just annoying and pointless. I can't understand why people feel that Linux should be just like the other two major operating systems in graphical interface and annoying bells and whisles.

That said, maybe the *kits will be good in the end. I'll just be happy if they manage to make something that doesn't require some cryptic XML config file.

/soap box

iphitus · 2009-05-15 05:19:36

anrxc wrote:

I hate the very idea, and I can't stand Ubuntu exactly for this - as a leader on the desktop others just follow blindly no matter what they come up with. I can't imagine what pain it will be to get rid of all this *kit crap.

anrxc wrote:

scio wrote:
Gnome is adopting it upstream from their work, so Ubuntu is taking it.
Soon after all others. With the notable exception of Slackware which threw the crap out years ago.
My function keys work just fine without HAL and without DeviceKit. They worked 10 years ago, they work today. But if I choose to ignore both of them my software will not work. I'm so sick of conforming the Windows converts, it's not making my enviroment any better. Where would the world be if RMS decided to write a free Windows clone.

Quit beating on it just because you can, and because you don't understand what it does. So your function keys work without HAL -- they'll still work without HAL.

For years one of the biggest complaints about Linux has used to be hardware and hardware support. In userspace, dealing with hardware used to be a pain. Any application that did anything related to hardware had it's own techniques and code for gathering hardware information. Even if you got the driver for your scanner or other device working... then you had to get it working with the appropriate application.

If anything changed upstream in one of their information sources, be it /proc, /sys or otherwise, things got broken. Or if some new type of hardware was added, some extra information was added... things broke, not in one app, but many. Each distro had their own method of dealing with hardware detection. -- Even us, hwd/lshwd. This resulted in a pointless and incompatible duplication of efforts. I can recall one small bug in hwd, where it could not differentiate between some ipw2100/ipw2200 network chips. Same PCIID, different hardware/driver. Each distro and tool would have had to take this into account. Now scale this to the variety of different hardware, and multiply by n distributions.

HAL was a significant step forward. It finally created a central source of hardware information and made it trivial for any application to get a reliable source of information. If something changes, it's likely to be corrected within HAL quickly. Less time spent coding custom detection routines, increased consistency between distros, and in general, it makes things a lot easier...

Now for Device Kit. Instead of just blindly bashing it, read _why_ it's being implemented. HAL has been good, and fulfilled it's purpose, but it's not without it's warts. It's a replacement for HAL, and it will be simpler, cleaner and more modular (starting to sound more Arch like than HAL's design...).

http://lists.freedesktop.org/archives/h … 11560.html

Oh, and guess what. This is Arch, you have choice, this isn't forced on you. If you don't believe you need it, dont use it. What's the issue?

If that is the way the desktop Linux is going then I will follow through, is not like my system is going to break. We always go crazy about how Linux is implementing this, and blah, blah, but at the end it gets implemented, everyone forgets about it and no one cares anymore until another new technology is about to be implemented. That is the time the cycle starts all over again, go crazy, gets implemented, accept it, forget it.

Exactly. People here tend to have a pretty negative attitude towards anything new, because.... it breaks stuff. That's to be expected, Arch is the bleeding edge, duh. We get it when it's brand new, and when it's largely still untested and unpolished.

As a result people think it's crap, pay it out, and whine here on the forums. It's new and bleeding edge, what do people really expect? Maybe people should be filing bug reports instead of whining and trolling on the forums here.

I still see people comment "netcfg sucks", "netcfg doesnt work" or just give up and use something else when it doesn't work -- very few of these users bother to submit a bug report. I can only test on my own hardware, and I try to give each release a decent amount of time in [testing]. I can't guarantee it will work on everything, but it'd be nice if people helped me instead of paying my work out.

Last edited by iphitus (2009-05-15 05:40:08)

b9anders · 2009-05-15 07:00:45

I for one welcome this. Never really been satisfied with hal and this looks like a more promising implementation.

Don't understand the complaints. If you want things to work just your way, surely you wouldn't be using gnome in the first place.

dolby · 2009-05-15 09:33:53

anrxc wrote:

scio wrote:
Gnome is adopting it upstream from their work, so Ubuntu is taking it.
My function keys work just fine without HAL and without DeviceKit. They worked 10 years ago, they work today. But if I choose to ignore both of them my software will not work.

What are you talking about? Which software doesnt work without HAL?

PS. I wonder what a HAL deprecation means for xorg-server.

anrxc · 2009-05-15 15:38:49

iphitus wrote:

Quit beating on it just because you can, and because you don't understand what it does

I understand what it does just fine. What bothers me is how they do it on the user side. Take a look at xorg.conf and then at /etc/hal and tell me that I don't understand (or maybe this random search result). I also understand that XML is great for the Ubuntu user and his GUI administration tools, but it's not so great for the Unix user.

Even us, hwd/lshwd.

There are ways to do it, and then there is XML.

This is Arch, you have choice, this isn't forced on you. If you don't believe you need it, dont use it. What's the issue?

This software is becoming very important and "not using it" could mean a lot of work. How much work will be seen when KDE 4.3 comes out, Gnome is already lost for me. They both contain some important free software, and I have concerns.

Zariel · 2009-05-15 16:56:24

bleh, xml is not a readable config language!

Lexion · 2009-05-15 17:36:25

@ibertus: Then maybe I should use bsd.

R00KIE · 2009-05-15 17:45:46

If it is to make things easier and make them work better then I'm all for it.
Using xml for config files on the other hand is a big pain, it can allow for a better organization of things but still not pretty to see or easy to do bigger edits by hand ... not for me at least.

iphitus · 2009-05-16 00:01:47

anrxc wrote:

iphitus wrote:
Quit beating on it just because you can, and because you don't understand what it does
I understand what it does just fine. What bothers me is how they do it on the user side. Take a look at xorg.conf and then at /etc/hal and tell me that I don't understand (or maybe this random search result). I also understand that XML is great for the Ubuntu user and his GUI administration tools, but it's not so great for the Unix user.
Even us, hwd/lshwd.
There are ways to do it, and then there is XML.
This is Arch, you have choice, this isn't forced on you. If you don't believe you need it, dont use it. What's the issue?
This software is becoming very important and "not using it" could mean a lot of work. How much work will be seen when KDE 4.3 comes out, Gnome is already lost for me. They both contain some important free software, and I have concerns.

So it comes down to "i dont like XML" - Thus personal preference rather than any actual technical issue with the software.

I don't mind XML, but it depends how it's done. Openbox's config isnt bad at all. Most of the time there shouldn't be much need to hand edit them. I've never had to edit any of HAL's XML configs.

Eni · 2009-05-16 23:10:10

XML is not so bad but edit it with a traditional text editor is a pain in the ass.
Viewed as a tree, it shines.

damjan · 2009-05-17 01:04:30

The main problem with HAL and also ConsoleKit and PolicyKit and all the rules in dbus is that:
- all of them have not been documented enough or at all
- the existing documentation sucks
- they are hard to test, monkey patch or simulate (with shell scripts for ex.)

The problem is, while DeviceKit might be a better implementation of HAL, I don't see it solving those issues - especially documentation.

jacob_ · 2009-05-17 13:11:18

I think the idea is to replace parts of hal with dedicated daemons such as DeviceKit-power and DeviceKit-disks, move some stuff back into udev such as key maps, then remove the DeviceKit daemon. After that everything else can just use udev or input directly. Seems much simpler to me.

--

http://lists.freedesktop.org/archives/d … 00140.html:

If things work out as planned, DeviceKit, the main daemon, will go
away. Subsystem daemons will subscribe directly to device evens with
libudev. Udev/the kernel will do the event multiplexing/filtering,
there will be no D-Bus involved. It will be part of main udev, not
udev-extras.

DeviceKit-disks will use libudev, and take over the block device part
of HAL completely, and do the polling/mounting/disk-format/disk-setup
interface. At that point, the block stuff will be disabled in HAL.

DeviceKit-power will use libudev, and take over the all the
power/battery/UPS handling from HAL. At this point, the part of HAL
will be disabled.

Pulseaudio uses libudev, there will be no other common sound
interface, or totally stupid things like we pretend to do today for
audio with HAL.

X will likely be converted to use libudev directly instead of HAL.
Wayland the experimental next-generation Display server, which might
take over the low-level parts of X some day, already uses libudev.

Arch Linux

#1 2009-05-14 16:45:20

HAL deprecation

#2 2009-05-14 17:13:15

Re: HAL deprecation

#3 2009-05-14 18:21:17

Re: HAL deprecation

#4 2009-05-14 18:21:36

Re: HAL deprecation

#5 2009-05-14 20:25:09

Re: HAL deprecation

#6 2009-05-14 21:27:47

Re: HAL deprecation

#7 2009-05-14 21:31:29

Re: HAL deprecation

#8 2009-05-14 21:38:09

Re: HAL deprecation

#9 2009-05-14 22:43:07

Re: HAL deprecation

#10 2009-05-14 23:06:44

Re: HAL deprecation

#11 2009-05-15 00:04:32

Re: HAL deprecation

#12 2009-05-15 01:24:38

Re: HAL deprecation

#13 2009-05-15 02:00:27

Re: HAL deprecation

#14 2009-05-15 04:56:07

Re: HAL deprecation

#15 2009-05-15 05:19:36

Re: HAL deprecation

#16 2009-05-15 07:00:45

Re: HAL deprecation

#17 2009-05-15 09:33:53

Re: HAL deprecation

#18 2009-05-15 15:38:49

Re: HAL deprecation

#19 2009-05-15 16:56:24

Re: HAL deprecation

#20 2009-05-15 17:36:25

Re: HAL deprecation

#21 2009-05-15 17:45:46

Re: HAL deprecation

#22 2009-05-16 00:01:47

Re: HAL deprecation

#23 2009-05-16 23:10:10

Re: HAL deprecation

#24 2009-05-17 01:04:30

Re: HAL deprecation

#25 2009-05-17 13:11:18

Re: HAL deprecation

Board footer