Slack Current and KDE 3.5 automount
 

I just installed Slackware v10.2 and then upgraded to Current using slackpkg on an old test system. I wanted to see what changes are coming in the new version, and get a little experience with KDE (I normally use Dropline Gnome). After tracking down a couple of stray packages, everything seems to be running well. I also installed the new 2.6.16.9 kernel under /testing in the Current branch.

One question I have is the current with KDE does not seem to automount flash drives and CDs. I have been used to having automounting working for a while under Dropline Gnome, and I was surprised is isn't working under KDE. I have seen some posts for instructions on downloading hal and udev and configuring them for automounting, but I am surprised that is isn't working by default.

Does this indicate something wrong with my install of Slack Current and KDE since I upgraded from 10.2, or is this not enabled in KDE yet? I was wondering if there are other packages I need to install to get this working under KDE?

Thanks...

Bob

What you have to understand is that Dropline Gnome installs HAL and DBUS and messes with the standard Slackware udev in order to have that functionality. While all of this is supported by KDE, it isn't installed as a standard part of Slackware. Which is just as well, because it is a nasty hack IMO. Note: I'm not referring to Dropline's method of supporting it, rather the way that HAL & DBUS work themselves. That is to say: Dropline's packaging is as good as anyone else's. It is DBUS & HAL that I don't like.

Anyhow, I've always found it trivially easy to set up some desktop icons under KDE which will allow you to mount your USB keys and CD/DVD drives using the "traditional" method of mounting/unmounting.

Another alternative (which I've only recently discovered myself) is to set up autofs, which will automatically mount & unmount removable media. You need to have autofs support built into your kernel (it can be built as a module). There are a few posts here about autofs. It certainly seems a much cleaner alternative to the whole HAL/DBUS thing.

At the end of the day, it is your machine, so if you are desperate to have this "functionality" hack, you need to install the following packages from Dropline Gnome: hal, dbus and udev. There may be a couple of other dependancies, but you'll have to refer to the Dropline docs to find out for sure.

Personally I like to use KwikDisk when using Slackware with KDE. It will add a little icon in your System Tray which you can click to mount and open a (previously fstab configured) removable device.

Note that since this program runs with your user rights, you may need to use "user" or "users" in your fstab to properly mount some devices (I guess HAL/DBUS run as root).

EDIT: KwikDisk is under KDE Menu -> System -> More -> KwikDisk (At least in KDE 3.5.2). The executable is called "kwikdisk".

Thanks for the information. I am not necessarily in need of automounting, I was just wondering why it was not included. I don't mind at all exploring some of the other ways to provide mounting of removable media other than the command line.

I have no interest at all in adding a lot of "outside" packages to my KDE setup on this box, just wanted to understand the different approach.

Bob

I'm not sure what you mean. HAL is an abstraction layer between the system hardware, and the userspace applications. :D It basically just keeps information on the hardware so that other applications in the userspace can make use of it. As for removable media, HAL works the same way as "mount" and "umount" work when handling removable devices. It's just smarter, and can interface with the kernel directly, and communicate via dbus with the desktop environment and other software. New versions of HAL don't even need fstab entries to handle mounting. It can't be a "hack" because it simply works with other HAL-enabled applications to implement the same functionality of "mount/umount/eject" along with many other features. A replacement, perhaps, for several peices of software, but it's not a hack. The beauty of HAL is that many of the features that formerly were found in these legacy console commands can be implemented in a desktop-agnostic way, as long as a program is designed to make use of a handful of simple HAL functions.

Dbus is just a messaging bus. I can't see how it is a "hack" in any way. It's actually quite cool when you use it with various programs. It allows programs to communicate over a unified interface. It's very powerful and is used by lots of GNOME applications (and now KDE as well).

It will ultimately be impossible for Slackware to refrain from including things like HAL and PAM. Users will demand it. Software will demand it, or simply won't build at all (note the recent openldap inclusions in Slackware, thanks to Samba. Now we can stop building our Dropline openldap package). Eventually, Slackware's sole maintainer will ease everyone's worries by stating something along the lines of: "things are finally stable enough to warrant their inclusion in Slackware" when, in reality, he's just one lone man who's probably way too overwhelmed with many of the new technologies that are going into other Linux distributions. I don't mean to criticize the guy. It's just painfully apparent that many of his criticisms of these components stem solely upon his lack of experience with them.

I guess it still makes no sense to build HAL support into any Slackware components until the 2.6 kernel becomes a Slackware standard. But when it does (finally), excluding HAL support in Slackware would be absolutely foolish.

HAL is amazingly powerful software. The automounting of removable media is simply one component of it. It (and PAM, by the way), are some of the final components that are needed to properly turn Linux into a serious desktop for modern computing needs. Without them, Slackware simply sits in limbo as an unusable distribution for most home users and an inadequate distribution for serious businesses. If you've seen many of the the mechanisms that are required to use Linux in a networked environment, you'd probably notice that Slackware simply will not work out-of-the-box in many places. Where does it fit in the grand scheme of things?

I believe that Slackware users should politely request to Pat that many of these features are included in Slack. It's very obvious that many of them want these things. Some folks are just too afraid to voice their opinions for fear of being flamed by the "Slackware elite". I see frequent requests for help with making PAM work in Slackware, or making KDE automount disks with ease. It's a shame that Slackware just doesn't do these things by default. These are extremely powerful and useful tools that are responsible for bringing distributions like Ubuntu and Suse to the top in the home and workplace alike. How long will Pat be able to say "If you don't like it, then move to Ubuntu"?

I respect your opinion about the these features on a Slackware Linux desktop, but I do believe it's a bit unfair to call HAL a "hack" without really justifying why this is the case. A lot of the opinions on such matters often stem from a lack of familiarity with some of the underlying technologies that Slackware seems to be missing, while all of the other distributions seem to embrace them. Please correct me if I am missing something that may very well put it in a category as a "hack". To me, however, it simply seems like a logical replacement for old and obsolete ways of doing things.

I learned to use Linux on Slackware. I love Slackware and always will. So much of Slackware is done so well, but so much of it simply isn't improving in the right ways. Maybe it never will. Maybe it was always destined to remain a "hobby OS" for us geeks that still like it that way. I still believe that leaves room for improvements in usability though. I just don't feel that users should have to ask: "How do I make this work when I plug this in?". Linux isn't like that anymore, but Slackware remains the same. Perhaps it's just become too much for one lone hacker to handle on his own.

Sorry for crashing this thread. I just felt compelled to voice my opinion on this subject because I find it mindblowing that users still have to ask these sorts of questions when they use Slack. I don't think that users should have to say: "I don't really need automounting, I just think it would be nice to have." Because, you know, I believe that we do need these features in Slackware. What is the logical reason for making things more difficult for users? What will be the excuse if they are still left out by the time the next version of Slackware is released?

Could you please give a detailed explanation as to why you don't like Hal/Dbus?
Everyone is entitled to their own opinion and I respect yours, but claiming to
not like it because it is a "Hack" don't cut it. I would like you to break it
down a bit for us all to understand. Guess what I am seeking here is how deep your
knowledge of hal/dbus really is to be able to make such a statement. I am guessing
you won't be able too because it's just crap heresay you've heard from other die
hard slack users. Slackware is still using the 2.4.x kernels for crying out loud.
Hal/Dbus is not a hack, the problem is that Slackware is stuck back in the early
90's-2000's and if it's maintainer, "The Slackware God" Patrick Volkerding doesn't
learn to accept change, slackware will still be stuck in the past a few years from
now. I know Pat has his reasons for what he does and I respect that, what I don't
respect is his following tossing out misleading and false information to those who
might want to bring their slack desktop upto date with current technology. If you
don't like a certain software, state why you don't like
it, but don't be ignorant and mislead others. All you trolls are doing is making
the slack community look like a bunch of idiots.

Read this:
http://www.die.net/doc/linux/man/man8/fstab-sync.8.html
and then come back and tell me how clean HAL is.

I don't care what it is, nothing should be allowed to modify such important system files.

Autofs is a much cleaner, simpler and logical approach. The only "downside" that I can see is that I have to manually open a window instead of having one pop up.

Getting HAL & DBUS working was the single most difficult thing I've ever had to do on any Linux machine. At the end of all the hoop jumping, I was left with a setup wihch would dangerously alter system files when a user did something as innocuous as inserting a USB stick.

No thanks. Autofs rocks.

Slackware had PAM at one stage.

The beauty of packages like Dropline is that people can have them if they want them on Slackware today, while nothing is forced upon those who don't want it.
Personally, I wouldn't know. The only criticisms I read are the ones which appear in the changelogs. I prefer to find things out for myself. You know: Don't knock it until you've tried it.
And since when mst every Linux distribution be the same?? Keep Slack simple, I say. Let everyone else run to Ubuntu if that's what they want. Slackware is what it is. You can make of it whatever you want. I'd much rather it stay that way.
Ah, but like everything else, the Slackware way is the simplest:

To configure Autofs, you just copy two files from /usr/doc/autofs/samples to /etc, modify them to suit your system and add one command to /etc/rc.d/rc.local. No other automounter is so simple to set up.
Out of interest, where do you place the *BSDs? There are many thousand people worldwide who use them both at home and in business, yet a standard *BSD installation is far more "spartan" than Slackware.

Check for yourself... http://webcvs.freedesktop.org/hal/ha...og?view=markup

You basically just proved my point, because fstab-sync is 'NOT'
used anymore. Guess you need to do a better google search when
trying to prove your knowledge. Better inform your lemming slacky
users of this also. I guess if you all were with the times you
would know this little bit of info already...

Good day :D

Well it was when I tried HAL last September. :rolleyes: Anyhow, what have they put in its place?

I might try it again one day, but for now I'm happy with autofs.
Right back at ya!

1. fstab-sync has been deprecated and is no longer needed. Please try to keep up.

2. HAL deals with (mainly hot-pluggable) hardware, not just filesystems, which means autofs does not handle the types of things it deals with, not by a long ways.

3. There's nothing particularly dangerous about adding an entry for a device that the kernel knows wasn't there a moment ago, and is there now in a known, reasonably understood state.

4. fstab isn't some holy writ. It's just a list of filesystems and where the admin would like them mounted, and with what options. Plus, adding and removing lines from text files is a truly trivial programming task. I'd have thought guys who work inside the kernel could handle it.

I can't speak for kde for I don't use it, but I believe it can
use pmount. Gnome can use either gnome-mount or pmount. There
may be others but neither of them touch fstab or any other system
files for mounting devices.

That has already been pointed out. Please try to keep up.
So, what would happen in the situation where (as a result of a bad write) the file is corrupted and you don't realise until the next time you try to boot your computer?
It doesn't work under KDE 3.4.2. In fact, I couldn't get it working under Slackware 10.2 at all.

So they deprecated fstab-sync and haven't replaced it with anything? This all sounds too complicated.

I believe pmount utilises pam for permissions.

Be aware that the only thing that really requires an fstab at all are the legacy tools in util-linux. Nothing else needs them. HAL itself is a replacement for the fstab. It keeps information about the devices in the system, without the need to micro-manage an fstab.

I know it's hard to imagine actually mounting devices without an fstab entry for the device, but, again... It's not needed, which is why fstab-sync doesn't exist anymore.