LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
 
Search this Thread
Old 03-24-2014, 09:10 PM   #31
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Whatever fits the task best
Posts: 16,207
Blog Entries: 2

Rep: Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424

Quote:
Originally Posted by enorbet View Post
Additionally, I prefer to install proprietary graphics drivers myself and they require either runlevel 3 or dkms on other distros than Slackware, and if there is a way to avoid dkms on a given distro, I do.
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.
 
Old 03-25-2014, 06:40 AM   #32
enorbet
Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware 14 is Main OpSys on Main PC, 2ndary are OpenSuSe 13 and SolydK
Posts: 787

Rep: Reputation: 386Reputation: 386Reputation: 386Reputation: 386
Quote:
Originally Posted by ReaperX7 View Post
Just a reminder, but always check the status of your video card driver support level on AMD's website. Often from time to time, some video chipsets get pushed to legacy support, or passed off to the free driver provided by Xorg.

Running the latest kernel is always recommended as the later kernel versions now have better system control features not available in some earlier kernels including stable ones like those Slackware uses.

For AMD you always want to run the latest versions of each of these:

Linux Kernel
LibDRM
XServer
and
LibMesa+XF86-Video-ATI
or
AMD-Catalyst
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.
 
Old 03-25-2014, 06:45 AM   #33
enorbet
Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware 14 is Main OpSys on Main PC, 2ndary are OpenSuSe 13 and SolydK
Posts: 787

Rep: Reputation: 386Reputation: 386Reputation: 386Reputation: 386
Quote:
Originally Posted by TobiSGD View Post
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.
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.
 
Old 03-26-2014, 12:20 PM   #34
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Whatever fits the task best
Posts: 16,207
Blog Entries: 2

Rep: Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424
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.
 
Old 03-26-2014, 01:17 PM   #35
enorbet
Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware 14 is Main OpSys on Main PC, 2ndary are OpenSuSe 13 and SolydK
Posts: 787

Rep: Reputation: 386Reputation: 386Reputation: 386Reputation: 386
Quote:
Originally Posted by TobiSGD View Post
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.
 
Old 03-26-2014, 05:05 PM   #36
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Whatever fits the task best
Posts: 16,207
Blog Entries: 2

Rep: Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424
Quote:
Originally Posted by enorbet View Post
I prefer to install by the manufacturers' instructions and generally don't care for automated installs.
Then you will be delighted to hear that DKMS is supported by Nvidia's binary installer.
Quote:
Xandros had Runlevel 3 disabled and so does Ubuntu and afaik pretty much all Debian derivatives.
Indeed, almost all Debian based distros do only use one runlevel.
Quote:
There are ways around it but it's a pita to me.
IMHO, I don't think running
Code:
service gdm3 stop
to shut down the GUI is a pita, but YMMV.
 
Old 03-26-2014, 05:23 PM   #37
Raied_F1
Member
 
Registered: Mar 2014
Location: Uk
Distribution: FreeBSD
Posts: 57

Original Poster
Rep: Reputation: Disabled
thank you evry one guys . great support from great people ..
 
Old 03-26-2014, 08:25 PM   #38
enorbet
Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware 14 is Main OpSys on Main PC, 2ndary are OpenSuSe 13 and SolydK
Posts: 787

Rep: Reputation: 386Reputation: 386Reputation: 386Reputation: 386
Quote:
Originally Posted by TobiSGD View Post
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
Code:
service gdm3 stop
to shut down the GUI is a pita, but YMMV.
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?
 
Old 03-27-2014, 06:05 AM   #39
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Whatever fits the task best
Posts: 16,207
Blog Entries: 2

Rep: Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424
Quote:
Originally Posted by enorbet View Post
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?
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.
 
Old 03-27-2014, 06:47 AM   #40
enorbet
Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware 14 is Main OpSys on Main PC, 2ndary are OpenSuSe 13 and SolydK
Posts: 787

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

Quote:
Originally Posted by runlevelwiki
Ubuntu

Ubuntu 6.10 (Edgy Eft) and later contain Upstart as a replacement for the traditional init-process, but they still use the traditional init scripts and Upstart's SysV-rc compatibility tools to start most services and emulate runlevels.
Ubuntu runlevels

Code Information
0 Halt
1 Single-user mode
2 Graphical multi-user with networking
3-5 Unused but configured the same as runlevel 2
6 Reboot
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.
 
Old 03-27-2014, 07:08 AM   #41
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Whatever fits the task best
Posts: 16,207
Blog Entries: 2

Rep: Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424
Quote:
Originally Posted by enorbet View Post
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.
 
Old 03-27-2014, 03:50 PM   #42
enorbet
Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware 14 is Main OpSys on Main PC, 2ndary are OpenSuSe 13 and SolydK
Posts: 787

Rep: Reputation: 386Reputation: 386Reputation: 386Reputation: 386
Quote:
Originally Posted by TobiSGD View Post
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.
 
Old 03-27-2014, 05:06 PM   #43
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Whatever fits the task best
Posts: 16,207
Blog Entries: 2

Rep: Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424
Quote:
Originally Posted by enorbet View Post
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.
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).
Quote:
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.
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.
Quote:
I suppose much of this will become moot if and when systemd is fully Large and In Charge.
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).
 
Old 03-27-2014, 09:06 PM   #44
enorbet
Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware 14 is Main OpSys on Main PC, 2ndary are OpenSuSe 13 and SolydK
Posts: 787

Rep: Reputation: 386Reputation: 386Reputation: 386Reputation: 386
@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.
 
Old 03-27-2014, 09:34 PM   #45
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Whatever fits the task best
Posts: 16,207
Blog Entries: 2

Rep: Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424Reputation: 4424
Quote:
Originally Posted by enorbet View Post
@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.
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).

Quote:
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?
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.
Quote:
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.
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.
Quote:
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.
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] GPL question (Version 2, June 1991) - physical media availability question LicenseQuestions Linux - Newbie 1 12-01-2012 06:34 PM
basic html question - download link to files on my webpage question Davno Linux - Server 5 12-25-2009 07:24 AM
linux distro question & mysql install question natalie.aloi Linux - Newbie 5 07-19-2009 08:28 PM
Question, Apples Contribution to Open Source + MacOs file structure question Higgy3k Other *NIX 5 07-25-2005 04:23 AM
Not your regular GRUB question - just a short question for a fried MBR!! ziphem Linux - General 3 01-31-2005 01:51 PM


All times are GMT -5. The time now is 02:30 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration