Yes, as best as I can tell, everything else works as expected (read: as it previously did before HAL). I use my fstab as I always have, as well as xorg.conf, and I mount media manually, which I prefer.

However, one thing that is annoying: without HAL, You can't zap X with CTRL-ALT-BACKSPACE unless you do:

in one of the xinit files (can't recall which one). This apparently allows Zapping from within the DE, but for me hasn't allowed me to Zap from KDM/XDM, though I may have put in into the wrong file.

This whole HAL scenario kinda grates on my nerves a tiny bit: While I certainly understand some 'modernizing' is expected (and almost always appreciated) and the need/desire for some folks to have auto-mounting and whatever else HAL does, my personal thoughts are that HAL, in its current incarnation, goes against the Slackware philosophy in that it's for the most part an 'absolute necessity' which can't easily be gotten around. That's not KISS.

I'm going to install Slackware 13 this week on my desktop. I might just "go with the tide" and leave HAL there instead of trying to disentangle it from the rest of the system.
As for my laptop, power consumption is important so if I can't get HAL to stop polling the optical drive I might just not bother installing Slackware 13 at all.

Cool. Glad it's not just me who prefers to mount media by hand! I do most things in the terminal anyway, so it seems more sensible to me to do that.

I can't seem to kill/restart X with Ctrl-Alt-Backspace with HAL. I'm using Xfce right now and I'll try your solution (perhaps the file you put that in is ~/.xinitrc?).

Agreed!

Thanks again.

If you just want to disable the polling of the optical drive you can do that with this

I just had that in a bash script I would run when I was needing the most juice possible, or if this is a constant thing you could add it to your rc.local file.

Oh and make sure you replace /dev/hdc with your actual cdrom device (I'm not sure if it will follow symlinks).

Thanks a lot, I will try that!

When I installed Slackware 13.0 last Friday I encountered a few problems. Two of them concerned keyboard layout and TrackPoint behavior. I was unable to make them work properly. Xorg loaded some strange keyboard driver and ignored TrackPoint at all though it accepted an external mouse with a wheel. I generated xorg.conf with X -configure command and tried to implement in it options responsible in the previous versions of Xorg for the keyboard and the mouse work but without any results. Finally I found the solutions of these problems. Now I use .xinitrc to load the appropriate keyboard layout with setxkbdmap command and I use nice FDI policy for IBM TrackPoint.

I never used HAL and I never supposed I’ll use it in the future. I have sophisticated fstab and I mount all the devices manually. Surprisingly I started to use HAL since last Friday. I do it each time I touch TrackPoint or middle mouse button on my ThinkPad.

So: you never know...

It's not that it's bad. It's a preference thing. Some folk just see it as an unnecessary or unwelcome layer of complexity. Personally, I'd feel more inclined to like it if it had a single, easily understood, non-xml config file instead of tens of xml files spread over several directories.

I'm also not keen on the fact it polls devices every few seconds to see if a new volume has been inserted. It's a decision forced on HAL by limitations in the hardware, so I don't blame them for doing this, but I'd rather have to click on an icon when I insert a new volume than have the system keep polling for it every few seconds, which can cause problems with power-saving/sleep modes and is generally wasteful as 99.9% of the poll events will have nothing to report.


To me, it's a bit like an old engine v a modern engine. With an old engine if something goes wrong you had a good chance of diagnosing and fixing it yourself. With modern engines with their fancy engine management systems and electronic sensors all over the place you've got absolutely no chance and you'll need to take it to a specialist. Now clearly, modern engines do come with advantages: not needing to mess with the choke on a cold winter morning being one, but all that user friendliness comes at the cost of ease of maintenance and the ability to understand how it all hangs together. While it's all working correctly, a modern engine is wonderful, but as soon as you hit problems you're in for some pain, and that's how I see HAL.

Great analogy, I like that and can relate.

And the old engine used a fraction of the gas as the new one,
went much faster, was much more efficient, and lasted longer.

But then, enough users coming from Windows and Ubuntu are after
that "upgrade-often give-me-twirly-cube-features" mindset, and
who cares about stability or maintainability. Just look at all
the weird issues in threads today, versus Slackware of old.

Great analogy indeed, Gazl, it sounds fair enough to me. I do not wholly agree with Bruce on this however. Things like HAL have allowed Linux to be used by people with far less technical understanding of how things work. This kind of audience has different problems, rather than "more" - but since the group growed the amount of issues increased as well. At least, that's how I see the growth more.

In the past things either didn't work (winmodems come to mind) or were complex to get to work, like inserting a module for your soundcard with certain obscure flags in a not too descriptive modules.conf; The audience at that time, however, were mostly technicians, and were more capable of figuring things out. Now you toss in a disc, you do your install and most of the times the most important things work out of the box. The pros (it's easy) allow a less-technical audience to use Linux, the cons is that figuring out why something doesn't work has become different / more complex.

From the horse's mouth:

He goes on to talk about future plans, devicekit et all, as well: http://lists.freedesktop.org/archive...ay/011560.html

I notice this post is from May 2008. What's the word on how things are coming along?

FWIW, I think it's a great idea to keep developing HAL (or its successor) to improve it. Nothing is really ever perfect or complete, and every software program has compromises.

Regards,

I know ubuntu are moving away from hal towards devicekit. They even announced they're moving away from hal to devicekit. So I would have thought they'd be helping development if it stalls.

The freedesktop page and docs is being updated regularly if that's any indication: http://www.freedesktop.org/wiki/RecentChanges

The new direction does look a lot better compared to the car crash that is hal atm. As the separate programs seems to focus on one thing and one thing only, generally, I'll be happier; they'll be moving slightly further towards the unix philosophy.

Yeah, progress is being made, and while I don't necessarily agree with all of David's conclusions regarding the direction in which the linux desktop should go, he is overall a good guy - he agreed to try and make the rewritten stuff work without PAM whenever he finds the time to do so. The only other hurdle will be that he's targeting the development versions of glib and gtk (the ones leading to the next stable release), so it might be a few releases before Slackware even has those, much less considers migrating to the rewritten polkit stuff.

I'm glad to read that. When I saw that HAL will evolve to ConsoleKit, DeviceKit and PolicyKit... Too much kits for me.

Since I use Openbox, one of the first things I do on a new installation is disable HAL and D-Bus. I installed 13.0 on a test box and noticed that the keyboard and mouse wouldn't work without HAL and D-Bus, so many thanks to Robby for including the workaround in CHANGES_AND_HINTS.TXT. I hope Slackware will always remain a user-friendly distro for those who choose more minimal WM's.