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.
Starting from Linux kernel v5.6, the HAVEGED **service** has become obsolete. The userspace application as well as the haveged library are not affected. There are two main reasons for that:
2) Furthermore, as soon as the CRNG (the Linux cryptographic-strength random number generator) gets ready, `/dev/random` does not block on reads anymore. See the [kernel commit.](https://github.com/torvalds/linux/co...baa51bb4c44e32)
I'm happy that these changes made it into the mainline kernel. It's nice to see that the main idea behind HAVEGED has sustained time test- it was published already in 2003 [here.](https://www.irisa.fr/caps/projects/h...ege-tomacs.pdf)
I'm also glad that the HAVEGE algorithm is being further explored and examined - see the [CPU Jitter Random Number Generator.](https://www.chronox.de/jent.html)
I will keep maintaining HAVEGED - there are a couple of reasons for that:
* Most Linux installations are still running on the older kernel versions.
* HAVEGED can also be used as the userspace RNG to generate random numbers. See `man -S8 haveged` for examples or try running `haveged -n 0 | pv > /dev/null`
* Last but not least, HAVEGED can be used as the RNG library.
Fix a critical bug in pipewire-pulse buffer size handling that made some apps (MuseScore, ... ) stutter.
Fix a critical bug where devices would not show when the kernel was compiled without VERBOSE_PROCSFS.
JACK clients will now use lock-quantum by default. This makes sure that all dynamic quantum changes are disabled while a JACK app is running. The only way to force a quantum chance is through a JACK app or with the metadata.
Almost all limits on number of ports, clients and nodes are removed.
A Dummy fallback sink is now automatically created when there are no other sinks. This avoids stalling browsers.
Sound sharing with Zoom should work better. A new WirePlumber release might be required.
The kernel is fine , have enabled the opcion , the only one difference, is firmwares for now only support compress under xz , but i no see issues , cause if think arround system can load 3 o4 firmwares ,and impact is 0 cause load minimal number of this files.
The kernel is fine , have enabled the opcion , the only one difference, is firmwares for now only support compress under xz , but i no see issues , cause if think arround system can load 3 o4 firmwares ,and impact is 0 cause load minimal number of this files.
There is a proposal to compress the firmware files using zstd. Maybe for linux-5.18?
I am interested because the Slint installer's initrd is huge (and it ships not only all wireless modules but also associated firmware).
Last edited by Didier Spaier; 02-17-2022 at 04:37 PM.
Reason: correction: 5.18, not 5.16.18
There is a proposal to compress the firmware files using zstd. Maybe for linux-5.18?
I am interested because the Slint installer's initrd is huge (and it ships not only all wireless modules abut also associated firmware).
YEA , zstd is great , xz have better rate compression but need more cpu/ram , zstd have better balance.
After all , we need the external patch , cause the kernel only comprees the original build firmwares , but distros , provide the all firmwares-linux from external way.
Time to wait and see , but as i say , i test under xz , 700mb to 300mb saves me 400mb of hdd , and the more important difference is modules all load a big number of that , but firmwares normally 4 or 5 only per system ,then xz is not a big problem cause load a minimal number of this files. But i prefer if compress , all in same format of compression rater xz + zstd , all zstd.
Last edited by USUARIONUEVO; 02-17-2022 at 04:05 PM.
Time to wait and see , but as i say , i test under xz , 700mb to 300mb saves me 400mb of hdd , and the more important difference is modules all load a big number of that , but firmwares normally 4 or 5 only per system ,then xz is not a big problem cause load a minimal number of this files. But i prefer if compress , all in same format of compression rater xz + zstd , all zstd.
Well, I just checked: in the Slint64-14.2.1.4.iso, the uncompressed initrd includes all wireless firmware files, so this amount to no less than 259M. So I am interested to avoid requiring too much RAM only to load the initrd...
So, being not registered to the LKML I just wrote privately to Takashi Iwai who sent the RFC to tell him that I can propose this use case, ask which gain can be expected in terms of size and decompression time, and ask if I can just apply the proposed patches to test on a 5.16.n kernel.
PS And in Slackware-current the kernel-firmware package weighs no less than 792M uncompressed, so yes compress that is worth it be it with xz or with zstd.
Last edited by Didier Spaier; 02-17-2022 at 04:43 PM.
Well, I just checked: in the Slint64-14.2.1.4.iso, the uncompressed initrd includes all wireless firmware files, so this amount to no less than 259M. So I am interested to avoid requiring too much RAM only to load the initrd...
So, being not registered to the LKML I just wrote privately to Takashi Iwai who sent the RFC to tell him that I can propose this use case, ask which gain can be expected in terms of size and decompression time, and ask if I can just apply the proposed patches to test on a 5.16.n kernel.
PS And in Slackware-current the kernel-firmware package weighs no less than 792M uncompressed, so yes compress that is worth it be it with xz or with zstd.
no compressed firmwares lib 700mb
compressed firmwares 300mb
Thats under xz , i dont know size beneits under zstd.
But you miss some interesting to you , can compress /lib/firmwares , but can leave uncompressed if want in initrd.
You can mix , like modules , i have kernel modules in zstd , and some extra like nvidia uncompressed , kernel can load at time compressed and uncompressed modules/firmwares. :=)
If some one want test compressed firmwares , take the patch from archlinux ...and
clone firmwares git
cd firmwares
Quote:
patch -p1 < ./0001-Add-support-for-compressing-firmware-in-copy-firmware.patch||exit 1
make DESTDIR=$PKG FIRMWAREDIR=/lib/firmware installcompress
Last edited by USUARIONUEVO; 02-17-2022 at 04:55 PM.
2022 February 18 - GNU nano 6.2 "Kamperfoelie"
- The file browser clears the prompt bar also when using --minibar.
- Linting now works also with a newer 'pyflakes'.
Command "removepkg kernel-source" takes very long time to complete because of directory scanning.
Not really a request just observation, I've did it on some old netbook and it takes like 5min.
I'll use rm -r for that package in the future, it is done in few seconds.
Since rEFInd 0.13.2 builds from source without issues on 15.0 I would like to ask for inclusion in mainline Slackware again.
If it is included already i apologize.
There is this thread I started where I try to find a solution to a problem in the texlive-extra package, namely, cm-super fonts not being picked up by the LaTeX compiler, although they were installed as part of texlive-extra.
I was made aware of this by someone who complained about the font quality in my documents. Some Googling revealed the reason to be this problem with cm-super. Apparently, this font package is expected to be found on any modern LaTeX installation. Therefore I would like to suggest moving cm-super from texlive-extra to the official core texlive package.
There was also this thread where I suggested moving libcryptsetup (and its new dependencies) back under /lib(64), or else, updating the documentation and relevant scripts to warn the user that LUKS lock/unlock mechanism at boot will get broken if /usr is mounted on a separate partition than root.
There was also this thread where I suggested moving libcryptsetup (and its new dependencies) back under /lib(64), or else, updating the documentation and relevant scripts to warn the user that LUKS lock/unlock mechanism at boot will get broken if /usr is mounted on a separate partition than root.
IF I remember right, Slackware does not support anymore the installations with separate /usr , so it' just your own fault that you use it in unsupported ways. Please be kind to accept that you are the one to blame. After all, the cars aren't supposed to fly, the airplanes aren't supposed to run in highways.
However, there is a way to use a separate /usr partition: to mount it in an initrd, modifying the init script from it. I use this way on several computers, where for putting the elephant in a kitchen, I use a compressed squashfs for /usr .
In my humble opinion, the real issue it that our stock initrd is as customizable like is a wood log and they think that nobody ever will need to modify it.
IF I remember right, Slackware does not support anymore the installations with separate /usr , so it' just your own fault that you use it in unsupported ways. Please be kind to accept that you are the one to blame. After all, the cars aren't supposed to fly, the airplanes aren't supposed to run in highways.
I made two suggestions: Revert the chage, or, reflect the change in the documentation. This is the first time UPGRADE.TXT has failed me. I understand that the new tendency is to have /usr available at boot, but apparently this turned into a requirement for Slackware in the transition from 14.2 to 15.0. I just ask that this be made explicit in the docs. The installer warns you not to mount /sbin etc from a separate partition. Why not add /usr to the list there?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
