SUSE Linux 9.2: Let the Branding Begin! - page 5
Differentiating Novell and SUSE
Aside from the upgrade and wireless-tools issues I mentioned earlier, I only had a few minor problems. One of these was with getting sound to work on my system. 2.6-based systems use ALSA (Advanced Linux Sound Architecture) rather than OSS (Open Sound System), which was the standard for 2.4-based (and earlier) Linux systems. ALSA frequently starts up muted, which is easily corrected by running its alsaconf application. However, this alone didn't do it for me.
I could play CDs fine, but XMMS and other audio players remained mute, though they thought that they were playing since their timers were running. I eventually had to run the alsamixer application and enable various DXS playback items before my system would play any of the audio files that I've lovingly ripped from my CD collection. For me, keeping a stack of CDs beside the computer is silly nowadays, especially because I have a fairly wide range of tastes. And if you're from the RIAA and are reading this, you're free to stop by and visit my attic to see boxes of dusty CDs. Don't get your hopes up.
Another issue which was irritating for me is that SUSE turns off the ability for remote X Windows clients to connect to your desktop by default. Though "ssh -X" provides a more secure version of this capability for office use, I'm used to opening up X on my home network for convenience' sake. Even the generic "xhost +" command doesn't help, and I flushed the firewall just in case, but nothing. It had to google for quite a while before I found the magic info-byte to find out how to do what I viewed as a classically simple X Window system task. In order to enable remote X clients to display on recent SUSE releases, you have to crawl through various YaST menus once your system is up and running.
After entering the Control Center's YaST2 Modules pane (see Figure 5), select System, and select /etc/sysconfig Editor. After authenticating (unless you're already root), expand the Desktop selector, and expand the Display manager selector. You must then set both DISPLAYMANAGER_REMOTE_ACCESS and DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN to "yes." The next time you start the display manager, things will work normally.
Looking through /var/log/messages, I noticed some bizarre messages from the driver for the Marvell Ethernet chip on my 64-bit system. These are of the form:
Dec 12 16:19:53 64bit kernel: eth0: -- ERROR -- Dec 12 16:19:53 64bit kernel: Class: internal Software error Dec 12 16:19:53 64bit kernel: Nr: 0x19e Dec 12 16:19:53 64bit kernel: Msg: Vpd: Cannot read VPD keys
To be honest, I don't know what these mean, and the only information that I could find on the web about problems such as these were that they might indicate a BIOS issue. 100 Mb Ethernet seems to work fine, and I don't have a GigE network at home. Well, not yet.
As far as cool things that were new to me are concerned, one of the
handiest was SUSE 9.2's use of /media as a location where removable
media are automounted was both pleasant and handy. I'm used to
tweaking /etc/fstab to allow user mounts or configuring automounting,
both of which can be a PITA in different circumstances. With SUSE 9.2,
I noticed that I can immediately access any removable media that I've
inserted under the appropriate directory in /media, one of
/media/floppy, /media/cdrom, or /media/dvdrecorder. As far as I'm
concerned, that's just "the right thing."