Here are some initial Phoronix-test-suite benchmarks for the miniITX Rysen 7 with various GPUs I had on hand. For Nvidia, we used the their proprietary driver; for AMD, the open source radeon and amdgpu drivers provided in Slackware64-current kernel 5.4.2, 5.4.3, 5.4.5 (nvidia, radeon, amdgpu, resprctively - Slackware updates were fast and furious this week!).

The CPU cooler is a low profile SilverStone SST-KR01 so that the power supply would fit. Power is provided via a Rosewill HIVE 650S 650W ATX power supply. The Nvidia EVGA GTX 950 is an ITX form factor GPU; and thus, the results are with the case closed. The 2 radeon GPUs are huge and are attached via a PCI-E riser with the case open.
Phoronix Test Suite from Slackbuilds.org; stock KDE4; system and tests use default settings. For the RX590, the "HIGH" run references setting the GPU power management to "high" from the default of "auto".

So far am quite pleased and can't wait to get my hands on a Vega or NAVI series GPU, and of course Slackware 15.0 "real soon now."

It was a shame to toss a perfectly good mini-ITX case (Coolermaster Elite 110), so with the assistance of a mysterious benefactor, and fellow Slackware fan, I now have the components:

It will be interesting to see what does and doesn't work OOTB for kernel 4.19.xx and 5.4.xx. Now I just need a good sale for some AMD Navi GPUs. I have an assortment of older AMD and Nvidia to try out in the meantime.
Stay tuned!

It was only a matter of time, I suppose, but my old Pentium 4 box used as a hobby server is no more. A fast thunderstorm with hail moved through our area. Of course, we lost power for several hours. Rather than hope the UPS will last long enough, I powered the ol' box down. Unfortunately, the P4 had issues powering up and booting. When it did boot, it was missing some memory and a had number of other motherboard glitches. I was planning on moving everything to the M91p with the release of Slackware64-15.0, anyway.

It is time.

Welcome our "new" server!

[UPDATE: Now running on a Slackware Linode with Wagtail CMS. -KB Jan 2, 2021]

I purchased this game on sale at GOG.com a while back (2014?) when I was exited about the Linux port, and before I realized it used the wrapper eON translation layer. (We can quibble over wrapper vs API vs etc here: PSA: eON is not a wrapper).

I'll just say that native linux code would be better.

Performance with Slackware64 multilib with Nvidia GTX 660 was poor: crashes, video glitches, lags, sudden fps drops. I was barely able to complete the tutorial section. A few patches were released that improved performance. There was also github project that tracked Linux updates and performance tweaks which now seems to be gone. I put the game aside for awhile to let it mature.

GOG.com updated Witcher 2 to Release 3, and it is officially tested on Ubuntu 16.04 LTS, Ubuntu 18.04 LTS, and variants. Non-Ubuntu Linux distributions are not officially supported - as in no technical support or refund. As a Slackware user, I have found that par for the course. Here are some notes on giving Witcher 2 another go.

Witcher 2 is a 32-bit program, so multilib and compat32 libraries are not needed on the Slackware 32-bit release.

The installer script runs perfectly to install the game and create desktop and menu entries. Running from the desktop brought up the launcher. However, the play or option menu opens with an error. Running via the terminal, shows a surprise for non-systemd linux distributions: a dependency on libsystemd.so.0. Another Slackware user posted the fix on the GOG.com forum:

LINUX Witcher 2 non-debian distro compatibility bug AND solution

Simply delete or rename /game/libdbus-1.so.3.14.6 and the libdbus-1.so.3 symlink, and the game will use Slackware's libdbus-1.so.3.14.6. Now the game will work as intended.

Witcher 2 runs much smoother at even 4K resolution. Battles with large groups are now possible. I'll probably eventually play on a 1080p monitor to further smooth out the frame rate and reduce the tearing in cut scenes. There are some optimizations and tweaking to do, but I will leave that as an exercise for the reader.

On the Lenovo T510 laptop I use to track and test Slackware-current, everything I've played with has been good so far. About a week ago, after another kernel update (4.19.48 and .49), the wifi kept dropping off when using Network Manager via the KDE network applet in the systray. Wired connectivity was fine. I at first though the Netgear R7000 router was gimpy since I had just updated it's firmware as well. The laptop would drop the connection after a few hours, and DHCP would take several minutes, if it connected at all. Usually, '/etc/rc.d/rc.networkmanager restart' (or stop, start) would fix the issue for a while. However, other devices (phones, tablets, Slackware-14.2...) remained connected with no issues. Using the command line nmcli and nmtui worked with no connectivity issues for several days. There has been another kernel update, and I haven't tried Xfce yet.

UPDATE: Looks like the updates from last week (kernel 4.19.51 now) seemed to fix this odd Network manager applet glitch.

Announced on the SBo mailing list and his blog, a long-time Slackware user and SBo buildscript maintainer, has cited both Slackware and SBo in a recent publication from his research group. Read more in his blog and paper below.

Slackware and SlackBuilds.org cited in a scientific publication

Computational analysis of the evolutionarily conserved Missing In Metastasis/Metastasis Suppressor 1 gene predicts novel interactions, regulatory regions and transcriptional control

Nvidia released a security bulletin and driver updates fix 8 security issues. One, CVE-2018-6260, can impact Linux users:

The updated drivers are already in Slackbuilds.org. For non-Slackware Linux systems, please check your respective update repositories. Also, note that older Nvidia GPUs designated as EOL may not have their legacy drivers updated. For information on mitigating CVE-2018-6260, refer to the driver Known Issues section of the README.
Nvidia Linux Driver Known Issues

References:
GeForce Driver Updates Contain Security Fixes
Security Bulletin: NVIDIA GPU Display Driver - February 2019

This is a very simple bridge example to allow your qemu quest to access your host's LAN and internet, as opposed to being isolated to access only the internet via NAT (the default), for a Slackware64 14.2 host and a Windows 10 guest. Note: in this case you will need to install the Windows 10 virtio drivers, otherwise you can just use one of the standard emulated qemu NICs. Create the ACL file to allow user access to the bridge. As root create '/etc/qemu/bridge.conf' with the lines:

Then set permissions:

This last setuid is needed if you didn't already do so when you built qemu. Now you can run qemu and access the br0 interface as an unprivileged user. This is the default if you installed qemu via Slackbuilds.org. Next, configure '/etc/rc.d/rc.inet1.conf' to set up the bridge interface at each boot:

Now, run the network script to set it all up:

The bridge should now be set up and linked to the host eth0 interface.

Logout of root, and as your local user you can now run the qemu VM. For example (legacy):

Alternatively (modern), use

The Linux Counter project shut down a few days ago. It had a good run. I'm sad to see it end, and also that it never quite developed the popularity to fully serve its purpose. Commercial / proprietary software installed base is easy to count: sales. With F/OSS it is difficult to get a true count of the number of systems running Linux distributions. Raw downloads aren't a reliable count for systems actually in use.

Wikipedia: Linux Counter

I've uploaded the new nvidia-{driver,kernel}-410.73 SBo build scripts. Lots of changes, new GPU support and updates to vulkan. Be sure to check on the changelogs at nvidia.com. I also renamed the prior version nvidia-legacy390-390.87 as it is now on Nvidia's legacy branch, and the last version to support 32-bit.