Probably didn't have to state the obvious.
Stronger compression reduces file size, which is why for example youtube requires a lot of CPU power to encode/decode and less bandwidth to actually use.
And whatever, I'm not trying to argue, just saying unpacking "ucode" and few other files with mc, is multiple times faster than doing "upgradepkg".
Same thing goes for kernel-source because of many checks upgradepkg does on the huge directory tree and great number of files. I don't think it's xz problem, TBH.

Correct. In Slackware 15.0:So no, this does not save bandwidth for me. More exactly for Tadgy, who kindly hosts the Slint repositories for free, thanks Darren!

As an aside, the size on Slint 15.0 is slightly smaller than in Slackware15.0, due to a different file system used.

Be interesting to get Hazel to weigh in. I know she's got some bandwith issues at her place, so this is something that's in her area of expertise.

No, it's rather a bash problem. spkg is way faster in this case because it is a compiled application written in C.

So I guess trade some minor reduction of install-time requirements, for increased traffic and increased run-time requirements?
How is that rational? I thought we're talking about splitting firmware, in order to reduce traffic and runtime-requirements.
This took some unexpecting turn, I didn't realize at first what you were trying to achieve.

You can easily remove the three worst offenders.

Ed

increased traffic, yes, run-time requirements, no, as Petri has clearly explained.Did you really measure the time needed to load the few firmware files you are using?
I achieve two things:

1. Less space on disk needed (around 460G saved). This is useful also for Slackware.
2. Specifically for Slint allow to ship the whole kernel-firmware package in the initramfs of the installer, to allow using any wifi card for net install, while not requiring more than 2G of RAM and not wasting my time maintaining split firmware packages.

As an aside I also ship zstd compressed kernel modules in the initramfs.

3 members found this post helpful.

Honestly, I do NOT miss in this forum the traditional Ubuntu threads like "My CrapOne WiFi card does not work. Please help me!"

I for one I believe that the idea of splitting firmware in Slackware (and Ubuntu too) is worth of an Ig Nobel Prize

You are nuts, people? Even the Ubuntu, with it's apt-get and a hell of hardware auto-detection, have a hard time with those split firmware. On Slackware this will be really, but really nasty - unless, of course, in the traditional Slackware way, shall be installed all firmware packages. And we will end with installing 100 packages instead of one.

5 members found this post helpful.

I was just going to mention that in Slackware-11.0 the modules were gzipped but not after that. I wonder why. Man and info pages are still gzipped. There is the same trade-off there: gzipped man and info pages take less space on disk but make txz packages larger and need CPU cycles to browse on elcore's system.

1 members found this post helpful.

Technically, it's pkgtools logic and not bash fault, because mc also uses bash commands to unpack files from txz to filesystem.
There's room to improve this feature efficiently; my solution (for firmware and source package) is to bypass upgradepkg and just do rm-rf followed by installpkg.
Usually, not something fit for general public distribution.
But if you have ideas on how to improve it without increasing any requirements, that'd be great.

Note that there are six other packages putting firmware files there besides kernel-firmware. You may have removed more than you thought.

3 members found this post helpful.

I've always wondered how these distributions manage the firmware packages. I remember that in Fedora, these firmware packages appear as dependencies.

Maybe, on full install. I don't have/use any, apart from ucode and 2x nic.

Well, there's a system of hardware auto-detection, which tries to find the kernel modules which are needed for the system, then this is mapped to packages which contains those modules, then the associated firmware packages are dependencies of the kernel modules packages.

So, as example: when you plug a new WiFi dongle in your computer, Ubuntu asks you to install the support packages. That's great, WHEN it works. Because sometimes this hardware auto-detection logic fails, and the user ends with a WiFi dongle which does not work at all.

BUT, those are the main features used: the hardware auto-detection and the packages management with remote binary repository support - and of course, the packages dependency resolution is fundamental. And many, many packages of firmware and kernel modules.

1 members found this post helpful.

I agree with you that automatically installing only the firmware required by the installer, slackpkg or pkgtools would be difficult in Slackware.

But, on the other hand, if the kernel firmware were divided into 100 packages, advanced users like is @elcore or @Hazel, for example, could install only the firmware packages they need, and the rest could end up in the slackpkg blacklist.