I think I've missed something somewhere along the line... when I start up VMware Server it runs as "me" (my login) and cannot connect to /dev/dsp for sound. I can change the mode of /dev/dsp from 660 to 666 and that works, but that doesn't seem right (and I have to do it every time I start VMware again) -- I ought to be able to do something with adding my ID to /etc/group or something but I can't seem to quite get that figured out (and I can't find a previous thread about this but I seem to remember that there was one).

If somebody would be kind enough to point me in the right direction I'd appreciate it.

Make sure you are in the audio group
Edit:
run groups to check your groups.

Also, the vmware server should not be running as you, but the player will.

Don't forget to move the vmware init scripts (sym links) installed to /etc/rc.d/rc5.d to /etc/rc.d/rc4.d or else it won't automatically run in runlevel 4.

Well, both root and "me" were (and are) in the audio group and I removed the VMWare symbolic links in /etc/rc.d/rc5.d and created the same links in /etc/rc.d/rc4.d. Restarted the system, VMware works fine except for the same error message:
I should note that VMware started, ran, XP worked fine, everything normal previously (with the symbolic links in /etc/rc.d/rc5.d); that is, everything but the identical error message from /dev/dsp.

If I chmod 666 /dev/desp after the system boot, that seems to work -- but that shouldn't be necessary (because I can use the sound system with MPlayer and other utilities without having to change the mode of /dev/dsp).

'Tis a puzzlement.

Thanks for the help.

Check the permissions of /dev/dsp. Post the output of `ls -l /dev/dsp`. On my system, it looks like this:
Also, it should be noted that you HAVE to add the user to the audio (and video, cdrom and plugdev) groups manually. You will appear to be a member of the audio group in runlevel 3 because of /etc/login.defs, but that only works in runlevel 3 (and you should manually add yourself to the audio group anyway). If you *did* add yourself manually to the audio (and video, cdrom and plugdev groups for other reasons) either through the adduser script or the gpasswd command posted by shadowsnipes, and both `group` and `id` show that you are in the audio group, then you've got an interesting problem. If /dev/dsp's permissions are not correct, it may be an ALSA or a udev thing -- I'm not sure which.

Well, /dev/dsp looks like this (after boot):
I did the explicit add (with gpasswd) to the groups (audio, video, cdrom and plugdev) and started 'er up: ding-ding-ding, dong-dong-dong and all is well with the world, thank you.

This seems to be one of those things that go bump in the night -- from Slackware 10.x up though 12.0, VMware never had a problem with the audio gear; it "just worked." Sigh.

As an aside, the previous really annoying "enhancement" was when su - changed the behavior it's had for decades (literally from System 3); you'd su - user and you'd get logged in with that user environment, handy on a multiuser system with all kinds of environment settings for different applications and the like (and, even better, when you logged out you didn't inherit any corpses from that environment). All of a sudden the blasted thing doesn't execute the profile and you have to fiddle around trying to figure out how to un-enhance it so it'll work the way it's supposed to; if something ain't broke some folks seem to be dedicated to fixing it anyway, alas.

Anyway, all is well that ends and thank you for the help.

Well, since this is documented in CHANGES_AND_HINTS.TXT on the install CD/DVD or at your favourite mirror, and is considered part of the installation process, and since the adduser command hints at pressing the up arrow when adding groups to see the recommended groups, of which audio is a part, I don't see this as a problem. If you setup Slackware properly (ie add the user to the audio group, which you must do on every Slackware install), it "just works". CHANGES_AND_HINTS.TXT documents the changes and hints () to the installation procedure and should be considered mandatory reading for EVERYONE installing Slackware.

I don't know that much about su beyond normal usage, but `su - user` still logs in as the other user while loading the other user's environment variables etc. A simple `su user` will obviously keep the same environment as the running user, but `su - user` still loads the proper environment for me. Maybe I'm just not understanding. I explicity set umask to a custom value for my normal running user in ~/.bash_profile and I have a few aliases in .bashrc. The aliases will never function as the other user even with `su otheruser` because .bashrc gets checked -- but .bash_profile doesn't unless it's a login shell. When I `su - otheruser` the umask is restored and the aliases no longer function (as expected). Can you elaborate on the problem?

OK, the "traditional" (that means for the past 20+ years), su - or su - user would, after asking for a password if you weren't root to begin with, do a "as if you logged in as user;" meaning as if a raw login on the console. So, you would become that user, with all the environment settings that user would have on a console login. Long about Slackware 11.something or maybe it was 12.0, you had to go edit /etc/login.defs and change
to get that (long-term standard, 20+ -- nearly 30+ -- years) behavior. PITA. Now that I know the thing is going to behave that way out of the box, I know what to change to get it to work the way I've always expected it to work.

Now it may not matter with BASH, but I don't use BASH and to be honest couldn't care less what BASH does or doesn't do (on a par with C-Shell; don't give a hoot what it does either), I use Korn Shell (no insults or arguments intended, I go back and forth between Solaris and Linux and port software back and forth and, well, it's Korn or nuthin'). One thing I do know is that BASH just doesn't work like Korn Shell and it's different enough that I don't want to bother with it.

The crux of the thing is that... if it ain't broke don't screw with it and people seem eager to fiddle with things better left alone. This stuff's been working just fine for decades and, gee, either leave it the hell alone or at least default to the previous behavior instead of requiring more screwing around to get the thing the way you need it to be. In UNXI-based systems, old is not a bad thing -- been working fine, quit screwing with it.

Just an opinion, and we all have 'em and that's enough about that.

Ah, I understand. I've never tried anything other than bash, so this is all news to me. However, upon testing with bash, it is displayed as "-su" instead of the actual shell name in ps, so I see your point. Not important to me, but at least I learned something. Thanks for taking the time to explain.

Thanks for the info as well, tronayne. I'm another BASH user so I never noticed the difference.