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.
Packages series are a remnant of the floppy disk era anyway. Not that useful in 2019 IMO.
Mr. Didier, you know well that's a so big big lie, that's worth of mainstream UK politicians - then permit me to dare to differ. They are exceptionally useful right now.
The packages series are the last thing which keeps a bit of sanity for those not interested to install either KDE or XFCE, or even Emacs, while they are not interested to thinker with Slackware every night.
I am very sorry to disappoint you, but even I used Slackware since long years, still I do not started even one time an Apache webserver and the FTP servers never interested me. The mail servers interested me even less.
So, why I should have them installed in my computer, as simple user not interested to study the Slackware packages and their mighty dependencies, but just to use the Slackware as is? Aren't they just useless bloat for someone like me?
Last edited by LuckyCyborg; 02-24-2019 at 03:32 PM.
Well, this has been discussed so many times... Doing a full installation does not imply that you have to use all the software in it. Nobody does.
Let me give you a counter example. In Slint a full installation is mandatory, only KDE being optional. I have a blind friend who uses it and never starts X. He uses only ttys through a Braille device, mostly using Emacs and doing maths (he is a former math teacher), also listening music, reading books and doing some shell scripting. However he never complained that Slint ships software that he will never use. He just doesn't care.
As an aside there are other ways to strip down a Slackware system, e.g. you can install just the bare minimum, install slapt-get, include in /etc/slapt-get/slapt-getrc the repository http://slackware.uk/salix/x86_64/slackware-14.2/ as main SOURCE of package, run:
slapt-get --add-keys
slapt-get -u
slapt-get -i <package that you want to add>
and you will get this package and its dependencies.
This works 99.47% of the time
Also, bear in mind that Pat guarantees that you won't miss any dependency *only* if you make a full installation.
I won't post again here on this topic in this thread, sorry to have contributed to derail it.
Best,
Last edited by Didier Spaier; 02-24-2019 at 04:10 PM.
In the era of virtualization and containers there are ever more use cases where even the a, n and l series are over ones head.
Then this MX example. Also I find the KDE, KDEi and XFCE extremely useful and well thought out.
Floppies being obsolete, there really might be some reordering and reconsidering of the series down the road? Maybe, at least, for the time after the 15.0 hits the streets?
I for one would like to see bare(i'm short of better name right now) series with a minimal system able to only boot, install and be ssh-d into.
I am fully aware that raising the issue of reviewing the install categories is a bit contentious as many people will disagree as to what application goes in which folder and what categories is considered necessary to run a modern system.
When I was looking at the n folder, I noticed that there were at least half a dozen to a dozen email programs. It's not a problem to install them but if you never use them, then it doesn't make sense to install them as it defeats the point of the categories. It just seemed to me that it should be in an Mx category because if you want to install a mail server/client you most likely would only want one installed.
I disagree that the categories should be viewed soley as from the floppy disk days. Being able to only install the bare minimum to run slackware plus the packages that you actually want is one of the things that I like most about Slackware in a age of software bloat. Because its a server running a filtering system, I don't need x, xap and kde etc. So I very much like the category concept.
It's certainly not a high priority agreed, but eventually reviewing the install categories and considering new categories or renaming/removing old categories should be looked at as computer usage has evolved quite considerably since these categories were created.
It's not something available on the installer, but take a look at the LXC Slackware template. It contains a very minimal set of packages.
The point of running it as an actual install series (or supplying an tag for an equivalent install instead) is the actual use and purpose of such a feature.
And don't think x86 only
Maybe Slackware could endorse and ship a tag-file of said package list?
Mr. Didier, you know well that's a so big big lie, that's worth of mainstream UK politicians - then permit me to dare to differ. They are exceptionally useful right now.
The packages series are the last thing which keeps a bit of sanity for those not interested to install either KDE or XFCE, or even Emacs, while they are not interested to thinker with Slackware every night.
While it might be true that keeping package sets helps with people to uninstall things, what Didier stated wasn't a lie. Pat doesn't intend for them to be used that way.
Quote:
Originally Posted by volkerdi
Arguing about which series any particular package belongs in is even more pointless than having separate package series in the first place. Really, everything should just be dumped in one big package directory so that people don't get carried away with the idea that the divisions actually mean something.
Sometimes an inventor of something doesn't always understand how useful their invention is. Or the scope of its usefulness. I think package groups are an example of this. Mr. Volkerding may not have intended for them to be used and managed the way they are in practice, but the fact of the matter is that they are, and if they were cut, many, many, users would complain.
I don't think Mr. Volkerding will ultimately cut them out. It would violate the POLA (principle of least astonishment) which is an overarching principle I believe he takes much more seriously than any opinions he may hold on package groups.
Sometimes an inventor of something doesn't always understand how useful their invention is. Or the scope of its usefulness. I think package groups are an example of this. Mr. Volkerding may not have intended for them to be used and managed the way they are in practice, but the fact of the matter is that they are, and if they were cut, many, many, users would complain.
I don't think Mr. Volkerding will ultimately cut them out. It would violate the POLA (principle of least astonishment) which is an overarching principle I believe he takes much more seriously than any opinions he may hold on package groups.
I totally agree with this, he hasn't intended for them to be used this way, even if they are. I also don't think he opposes to them being used this way, but I don't think he cares to support people who think this is some form of dependency control within Slackware. Overall, I don't foresee him removing them, but I also don't see him going out of his way to change them to fit with requests people have on here.
If things are to grow then they have to start their own life. No matter what was meant for them at the beginning. The diversity temporary/permanent is also well-known. Apache comes as I read somewhere from patches. So what was the meaning of package series now is of no importance. I was terrified by senseless pool in Debian - nightmare.
Add initrd (or linux-firmware) functionality for packaging up CPU Microcode...?
How about enhancing "mkinitrd" to (optionally) package up CPU microcode and include it in the initrd? I think this is worthwhile since mitigations for vulnerabilities like Spectre/Meltdown may be included, and not all vendors issue BIOS/UEFI updates in a timely manner.
I know there is the "-P" option to include a pre-prepared CPU microcode archive, but there's no immediately obvious way of creating the required archive.
It would be handy if mkinitrd could detect the CPU type and package up the relevant microcode. Alternatively, perhaps the kernel-firmware package install script could create the relevant archives in /boot for Intel and AMD CPUs at least?
Example:
For AMD, I've been using this little script for years. I didn't write it, and I can't recall the original source. The resulting archive can be used with the -P switch, or be manually prepended to your initrd.
Code:
#! /bin/sh
set -x
set -e
LIB=/lib/firmware/amd-ucode/
TDIR=kernel/x86/microcode
CPIO=/boot/amd-ucode.cpio
echo "Create the $CPIO file from the $LIB directory of files"
rm -rf /tmp/amd-ucode-cpio
mkdir -p /tmp/amd-ucode-cpio
cd /tmp/amd-ucode-cpio
mkdir -p $TDIR
find $LIB -type f -name \*bin | sort | xargs cat > $TDIR/AuthenticAMD.bin
find . | cpio --no-absolute-filenames -H newc -o -F $CPIO
#echo Remember to do:
#echo cat $CPIO initrd.gz \> initrd.new
#echo ...and run "lilo", etc...
exit
How about enhancing "mkinitrd" to (optionally) package up CPU microcode and include it in the initrd?
--snip--
For AMD, I've been using this little script for years. I didn't write it, and I can't recall the original source. The resulting archive can be used with the -P switch, or be manually prepended to your initrd.
Note, I'm not suggesting we shouldn't do this since it doesn't apply to everything, but... AMD doesn't need initrds to load microcode. Theirs are included in the kernel-firmware package and will be loaded automatically on boot. Intel prevents distribution of their microcode, which is why there needs to be a separate mechanism to load it during the startup of the OS.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,099
Rep:
OpenSSL-1.1.1b
Quote:
Latest News
Date
Item
26-Feb-2019
OpenSSL 1.1.1b is now available, including bug fixes
26-Feb-2019
OpenSSL 1.0.2r is now available, including bug and security fixes
Note, I'm not suggesting we shouldn't do this since it doesn't apply to everything, but... AMD doesn't need initrds to load microcode. Theirs are included in the kernel-firmware package and will be loaded automatically on boot. Intel prevents distribution of their microcode, which is why there needs to be a separate mechanism to load it during the startup of the OS.
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.
You can try to force a "late" update by running:
Code:
echo 1 > /sys/devices/system/cpu/microcode/reload
...but there are some issues with "late" updates: For example if the ucode changes the CPU feature flags it can lead to a situation where flags which were advertised at boot are removed, or conversely extra flags are added; neither of which is well handled. Therefore "early" updates via the initrd are preferred.
More details in /usr/src/linux/Documentation/x86/microcode.txt which says the distribution should do it. Quote:
Quote:
Here's a crude example how to prepare an initrd with microcode (this is
normally done automatically by the distribution, when recreating the
initrd, so you don't really have to do it yourself. It is documented
here for future reference only).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
