SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Perhaps thinking about it a different way would help. If you take Windows Server for example. When you install Windows Server, you install either core (no gui) or full (with gui). Then on top of that after you have installed Windows Server, you can install Roles such as active directory, DNS, DHCP, WSUS, WDS and so on.
Slackware does it better in that you can get rid of a lot more bloat by removing e, f, k, kde, tcl etc.
I think of a,d l and n as basically windows server core and ap as features that I can install. However a lot of Server roles seem to be in n by default eg mx servers.
I agree with Pat on one point. It's pointless arguing what should go in a, ap, d, l etc. And it's not a high priority. But I still see value in a core, full install and adding additional roles in the way windows server does it.
Anyway, if the developer sees this, he can decide what he wants to do if anything and I will be happy with whatever he comes up with as long as one can still do a bare minimum install as it were as many users like myself don't need a gui desktop server install.
I suggest to not bug Pat with requests for doing something similar, but volunteers could just set up a repository of customized tag files (on github, gitlab, whatever), that interested users could download, store on an USB stick, then use that during installation instead of the standard tag files, as the Slackware installer allows.
Last edited by Didier Spaier; 02-27-2019 at 04:56 AM.
Reason: Typo fix
many users like myself don't need a gui desktop server install
Quote:
Maybe a dedicated thread for tag files for various Slackware roles is in order?
Please! I suggest a poll, "Do you have an interest in Slackware tag files? Yes/No", to test what proportion of the community actually thinks this is important.
Personally, my answer is a flat no. But I am not trying to provision containers or run on limited hardware or limit attack surface or be a hairy chested CLI user.
Not true re AMD microcode being loaded automatically on boot. I have two AMD systems, one running Slackware-current and one running 14.2. Both are running Pat's stock kernels and neither update the microcode automatically despite there being an update available in /lib/firmware. I have to manually build the AMD cpio archive and add it to initrd.
What you show above is the original microcode version loaded by the BIOS/UEFI. There's no message about it being updated (early or late). Compare your output with mine - you're missing a line like this:
Code:
[ 6.841445] microcode: microcode updated early to new patch_level=0x0800820b
If a "late" update is done, you'd see a microcode entry with a "new patch_level=" message.
Now, it's possible yours is at the latest version, but I don't think it will update automatically if one becomes available.
I know I checked this when I first read of Ryzen microcode updates being pushed for Spectre and I'm pretty sure that I found that my microcode was updated based on what was in the linux-firmware package (but this was a long time ago, and my memory isn't what it used to be). I'm guessing the microcode was updated when ASRock pushed out their latest firmware update for my board so it now isn't being loaded by the kernel (or possibly some kernel change that broke late loading). I'll have to keep an eye on this. According to Gentoo, I'm running the latest microcode for my CPU.
make[1]: Entering directory '/tmp/x11-build/xorg-server-1.20.4/config'
CC udev.lo
udev.c: In function ‘device_added’:
udev.c:126:49: error: implicit declaration of function ‘major’ [-Werror=implicit-function-declaration]
if (xf86_find_platform_device_by_devnum(major(devnum), minor(devnum)))
^~~~~
udev.c:126:49: warning: nested extern declaration of ‘major’ [-Wnested-externs]
udev.c:126:64: error: implicit declaration of function ‘minor’; did you mean ‘mknod’? [-Werror=implicit-function-declaration]
if (xf86_find_platform_device_by_devnum(major(devnum), minor(devnum)))
^~~~~
mknod
udev.c:126:64: warning: nested extern declaration of ‘minor’ [-Wnested-externs]
cc1: some warnings being treated as errors
make[1]: *** [Makefile:686: udev.lo] Error 1
make[1]: Entering directory '/tmp/x11-build/xorg-server-1.20.4/config'
CC udev.lo
udev.c: In function ‘device_added’:
udev.c:126:49: error: implicit declaration of function ‘major’ [-Werror=implicit-function-declaration]
if (xf86_find_platform_device_by_devnum(major(devnum), minor(devnum)))
^~~~~
udev.c:126:49: warning: nested extern declaration of ‘major’ [-Wnested-externs]
udev.c:126:64: error: implicit declaration of function ‘minor’; did you mean ‘mknod’? [-Werror=implicit-function-declaration]
if (xf86_find_platform_device_by_devnum(major(devnum), minor(devnum)))
^~~~~
mknod
udev.c:126:64: warning: nested extern declaration of ‘minor’ [-Wnested-externs]
cc1: some warnings being treated as errors
make[1]: *** [Makefile:686: udev.lo] Error 1
No problem here. I've verified that the code calling major() and minor() is not #ifdefed out.
However, the package build without this patch may fails (this is a fatal error). I was able to get the package only after adding this patch. Before that, every time I got the xorg-server.failed file instead of a package.
Please! I suggest a poll, "Do you have an interest in Slackware tag files? Yes/No", to test what proportion of the community actually thinks this is important.
Personally, my answer is a flat no. But I am not trying to provision containers or run on limited hardware or limit attack surface or be a hairy chested CLI user.
I was wondering if during the next development cycle of Slackware 15, gtk-3.0 gets upgraded, could it be built with wayland-backends enabled? This would not require wayland itself, only wayland-protocols and wayland-egl, both are in SBO.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
