HAL deprecation

bernarcher · 2009-05-17 13:23:29

Eni wrote:

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.

Just had a look at the conglomerate XML editor from the AUR. First impressions are positive.
Are there any experiences with conglomerate?

litemotiv · 2009-05-17 14:08:32

iphitus wrote:

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.

The main problem for netcfg i think is that a working connection is something people want/need very early on, so in practice the majority of people running into problems with it are newbies, first time installers. When they try out Arch they are pointed to netcfg very early on in the Beginners Guide, and i personally can't imagine anyone at that stage considering filing bug reports when they encounter problems. Something so fundamental for using a distro isn't thought of as bleeding edge for many, when it's in the Beginners Guide they expect it to be rock solid. So when it fails after all, the obvious step for many is to try another program, and if that does work right away then yes, they conclude that netcfg sucked anyway.

Debugging wireless just isn't much fun to 99% of the people, especially when they read/are told to just try out various combinations of "quirks" settings, that it's "probably a driver issue". At that stage it's not like trying out a new WM when you know you can always switch back to your previous favorite. If it works it works, being it a direct success with netcfg (netcfg rules!) or something else (netcfg sucks!).

And yes, i'm kind of taking this personally, since i did honestly try to get netcfg working when i first started using Arch. Tried all the quirks combinations i could think of, read in the wiki that if

"It still doesn't work, what do I do ? If the FAQs below didn't solve your problem the next best place to go is the forums, or the mailing list."

so i posted what i encountered on the forums, first in a dedicated thread, then in a direct response to you in another thread to get some attention. Both in vain, so i figured i just install Wicd for a minute and waddya know, it worked instantly.

</offtopic>

Llama · 2009-05-18 06:00:39

litemotiv wrote:

"It still doesn't work, what do I do ? If the FAQs below didn't solve your problem the next best place to go is the forums, or the mailing list."
so i posted what i encountered on the forums, first in a dedicated thread, then in a direct response to you in another thread to get some attention. Both in vain, so i figured i just install Wicd for a minute and waddya know, it worked instantly.

The same with me, I'm sorry to say...

Wilco · 2009-05-18 07:08:56

Is it possible to have a working cardreader without using hal? In that case I can throw out hal and dbus in one go. But without HAl it doesn't recognize a card being inserted.

pauldonnelly · 2009-05-18 07:42:53

Wilco wrote:

Is it possible to have a working cardreader without using hal? In that case I can throw out hal and dbus in one go. But without HAl it doesn't recognize a card being inserted.

Should be. I get devices for inserted cards, and I don't believe that's HAL's doing. Or maybe it is, but I would have guessed udev.

bender02 · 2009-05-18 07:43:29

Wilco wrote:

Is it possible to have a working cardreader without using hal? In that case I can throw out hal and dbus in one go. But without HAl it doesn't recognize a card being inserted.

How do you check if it's being inserted? The correct way is to run 'dmesg' and see it kernel says anything, and then check if udev creates the appropriate device nodes in /dev/*
The above has nothing to do with hal. What hal does is it notices that the above has happened and lets your file manager, WM, whatever, know that there is a new removable storage unit available. You don't need hal for manually mounting the node from /dev/. [EDIT:typos]

Last edited by bender02 (2009-05-18 07:44:21)

Wilco · 2009-05-18 08:17:07

bender02 wrote:

Wilco wrote:
Is it possible to have a working cardreader without using hal? In that case I can throw out hal and dbus in one go. But without HAl it doesn't recognize a card being inserted.
How do you check if it's being inserted? The correct way is to run 'dmesg' and see it kernel says anything, and then check if udev creates the appropriate device nodes in /dev/*
The above has nothing to do with hal. What hal does is it notices that the above has happened and lets your file manager, WM, whatever, know that there is a new removable storage unit available. You don't need hal for manually mounting the node from /dev/. [EDIT:typos]

Most cardreaders (including mine) don't notify the kernel upon insertion of a device. Therefore, HAL polls the cardreader every few seconds. Without polling, udev does not create a node and I cannot mount it easily.

iBertus · 2009-05-18 12:41:39

Wilco wrote:

bender02 wrote:
Wilco wrote:
Is it possible to have a working cardreader without using hal? In that case I can throw out hal and dbus in one go. But without HAl it doesn't recognize a card being inserted.
How do you check if it's being inserted? The correct way is to run 'dmesg' and see it kernel says anything, and then check if udev creates the appropriate device nodes in /dev/*
The above has nothing to do with hal. What hal does is it notices that the above has happened and lets your file manager, WM, whatever, know that there is a new removable storage unit available. You don't need hal for manually mounting the node from /dev/. [EDIT:typos]
Most cardreaders (including mine) don't notify the kernel upon insertion of a device. Therefore, HAL polls the cardreader every few seconds. Without polling, udev does not create a node and I cannot mount it easily.

I think udev should probably do this and HAL should just notify via DBUS so that nautilus/konquerer/thunar can automount correctly. I used to use a card reader pre-hal without any trouble by just looking at dmesg output and mounting the device in a terminal. Also, I remember some custom udev rules that would make the card reader always something like /dev/card-[cf,ms,sd] so that it was easy to remember.

Wilco · 2009-05-18 12:56:11

iBertus wrote:

Wilco wrote:
bender02 wrote:
How do you check if it's being inserted? The correct way is to run 'dmesg' and see it kernel says anything, and then check if udev creates the appropriate device nodes in /dev/*
The above has nothing to do with hal. What hal does is it notices that the above has happened and lets your file manager, WM, whatever, know that there is a new removable storage unit available. You don't need hal for manually mounting the node from /dev/. [EDIT:typos]
Most cardreaders (including mine) don't notify the kernel upon insertion of a device. Therefore, HAL polls the cardreader every few seconds. Without polling, udev does not create a node and I cannot mount it easily.
I think udev should probably do this and HAL should just notify via DBUS so that nautilus/konquerer/thunar can automount correctly. I used to use a card reader pre-hal without any trouble by just looking at dmesg output and mounting the device in a terminal. Also, I remember some custom udev rules that would make the card reader always something like /dev/card-[cf,ms,sd] so that it was easy to remember.

But the problem is still the same on most card readers: no signal is presented to the kernel to notify insertion. Therefore, udev would need a polling mechanism if I want to get rid of HAL.

Arch Linux

#26 2009-05-17 13:23:29

Re: HAL deprecation

#27 2009-05-17 14:08:32

Re: HAL deprecation

#28 2009-05-18 06:00:39

Re: HAL deprecation

#29 2009-05-18 07:08:56

Re: HAL deprecation

#30 2009-05-18 07:42:53

Re: HAL deprecation

#31 2009-05-18 07:43:29

Re: HAL deprecation

#32 2009-05-18 08:17:07

Re: HAL deprecation

#33 2009-05-18 12:41:39

Re: HAL deprecation

#34 2009-05-18 12:56:11

Re: HAL deprecation

Board footer