Certainly. The method used by Dropline Gnome in their HAL & DBUS packages is what I was referring to. Essentially, they take advantage of Slackware's SysVinit compatibility instead of editing any of the rc files. This method enables much easier removal of the packages without requiring modification of any files.

Could it be that the automagic playback of DVDs works similar to the automatic playback of music CDs? The DVD must not be mounted, then. Maybe your problem is totally unrelated with the HAL (Hell?) thing discussed here... but I really don't know, just an idea.

gargamel

This is kind of off-topic, but on-topic if you get my drift.

I recently put suse on my pc to test out a video card, as you know suse 10.1 gm has : pam, hal, dbus,udev and resmgr and se-linux.

My mouse a logitech mx310 couldnt give me 800 dpi as a normal "user". Root could kick the mouse into 800 dpi but not normal users. KDE reported permission errors for 'libusb'; tho I found out how to do for slackware by simply making an fstab entry for 'usbfs' and putting in permissions for the entry; and it works superbly.

Anyway, I tried that fix for suse, and by all sense of reason, it should work. But no! All of these various overlays of the pam, hal...etc,etc one was stopping me? I don't know, there's nothing logged; and in the end I just plain gave up after about 2 hours.

You see I'm also trying to learn PAM as I use vmware, so I kind of wanted to see how SuSe does it too which is why I was trying to get the suse running.

Well, now I kind of see why Pat doesn't have these items in slackware. Something may or may not work becuase of some little config file setting; and the irc and message boards could be flooded; may be too much for one man.

I guess before I take the plunge into setting up hal, pam on slackware 11 I'm going to be sure I have all my stuff working correctly first for a few days or so, then add them in little by little and test test test.

I kind of wish these teams: hal, dbus, udev, pam, resmgr got together and put one package out with one or two maybe config files. It's kind of overwhelming to be honest. But that's half the fun of linux is messing around under the hood

Thanks for the ideas about SysVinit, but I do prefer to keep things the slack way, so I think I will stay with my method. Got the autoplay of DVDś working by using the IVMAN software from here:- http://prdownloads.sourceforge.net/i...r.bz2?download.
Do the usual ./configure, make, make install, then edit a single config file and away you go.

Still, it seems a real shame that it takes no less than 4 different pieces of software, and hours of work compiling and editing .conf files to achieve what would at first glance seem to be quite a simple task. As Old_Fogie points out, it would be nice to see just one package that does it all.

Huh? By using the sysvinit trick, you would be using a capability which is built in as part of Slackware and provided for just that purpose. One thing's for sure - it makes for an easily removable package.

Regardless, HAL works either way. Neither is really more "Slackware" than the other.
Out of interest, did you install PAM as well?

The reason that these are not combined is because they have nothing to do with one another.

-PAM is system of an modular authentication mechanisms. PAM modules can be used for a number of different things. One of its most useful modules (in my opinion) is pam_console, which locks ownership to a single active user on the console.
-Dbus is a messagebus that's used by *lots* of GNOME apps (and a growing number of non-GNOME apps as well). It is merely for communication between applications (not only HAL, like many folks believe).
-Udev is for (but is not completely limited to) creating dynamic device node creation.
-HAL is an abstraction layer between the hardware and the software. It does nothing but provide information about hardware.

Combining them into one package is would be like combining the Linux kernel with OpenOffice.org.

Like anything else, understanding how things work is important to making the most of software. They aren't that complicated, but the only thing that a normal system admin may truly need to understand is PAM. The other stuff is normally only important to software authors in terms of making things work together, and is supposed to be transparent to users. If something is not working with the above mentioned software, then it's likely that your distro developer did not implement it properly, or there are some problems with the software itself.

One problem that I see with Slackware is that so many users are becoming left behind when it comes to some of this mainstream software these days. A perfectly normal thing on the majority of distros (e.g. PAM) becomes much more complicated because the majority of Slackware users have never used it before. But it's a powerful tool that is important (in my opinion) for desktop and enterprise installations alike. I really think that it would be beneficial for Slackware users to ask for some of this stuff in Slackware proper.

Hi rkelsen,
I just meant I prefer to keep my scripts in rc.d, not the rc.0...1...2 etc. And no, I have not installed PAM. Seems to work OK without it.

One thing important with SuSE is: Do as much as you can with YaST, and avoid fiddling with config files directly. YaST writes config files based on its own input files. If you change a config file manually, it may happen that YaST overwrites your change. You can turn this behaviour off, but then you don't have the benefits of YaST.

Not sure if that is your problem. It may also be caused by the fact that Novell doesn't include as many hardware drivers with 10.1 as they did with earlier versions.

Don't get me wrong: IMHO, SuSE and Slackware are equal in quality. The concepts are completely different, and that's just fine. Because you can choose between two excellent distros depending on what your are going to do. I one Slackware-only, and one SuSE-only system, and two dual boot systems with both Slack and SuSE.

gargamel

@zborgerd: thanks for the feedback, helps me to understand their perspective. I think I see your point about slacker's maybe getting left behind as due to the lack of the hal in slackware. It's becoming more of a requirement, even for KDE stuff like the Klaptop for example which runs awesome in suse by the way, tho my pc is too slow for suse and runs slackware. I've found many others that appear to be going that way, madwifi too for example.

For me, because I'm so new, I'm having a hard time to even find good documentation, so this thread has helped a ton for sure.

The PAM is really bizarre, I was hoping that from the manual's and SuSe I could figure it out on my own. I learned how to tighten up security for my vmware, but I'd like to implement it further, this is where it's all "going to pot on me"

@gargamel: yea you're right about doing things in suse thru yast. SuSe is a little misleading, as it share's a common history from slackware, some of it's items, config's are in the same spot and you think that you can tweak them, only to find out later you were really wrong.

I found on the net...burried in an IRC thread, that suse issued a patch to stop 'resmgr' from giving people who use their pc's access to 'usbhid' devices, and 'hubs' for the fix that i use here in my slackware. apparently, a local user, or a remote user can log in thru virtual console and gain access thru the usbfs so suse decided to disable this, tho I can't find how I give myself access to the mouse as a result of this fix that made it's way in to SuSe 10.1 GM and wasn't there even in SuSe10.0.

Nice that they patched it, but how about work arounds?

I too agree SuSe is a nice distro, the problem that I find with it ultimately is that I cannot find anywhere near good community support for it like that with slackware.

Permissions rules is really my next step in locking down my boxes, requires alot more reading, I'll get it, just takes time.

Bye for now.

From the look of things, Pat's been hinting in his ChangeLogs (and #slackware on irc.freenode.net) that HAL will be in Slackware 11.1. This means that future KDE builds may be HAL-capable. This is a good sign, in my opinion.

Digging this up from the grave, but did anyone get this to actually work? I see a couple of people claim they did, but I followed the instructions and I still don't see a change...

Running kernel 2.6.17.13
Got Hal from linuxpackages.net
Got Dbus and compiled it --with-qt
Created messagebus and hal users on system
Compiled kdebase --with-hal

Installed everything, seems to be the same...

Any suggestions?

Actually, Pat included a last minute patch in Slackware 11.0 just before release. The patch eliminates the dependency of KDE from HAL and DBUS. The result is that you can work just like with 10.2 (almost), and that most Slackware users won't miss HAL or DBUS.

Now, that doesn't explain how to activate HAL and/or DBUS. It's just a hint that you may not need it, depending on your concrete situation, of course.

gargamel

As far as I know, that should be about it. Kdebase is the one KDE component that needs a rebuild for this to work. You may want to verify that your Linuxpackages.net HAL package is working. Not sure I'd trust it. There are a lot of quirks in recent HAL releases.

The Dropline HAL and dbus builds are verified as working, but you'd still need a recompile of Dbus with the QT bindings (something that we do not add).

You may be able to ask Stik in #dropline on irc.freenode.net. I believe that he has a working kdebase package along with a dbus build with QT bindings.

I thought the same thing while reading the patch for it... However, automounting does not work at all. Trying to get a KDE system set up that is as easy to use as possible and this is starting to limit the ease of use!

Not sure what the problem is... When I got to system:/media/cdrom, it just works at trying to view it (the K icon moves). Then I look in system:/media, the CDROM is present, but it says umounted. If I right click and try to mount it, it doesn't mount it. Not sure why...

Here is my fstab for the CDROM:

/dev/cdrom /mnt/cdrom auto noauto,user,ro 0 0

I would guess it should be able to mount that. I can as a normal user... Why can't KDE?

Does KDE have any logs for such things?