Huh? DKMS (Dynamic Kernel Module Support) is a system to automatically recompile kernel modules in case the kernel changes. It is in no way related to the different runlevels.

Thanks for the reminder. I'm quoting it so someone who needs it will find it hard to miss. Not only am I an old hand at this game, but I haven't bought anything but nVidia since 1996. ATi back then had no interest in "alternative" operating system support and that might have been a good thing because, until AMD took over they weren't very good at writing drivers. Nice hardware, sketchy drivers. At least AMD is trying and seemingly getting better all the time.

On another front, it's a shame both graphics card manufacturers, in the interest of hitting so many price points, create so many models every year that they apparently find themselves overwhelmed in supporting them all and have to cry "legacy!" Oh well.

I am referring to this in a functional way. I'm not sure which is "the cart" and which is "the horse" (and care only little) but as I see it, distro devs that choose to essentially abandon runlevel 3 (and perhaps also the whole non-vanilla dependency issue plays a part), preferring to boot right to desktop, make it a huge hassle, if possible at all, to install graphics drivers (and kernels themselves) in the proper way, sans X. So, instead, they rely on dkms.

Again, DKMS has nothing to do with runlevels, DKMS works in any state and is just an automatism to recompile kernel modules, regardless if they are for graphics card drivers or anything else. It is just a convenient thing, so that you don't have to recompile yourself when the kernel is updated.
Also, I yet have to come across a distro that doesn't allow you to shut down the GUI.

Thanks Toby for being certain but I do know how dkms works. I never said it had anything to do with runlevels BEYOND the fact that distros that don't have runlevel 3 enabled, employ it, sidestepping the need as per driver install instructions to install from outside X. I prefer to install by the manufacturers' instructions and generally don't care for automated installs. I'll take freedom and stability over "convenience" any day.

Regarding your last sentence, while OpenSuse actually has Runlevel 3 enabled it is not default but can be selected as default, and as I understand it so does RedHat, Fedora, and that family. Xandros had Runlevel 3 disabled and so does Ubuntu and afaik pretty much all Debian derivatives. There are ways around it but it's a pita to me. I prefer the Slackware default and not just because I'm used to it. It just makes more sense to me.

Then you will be delighted to hear that DKMS is supported by Nvidia's binary installer.
Indeed, almost all Debian based distros do only use one runlevel.
IMHO, I don't think running to shut down the GUI is a pita, but YMMV.

thank you evry one guys . great support from great people ..

Technically Debian uses 4 runlevels, right? Start, Single User Console, X, and Halt. So if one issues the above command, where does that put one? Single User Console? To me that is a pita. The bottom line is that we all tend to prefer what we grow used to and see little value in changing. Only if there appears a considerable gain are most of us willing to change, since change almost always assumes some cost. It's all about the "bang for the buck", right?

It is pretty obvious, I would think. If I run in full multi-user mode (in Debian: runlevel 2) and stop the display manager service to shut down the GUI I am still in full multi-user mode, just without the GUI running. Stopping the display manager (or, FWIW, any other service) will not suddenly switch the runlevel to single-user mode (in Debian: runlevel 1). Why should it?
It is the same in Slackware, if you are in runlevel 4 and stop the display-manager to shut down the GUI you are still in runlevel 4, you just have stopped a service.

Yes, that makes sense. I haven't used Debian for more than a few days, just derivatives and most were like this

I guess that "graphical" threw me off. That doesn't change that it is unclear in such distros, especially a so-called "user-friendly" sort, how to drop to console unless they are KDE-based since GDM, unlike KDM, has no menu entry for it.

Those user-friendly distros have all needed drivers for videocards in their repository, you can install them without dropping to a console. I guess that it is not a priority for them to make more clear how their runlevels work, since the average user never should have the need to drop to a console.

Yes that's correct and unless it has changed very recently (as it likely will over time as the adoption rate of dkms increases, as it will) one must wait until say an nVidia or ATi driver has been developed for that distro. There are numerous threads on The Net where certain chips and certain kernels have "issues", usually solved by upgrading one or both. Either is more difficult on the "friendly" distros, in general. For this reason, and just general principles, there is a gulf between "never having a need" and "never getting (or realizing) an option".

I'm guessing runlevel 3 inclusion was carefully weighed and found wanting in that advanced users would likely figure it out, and less callbacks result from limiting average users' power. I suppose much of this will become moot if and when systemd is fully Large and In Charge.

Those drivers aren't developed per distro. All distros use the standard driver, only packaged by a maintainer. That isn't rocket science either, just have a look at the Slackbuilds for the Nvidia driver (the AMD driver even is able to create packages for most distributions, including Slackware).
In most of the user-friendly distros it comes down to either use a backport repository or a third party repository, like Ubuntu's PPAs.
systemd has a runlevel like structure, called targets, used for example to start the multiuser target (runlevel 3 in Slackware) or the graphical target (runlevel 4 in Slackware).

@Toby - What's going on here? Why are you so strenuously trying to evade the issue that regardless whether you call them devs or maintainers, and though I do understand the difference, in this case it still adds up to waiting since both kernels and dkms modules, at least for nVidia from experience and from ATi I'd imagine as well lag behind on kernel releases and graphics drivers. On a system like Slackware where it is de riguer to drop to console (or even telinit 1) to do deeper work, and the value of being vanilla really shines in being able to use unpatched source as soon as it is out.

IMHO it is a clear advantage to Slackware that I can try new kernels and/or graphics drivers, or whatever!, immediately to see if it will fix some bug, or are you now going to argue with that? If you like dkms, fine. If you wish to boot right to desktop, I don't care. If you want to install and use one of the various auto-dependency resolving applications, while I would wonder why you even choose Slackware then, it's still OK with me. I have my way and it works for me and in the manner I wish it to. I distrust convenience. Any attempt at convenience is going to have to convince me that any gain is worth the cost to me. I prefer solid and I'm willing to do the work, even if the gain is only that I know it is the way I want it.

Huh? If a proprietary driver does not support a specific kernel it doesn't matter if you run that kernel on Debian/Ubuntu/Fedora/Slackware/whatever, it is still not supported, no matter if you use DKMS or not or if a distro is more vanilla. In fact, distros where being vanilla is not that important, for example Arch, get new proprietary drivers usually faster running on new kernels, since they just patch the drivers (actually, not the drivers, but the shim, that part of the driver that interfaces between kernel-module and kernel, that part that DKMS compiles when you change kernels).

Why should I argue with that? What I don't understand is why you think that this is not possible with other distros. As a former Debian user I can assure you that that is absolutely no problem.
Use what you want, I don't care. Also, I have never said that I want to use DKMS or dependency resolving package managers, I don't know where you get that from. However, that doesn't hinder me from correcting factual errors or ask again if I think that there is a misconception. Thatr does not mean I have to like something, it just means that I prefer to be correct and fair to every project.
I also prefer solid. Debian with DKMS and dependency resolving is solid, so are Suse and Red Hat. Just because I prefer Slackware doesn't make these distros or the technologies they use somehow less solid.