[arch-general] HAL dependencies

[Thomas Bächler]

Am 20.04.2010 13:01, schrieb Joerg Schilling:
> "Laurie Clark-Michalek" <bluepeppers at archlinux.us> wrote:
> 
>>> The important question is: by what will hal replaced?
>>
>> UDev
> 
> Note that people have been talking about Xorg which is a highly portable 
> project. So this is most likely not correct as e.g. Solaris has no udev 
> and will never introduce udev. There is the /devices filesystem since 1992...

There is still the possibility for a hal backend in Xorg. And I think
the goal was to add system-specific backends for input devices.
Obviously, udev is only relevant for Linux.

>> You can't take a single high level fault as a indication of a whole 
>> software stacks uselessness. Hal works well for me - in that it does 
> 
> This is an important design fault and as it has not been fixed for many years, 
> it at least let's me asume that the people behind hal are not interested in 
> their users. They developed hal without looking at existing software and without
> fixing the problems they created with this development model.

You didn't even mention WHAT is a design fault. But frankly, I don't
care, as this is neither the topic here, nor is it the right place to
complain about design faults in Linux or HAL.

> On Solaris, hald is built on top of the state detection code inside the "sd" 
> device driver and the problems seen on Linux to not exist on Solaris.
> Does this mean that the problems found with hald on Linux are caused by bugs in 
> udev?

Again, I have no idea what particular problem exists in Linux that
doesn't in Solaris, as you didn't even mention that. But again, this is
not the place to discuss about Solaris or Linux design. Especially not
about Solaris, as it is entirely on topic here.

I would urge you to either discuss the topic, which is eliminating HAL
dependencies in Arch Linux packaging, or not discuss at all. As you
don't seem to have anything to say about Arch Linux packaging, I suggest
you do the latter.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20100420/e7b40d92/attachment.bin>