More noob coolness
 

OK, so I just inherited my kid's Athlon X4 and I threw Slack 14.2 on it, but Xorg kept crashing with the Noveau drivers, so I had to figure out how to build and use the Nvidia drivers from Slackbuilds. The office comp is all Intel, so the drivers are fine in there. A couple of trials and error, and Slack is solid as ever. This rig's in the living room so I can watch Twitch and stuff when I'm not writing the next great American novel. TTY's are 80x24, but nothing in life is perfect.

Speaking of the other rig, I wanted to update the Intel microcode in there, so I did some searching and found the process. More Slackbuilds, but this time the trick was to build AND install the iucode program before I build the microcode. Otherwise, the intel file I needed in boot wouldn't appear. That was just from not paying more attention to the instructions. Oh, and according to the Gentoo guys, microcode_ctl is deprecated, so I didn't end up using that.

So, once again, there was something I wanted to do and Slack just did it, once I understood what it was I wanted. Video drivers and microcodes are stuff that I've never tried to use before, but when a distro makes it this easy to learn and do new stuff, somebody did something right when they put it together.

Oh, and speaking of novels, anytime you need a quick PDF that works anywhere, forget Pandoc. Just grab text2html from SlackBuilds, and build it. Then throw some Control-L's where you want pagebreaks, and voila, instant PDF with pages. 7-bit PDF's, but I got better things to do with my time than spend time formatting stuff for books I just give away anyway.

BTW, ratpoison on a 1920x1200 is the rat's pajamas. More real estate than on 1920x1080, and Tmux means it's completely mouseless (startx -- -nocursor ftw). I just wished I hadn't waited so long for the upgrade.

That's about all the irrelevant stuff I can think of for now. One of these days I'll do something that everyone else hasn't already been doing for years, and then I'll really be something.

Stay cool, and keep Slacking
Launfal

sorry I stop reading at nvidia slackbuilds. That is not the slackware way acording to the slackware documents. Slackbuilds on that build does not conform to Slackware.
https://docs.slackware.com/howtos:ha...aphics_drivers
you will find your self down the rode with a switch that never switches. Slackware is KISS slackbuilds is wonderful but not always the Slackware way. Ok going to read the rest reply later.
Nvidia gives you an option during install to blacklist just like slackware wants. why because Slackware is built to run programs vanilla
That means a programer spent years working on something to run stable so let it run stable on slackware. KISS

Granted I do not fully understand what your post is saying about slackbiulds, but please see Linux Questions

As for me, when I set up a new box with Slackware I know I do things not "the Slackware way". But that is the best thing about Slackware. I can easily do things on Slackware (my way) that range from difficult to next to impossible in most distro :)

OK, color me confused. That docs link describes two methods of installing the Nvidia drivers, and the SBo instructions are what I did: Download the legacy drivers with dependencies and run the SlackBuilds. If I read the official docs and follow the instructions, which part of the Slackware Way do I not conform to?

Not conform your learning slackware linux. Slackbuilds is a wonderful tool and like many things if you do not understand slackware and linux you can break a ton of stuff using slackbuilds. conform is not what i mean sorry I said slackware way is documented slackbuilds. is another path. alien bob slackbuilds is anopther path. then you have Patricks path since you bring this up. it is very simple since you use a legacy driver some may need patched look at the patch where did it come from and how was it made. and why was it made. If you have a legacy device that needs patching for a newer version of xorg most of the times your just telling the installer to not see the problem. Keep it simple. do you really need qt5 from slackbuilds for many things no. but they push it down your throat. learn what slackbuilds is and understand has very little to do with slackware way. It is a great tool use it as you need i do.

My advice is to carefully follow the instructions (nvidia-switch) if you decide to remove the SBo nvidia driver. I just use the nvidia run file and use the slackbuild when that doesn't work. Also with slackpkg blacklist xf86-video-nouveau and [0-9]+_SBo if you haven't (which I suspect you probably have).

There are a lot of nice repositories in this community.

Yeah, blacklist-nouveau is installed. I saw the instructions for nvidia-switch, but on this machine, Xorg will crash without the binary driver. Every time. I was just about to try one of the 'Buntus before I checked out SlackDocs and gave building the drivers a shot.

There sure are. I prefer to build everything I use locally, but for some of the heavy monsters, it's nice to know that there are repos I can trust to find a pre-built binary.

There is also /etc/slackpkg/blacklist which prevents slackpkg from installing/removing packages.

Just FTR, I too prefer and have done for going on 17 years, dropping to runlevel 3 and running nVidia's run file installer. I like that it is an interactive install asking me, for example, if I want to install the 32 bit compatibility drivers and that it comes with glx and mesa that works with each driver. I always build a custom kernel sans initrd and I have never had nVidia's installer fail on me as long as I had the correct driver. In the past several years even that has become easier with nVidia's manual search function where one enters either 32 bit or 64bit Linux and selects the appropriate video card.

It even handles uninstalling previous ones before installing upgrades so I see no reason, especially on a system that doesn't require KMS, for employing a Slackbuild. I choose nVidia exactly because they are longtime veterans at "alternate" operating systems. I support them because they have never failed to support my needs. Despite Linus' and others' complaints, nVidia does it right in my book. I love OSS but it has always been my understanding that the GPL promotes coexistence, and I think that's a good thing.

Before I even knew of the existence of SlackBuilds for NVIDIA's driver, I was using this exact method. In my experience, this is the simplest method to install a new driver, or have an old one link to a newly-compiled kernel. It has the advantage that the installation and upgrade paths are relatively clean, and there's no messy files left behind.

As some of you know, I upgraded from an ASUS R9 270 to a pair of NVIDIA GTX 970 in SLI, and have since had no reason to regret my purchase. NVIDIA's engineers have done a superb job of implementing hardware and software, and there's nothing of significance that I would have changed. I will probably upgrade to the 10xx series once I upgrade to Ryzen. Of course, by then, NVIDIA's architecture would probably have progressed by several orders of magnitude, but that's technology for you.

There's nothing wrong with coexistence, and as long as it gets the job done, it can be considered a good thing (TM).

Happy Slacking!

As an update, on the advice of several in this thread, I backtracked the Nvidia drivers I had built and downloaded the legacy Nvidia installer and ran it.

Never having used it before, I have to admit, that was as painless as it gets. Answer a few simple questions then let it do its thing.

Chalk one up for living and learning. Thanks everybody for the heads up.

I like slackware because of it's package system, and when slackbuild.org doesn't have a build, or when it's build failed or didn't work, I've rolled my own packages--except for nvidia. Like Enorbet, I've just used their .run file and it's always worked... It kind of irritates me though--just not the slackware way--no entry in /var/log/packages, etc. I've wondered if it would be possible to install slackware into a folder; install it again into a second folder, and copy the .run script to second folder; chroot into second folder, execute the .run script, and then exit the chroot. Wouldn't a diff between the two folders reveal every change the .run script made. Then couldn't I make a /tmp/nvidia folder, duplicate the slackware file system in /tmp/nvidia, and copy the changes to the appropriate directories in that file system; give it a slack-desc and an .install, and then use makepkg?

Seemed conceivable... but haven't had time to try yet...

Has anyone else ever built a package from some 3rd party .run script this way?

I don't know about building a script, but I do know 55020 uses a similar method on his slackrepo program and builds everything inside a chroot, but he still uses normal packaging methods and then checks the chroot for to see if there's any files that were modified that shouldn't have been (in general, pretty much anything outside of the build and packaging directories should be off limits to changes by compiling programs).