1 |
On Wed, 04 Nov 2009 11:25:49 -0500, Mike Edenfield <kutulu@××××××.org> |
2 |
wrote: |
3 |
> On 11/4/2009 10:51 AM, Harry Putnam wrote: |
4 |
>> I didn't want to derail the ongoing thread about hal/xorg with this |
5 |
>> question there. |
6 |
>> |
7 |
>> Far as I remember I haven't done anything special concerning hal but |
8 |
>> at some point hal disappeared. And is not on my system anymore. |
9 |
> |
10 |
> I believe that some packages in portage recently masked off the "hal" |
11 |
> USE flag (GNOME stuff, maybe?), so if those were the only packages |
12 |
> relying on hal it might have gone away. |
13 |
> |
14 |
>> I've always used and /etc/X11/xorg.conf file for starting X. |
15 |
>> What I'm wondering from seeing this kind of topic frequently here is |
16 |
>> if I'm running in some deprecated mode? |
17 |
>> |
18 |
>> If my setup using no hal, and xorg.conf is going to become outdated |
19 |
>> and stop working anytime soon? |
20 |
> |
21 |
> The answer is a solid "who the heck knows". |
22 |
> |
23 |
> If it works for you now, don't mess with it. Wait for the |
24 |
> Xorg/hal/devkit/whatever situation to settle down before you go making |
25 |
> any drastic changes. |
26 |
|
27 |
I'd just save all the config files for future reference, specially if you |
28 |
are going to keep your hardware for a long time. For the rest, use whatever |
29 |
works for you right now. I remind you also of quickpkg, in case you need to |
30 |
test and revert packages quickly. |
31 |
|
32 |
> Some people, like myself, are running X with hal and no .conf file and |
33 |
> it works like a champ. I get better hardware detection with hal, |
34 |
> especially on my laptop, than I ever got manually. |
35 |
> |
36 |
> Other people have had problems with hal and Xorg not detecting their |
37 |
> hardware at all. What you are "frequently" seeing is those people |
38 |
> reminding everyone, every time the topic come up, that you don't *need* |
39 |
> to use the new hal-ified way if it doesn't work for you. |
40 |
|
41 |
This whole hal stuff has always been a mess. Yes, it works for a few |
42 |
persons out of the box. But for those that don't, it has brought a lot of |
43 |
trouble. I've never suggested anyone ditching hal when it worked for him or |
44 |
her. If it ain't broke, don't fix it. But I can't help but to think that |
45 |
I've never liked hal because it's a monsters that doesn't solve the |
46 |
problems that it was created to solve, except in a few cases out of pure |
47 |
chance. I still don't know what's so amazing about the hal automounting |
48 |
stuff, when a simple udev rule can do exactly the same without tainting all |
49 |
my software. Now hal has proven to be what a lot of people knew it was from |
50 |
the beginning, just think of the lot of wasted hours, and the other lot |
51 |
that will be wasted to remove all the metastases on every single program it |
52 |
has touched with its tentacles. Hopefully a big part of it would be a |
53 |
conversion rather than a complete rewrite. |
54 |
|
55 |
However, I am sure that they've learn from the experience, and that's a |
56 |
good thing, it's useless to talk now about *what* could have been done and |
57 |
*how*, we have to look forward, everyone including those that just like me |
58 |
do not like hal. It's the kind of thing that happens when we integrate |
59 |
non-mature technologies into every single product under the sun: if they |
60 |
succeed they are visionaries. If they don't, then everyone complains, human |
61 |
nature I guess. :) |
62 |
-- |
63 |
Jesús Guerrero |