I agree that that is a matter of taste. There is little to no Slackware influence here, because we use the default KDE colour scheme.

That will not happen anytime soon. None of the people in the Slackware team like grub very much. Grub also does not compile on slackware64 which makes the decision even harder to add it to the installer.

Now that would indeed be a good thing to add.

Not going to happen, due to restrictions in the distribution licenses.
Installing the binary nvidia or ati driver should not give you headaches however; it is not that difficult. What are your issues?

As a test, I just added a new category "Aliens" to the KDE menu, and I did not have to switch to "classic view" to achieve that. It only requires you to add an actual entry in the category menu to make it visible in the menu.

In "System Notifications", there is a tab "Player settings" where you can check "No audio output" which will disable all notification sounds.
And using TAB and arrow keys, I can configure any sound effect of any event source.

No idea about the integration with other DE's, but adding desktop icons is quite easy if you configure your "Desktop Activity" settings as a "folder view" instead of a "desktop"

I have no smb.conf file at all on this laptop, but Dolphin as well as Konqueror accept the notation smb://myserver/myshare and in my case of a server share that requires authentication, I got a nice password dialog where I could enter my credentials.

The thing is, the Linux desktop evolves, and this may require adaptation of the way you look at your computer and the way it can serve you. Things are not becoming impossible, they merely change.

Eric

1 members found this post helpful.

Spot on ...it seems that the 64bit Nvidia driver is compiled using a newer compiler than the one used to compile 13.1... well... what the heck I want to try and compile something anyway... so I don,t mind.

I've never had a problem with the proprietary Nvidia driver downloaded from Nvidia.com

Pity. Grub works quite well and allows you to recover from screw-ups that would be fatal under lilo.

FWIW, grub-1.98 just successfully compiled on my Slackware64 13.1 setup. It isn't multi-lib. I freely admit that I haven't tested the result of the compile. :-)

Let me clarify that my recent problems have all been with the ATI drivers not nVidia. Mostly the issue is that it was not possible to install the driver without editing or patching files. It was difficult to find the correct patches and installation steps for Slackware 13.0 The newest release still requires some extra commands to build the driver for Slackware 13.1, but I did find those in a forum post.

I am currently struggling with the KDE desktop effects, and trying to get them to work with the ATI driver. This has been a source of frustration for me, though I really don't need them.

Changing the desktop settings to use Folder View did solve my problem of integrating the desktops and creating icons. Thanks for pointing out that setting. I didn't mention KDE Help but that is another area that could use some improvement. It seems to lag behind KDE functionality. It is better than it was in previous KDE versions.

It also seems that the menu is more configurable in KDE than when I last looked. I was able to define a new Application folder. Is there a way to configure the panel tabs to add a tab and an icon, or are they limited to "Favorites", "Applications", "Computer", "Recently Used" and "Leave"?

My desire to use GRUB might change after "mdadm" supports my RAID setup and I am able to make a working "initrd" with "mdadm". At the moment LILO cannot determine the correct information to work with my RAID setup. I haven't spent a lot of time trying to make LILO work, so it's possible that it can. Having LILO rewrite the boot sector every time the configuration changes is inconvenient for me, since I use the Vista "bootmgr" to chain to a file with a copy of the LILO boot sector. I've thought about writing a little 512 byte routine to chain to the actual superblock of my Linux partition to avoid that problem.

In spite of my complaints (or perhaps misunderstandings) I prefer Slackware to other distros. The Slackware user community and Slackbook are both valuable resources. Getting my two computers with RAID working has always been possible with Slackware and is getting easier with each release. Hopefully "mdadm" will add support for more RAID metadata formats if "dmraid" is not updated in the future.

I also would like 32-bit support to be a more standard part of the 64-bit Slackware release. Even if 32-bit isn't installed, it should be at least provided with the releases as a package. I am not yet ready to move to 64-bit due mainly to the issues with supporting my RAID setup. I had problems with building the ATI driver for 64-bit but I haven't tried that with the latest ATI release.

I have used Slackware for quite a while. Obviously, I like it. There are some occasional annoyances. Right now, my /tmp directory is full of cr*p and I can't find anything other than $rm -rf /tmp/* to deal with it. I guess my continuing complaint is packages accumulating in /tmp. Perhaps SBo could designate some environment variable such as SB0-TMP="~/.tmp" to make it easier for users to keep package collections/history together more easily.

I did find this:
http://packetstormsecurity.nl/linux/...min-FAQ-6.html

Any thoughts on a good script to clean up the /tmp directory?

Thanks

Being a non-savvy linux user as I would like to be, each release could have gotchas if one isn't up on the release notes, which in some cases could be totally esoteric to me, and past habits are hard to break. For example was the movement to plugdev, then hal, to no xorg.conf, and in 13.1 from /dev/hdc -> /dev/sr0, all of which have had big implications in relearning Slackware functionality. Rather than updating the kernel, I've relied installing new versions from scratch as I've always had problems in updating kernels. I've always liked Slackware's quickness compared to gui-based distributions, but the last straw in my main pc was getting cdrom, usb and wireless (using wicd) to work. Linux Mint (actually a version of ubuntu) worked without a hitch, although I've been trying to get rid of sickly green themes and replacing branded browsers.

In what way did cdrom and usb did not work for you? Wireless can be somewhat painful to set up, but I don't see big changes there from 12.2 to 13.1 (admittedly, I haven't bothered to use wicd but have used the rc.inet1.conf configuration file).

No complaints from me that are slackware-specific. I, too, prefer grub but it is easy enough for me to replace lilo post-install.

My headaches with 13.1 are all caused by kernel changes. I use slackware for embedded systems and some of them rely on the VESA framebuffer for initialization and status screens. There are half a dozen more little things in the current slackware kernel version like that, and in combination they've made upgrading my embedded systems more trouble than it is worth. I'll stick to 12.2 and 13.0 for those machines and projects.

Here's one thing I don't like, the defaults.

When you install slackware it uses the huge.s kernel, and then stays with it even after install. This is the source of problems, I suggest switching to generic as the default after install, although this may also cause problems.

Other defaults are problematic, but I can't think of them right now.

Perhaps you need to check /etc/group
Is your regular user a member of the plugdev and netdev groups? For me 13.1 was a completely painless transistion as my cdrom, usb, and wireless (using wicd) worked out of the box.

Please be a little more specific: you speak about a ton of problems but do not give a single example, so one can see your sentence as only spreading FUD. BTW, how heavy is a ton of problems

Furthermore, as you already know very well, Slackware users are invited to switch to -generic with an initrd as soon as the system is installed and that has been the case for years. So really, I don't see your point here.

You know very well too why -generic is not the default at time of install. Among other reasons most file systems are not built in it so you would go for a kernel panic in most cases.

It's boring. I can have an install running X in minutes. After that, it only takes an hour or so to get everything just the way I want it. There's no challenge.

It's one of the first tasks I do when setting up my account. I've been following other threads with cdrom issues as the symptoms appear similar to mine. In the meantime, I'm trying to figure out if I'm starting to get a failing motherboard or hard drive. However, the other linux distribution installed totally without a hitch (it almost broke my heart just how painless it was compared to what I've done in slack).

LOL