[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Yes, we have bugs



2009/4/15 Josselin Mouette <joss@debian.org>:

> Or maybe it is just that the Utopia maintainers, just like those of
> Linux, KDE, GNOME, Mozilla or X.org, receive too many bug reports
> compared to the amount they can handle. Bugs assigned to HAL are often
> caused by buggy drivers or other kernel bugs, or they need workarounds
> specific to the hardware. They are clearly not the easiest to deal with.

Joss, I was explicitly asking if there is a better metric, and I
stated, both a line before your quote, and a line after, that the bug
count is not a fair way to measure the quality of a package.
Just to prevent a possible flame over the quality of hal maintainers'
work, which was not my aim at all.
I see that I could have been less aggressive in my mail, and that a
rant against hal maintainers can be read in it.
That was unintended, I'm sorry.
My point is different: hal is a pain for a lot of users. I don't blame
you nor anyone else.
But please, pretty please, don't force it on every one if it's avoidable.
[The rest of the mail is just more ranting on how hal sucks, skip it
if you like]

> HAL is flawed for various reasons, and people have started to write a
> much lighter replacement (devicekit). Nevertheless, it still does the
> job correctly, and I’m happy that the last piece of the desktop that did
> not correctly support hotplugging now does.

But what if I don't need hotplugging? Why should I bear hal flaws if I
don't need its features?

> You must be joking. HAL is much faster to start than X, furthermore it
> allows for asynchronous device detection, which means both can be
> started in parallel.

Maybe for your systems.
In on of mine, it waits several second for my empty cd drive to tell
it what it has inside.
On my netbook, it takes more than one second out of eleven in the boot
process: that makes 10%.
Gdm probably takes more, but it forks after ~0.2s, so the process can go on.
Anyway, with hal I have to wait for hal to start, and then for X to
start, and I can't start them in parallel.

> I agree the HAL FDI files’ syntax sucks, but they allow to directly ship
> in packages a number of configuration snippets relevant to specific
> hardware – this is how we can really improve out-of-the-box hardware
> support.

I'm not saying that this shouldn't be possible, just that users
shouldn't be forced to use it.
Cheers,

Luca


Reply to: