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.
Sat Oct 21 18:59:54 UTC 2023
a/btrfs-progs-6.5.3-x86_64-1.txz: Upgraded.
d/meson-1.2.3-x86_64-1.txz: Upgraded.
d/subversion-1.14.2-x86_64-6.txz: Rebuilt.
Recompiled against utf8proc-2.9.0.
l/nodejs-20.8.1-x86_64-1.txz: Upgraded.
Stick with the (future) LTS release to avoid compatibility issues.
Thanks to gildbg.
l/utf8proc-2.9.0-x86_64-1.txz: Upgraded.
Shared library .so-version bump.
n/irssi-1.4.5-x86_64-2.txz: Rebuilt.
Recompiled against utf8proc-2.9.0.
xap/gnuplot-5.4.10-x86_64-1.txz: Upgraded.
10 updates (x86_64). Including a (* Security fix *)! : 4 Upgraded, 1 Rebuilt, 5 Added
Code:
Sun Oct 22 19:30:42 UTC 2023
a/lvm2-2.03.22-x86_64-1.txz: Upgraded.
kde/kstars-3.6.7-x86_64-1.txz: Upgraded.
It's time for KStars in Slackware to be less of a toy and more of a useful
tool. The required dependencies have been added for EKOS, the INDI client
included in KStars, which will allow for computer control of astronomy
devices. Additional deps and drivers may be required, but these are runtime
dependencies. See (for example) gpsd, libdc1394, libftdi1, libindi-libraries,
and libindi-drivers, all of which can be found on slackbuilds.org.
Huge thanks to Edward W. Koenig for the detailed writeup - it was extremely
helpful! :-) Here's a link to the article:
https://www.linuxgalaxy.org/kingbeowulf/astronomy-device-control-in-slackware-15-and-current/
kde/libindi-2.0.4-x86_64-1.txz: Added.
This is required by kstars-3.6.7.
kde/libnova-0.15.0-x86_64-1.txz: Added.
This is required by kstars-3.6.7.
Thanks to Chris Abela, Ryan P.C. McQuen, and Philip Lacroix.
kde/stellarsolver-2.5-x86_64-1.txz: Added.
This is required by kstars-3.6.7.
kde/wcslib-8.1-x86_64-1.txz: Added.
This is required by kstars-3.6.7.
l/LibRaw-0.21.1-x86_64-2.txz: Rebuilt.
This update fixes a security issue:
A heap-buffer-overflow was found in raw2image_ex(int), which may lead to
application crash by maliciously crafted input file.
For more information, see:
https://www.cve.org/CVERecord?id=CVE-2023-1729
(* Security fix *)
l/imagemagick-7.1.1_21-x86_64-1.txz: Upgraded.
l/libev-4.33-x86_64-1.txz: Added.
This is required by kstars-3.6.7.
As this package may have more general usage than just kstars, we'll put it
in the L series.
Thanks to AA ime Ramov and Matteo Bernardini.
l/vte-0.74.1-x86_64-1.txz: Upgraded.
24 updates (x86_64). Including a (* Security fix *)! : 22 Upgraded, 2 Rebuilt
Code:
Thu Oct 26 19:55:16 UTC 2023
a/kernel-firmware-20231024_4ee0175-noarch-1.txz: Upgraded.
a/kernel-generic-6.1.60-x86_64-1.txz: Upgraded.
a/kernel-huge-6.1.60-x86_64-1.txz: Upgraded.
a/kernel-modules-6.1.60-x86_64-1.txz: Upgraded.
a/shadow-4.14.1-x86_64-1.txz: Upgraded.
d/kernel-headers-6.1.60-x86-1.txz: Upgraded.
k/kernel-source-6.1.60-noarch-1.txz: Upgraded.
Hey folks, if you've been following LQ you know I've talked before about
dropping the huge kernel and moving the distribution to use only the generic
kernel plus an initrd. After mulling this over for a few months, I think I
was looking at the problem in the wrong way. First of all, it's clear that
some Slackware users have been using the huge kernel all along, without an
initrd, and are (to say the least) unhappy about the prospect of a new
requirement to start using one. I've been recommending the generic kernel for
some time, and a major reason is that we've been using the same set of kernel
modules with two slightly different kernels. Because of this, there have
always been a few (generally seldom used) kernel modules that won't load into
the huge kernel. These are things that aren't built into the huge kernel, but
because of a difference in some kernel module dependency, they won't load.
The conclusion that I've come to here is that rather than drop the huge
kernel, or slap a LOCALVERSION on it and provide a whole duplicate tree of
kernel modules especially for the huge kernel, it would be better to make the
generic kernel more huge, and minimize the differences between the two kernel
configs.
That's what I've done here.
Shown below are the differences between the previous generic kernel config
and the one shipping in this update. You'll notice that most of the popular
filesystems are built in. At this point the main difference it that the huge
kernel has a couple of dozen SCSI drivers built into it. The modules for those
drivers won't load into the huge kernel, but they're fully built in so that
doesn't matter. If you find any other modules that will not load into the huge
kernel, please make a note about it on LQ and I'll see what can be done.
So, tl;dr - what does this change mean?
Unless your root device is on SCSI, if you were able to use the huge kernel
without an initrd previously, you should now be able to use the generic
kernel without an initrd. The kernel is a bit bigger, but we probably have
enough RAM these days that it won't make a difference.
Enjoy! :-)
-CIFS_SMB_DIRECT n
9P_FS m -> y
9P_FSCACHE n -> y
BTRFS_FS m -> y
CIFS m -> y
CRYPTO_CMAC m -> y
CRYPTO_CRC32 m -> y
CRYPTO_XXHASH m -> y
CRYPTO_ZSTD m -> y
EFIVAR_FS m -> y
EXFAT_FS m -> y
EXT2_FS m -> y
EXT3_FS m -> y
EXT4_FS m -> y
F2FS_FS m -> y
FAILOVER m -> y
FAT_FS m -> y
FSCACHE m -> y
FS_ENCRYPTION_ALGS m -> y
FS_MBCACHE m -> y
HW_RANDOM_VIRTIO m -> y
ISO9660_FS m -> y
JBD2 m -> y
JFS_FS m -> y
LZ4HC_COMPRESS m -> y
LZ4_COMPRESS m -> y
MSDOS_FS m -> y
NETFS_SUPPORT m -> y
NET_9P m -> y
NET_9P_FD m -> y
NET_9P_VIRTIO m -> y
NET_FAILOVER m -> y
NFSD m -> y
NLS_CODEPAGE_437 m -> y
NTFS3_FS m -> y
NTFS_FS m -> y
PSTORE_LZ4_COMPRESS n -> m
PSTORE_LZO_COMPRESS n -> m
PSTORE_ZSTD_COMPRESS n -> y
QFMT_V2 m -> y
QUOTA_TREE m -> y
REISERFS_FS m -> y
RPCSEC_GSS_KRB5 m -> y
SMBFS m -> y
SQUASHFS m -> y
UDF_FS m -> y
VFAT_FS m -> y
VIRTIO_BALLOON m -> y
VIRTIO_BLK m -> y
VIRTIO_CONSOLE m -> y
VIRTIO_INPUT m -> y
VIRTIO_MMIO m -> y
VIRTIO_NET m -> y
VIRTIO_PCI m -> y
VIRTIO_PCI_LIB m -> y
VIRTIO_PCI_LIB_LEGACY m -> y
VIRTIO_PMEM m -> y
XFS_FS m -> y
ZONEFS_FS n -> m
ZSTD_COMPRESS m -> y
+NFS_FSCACHE y
+PSTORE_LZ4_COMPRESS_DEFAULT n
+PSTORE_LZO_COMPRESS_DEFAULT n
+PSTORE_ZSTD_COMPRESS_DEFAULT n
kde/plasma-workspace-5.27.9.1-x86_64-1.txz: Upgraded.
l/glib2-2.78.1-x86_64-1.txz: Upgraded.
l/netpbm-11.04.03-x86_64-1.txz: Upgraded.
l/newt-0.52.24-x86_64-1.txz: Upgraded.
n/gpgme-1.23.0-x86_64-1.txz: Upgraded.
n/p11-kit-0.25.1-x86_64-1.txz: Upgraded.
n/php-8.2.12-x86_64-1.txz: Upgraded.
This is a bugfix release.
For more information, see:
https://www.php.net/ChangeLog-8.php#8.2.12
x/xorg-server-21.1.9-x86_64-1.txz: Upgraded.
This update fixes security issues:
OOB write in XIChangeDeviceProperty/RRChangeOutputProperty.
Use-after-free bug in DestroyWindow.
For more information, see:
https://lists.x.org/archives/xorg-announce/2023-October/003430.html
https://www.cve.org/CVERecord?id=CVE-2023-5367
https://www.cve.org/CVERecord?id=CVE-2023-5380
(* Security fix *)
x/xorg-server-xephyr-21.1.9-x86_64-1.txz: Upgraded.
x/xorg-server-xnest-21.1.9-x86_64-1.txz: Upgraded.
x/xorg-server-xvfb-21.1.9-x86_64-1.txz: Upgraded.
x/xorg-server-xwayland-23.2.2-x86_64-1.txz: Upgraded.
This update fixes a security issue:
OOB write in XIChangeDeviceProperty/RRChangeOutputProperty.
For more information, see:
https://lists.x.org/archives/xorg-announce/2023-October/003430.html
https://www.cve.org/CVERecord?id=CVE-2023-5367
(* Security fix *)
xap/mozilla-thunderbird-115.4.1-x86_64-1.txz: Upgraded.
This release contains security fixes and improvements.
For more information, see:
https://www.mozilla.org/en-US/thunderbird/115.4.1/releasenotes/
https://www.mozilla.org/en-US/security/advisories/mfsa2023-47/
https://www.cve.org/CVERecord?id=CVE-2023-5721
https://www.cve.org/CVERecord?id=CVE-2023-5732
https://www.cve.org/CVERecord?id=CVE-2023-5724
https://www.cve.org/CVERecord?id=CVE-2023-5725
https://www.cve.org/CVERecord?id=CVE-2023-5726
https://www.cve.org/CVERecord?id=CVE-2023-5727
https://www.cve.org/CVERecord?id=CVE-2023-5728
https://www.cve.org/CVERecord?id=CVE-2023-5730
(* Security fix *)
xfce/thunar-4.18.8-x86_64-1.txz: Upgraded.
isolinux/initrd.img: Rebuilt.
kernels/*: Upgraded.
usb-and-pxe-installers/usbboot.img: Rebuilt.
The kernel is a bit bigger, but we probably have enough RAM these days that it won't make a difference
Do the Linux kernel really allocate RAM for modules not in use? From what little I've grasped about the very efficient Linux Memory Management System, I find it hard to believe...
Do the Linux kernel really allocate RAM for modules not in use? From what little I've grasped about the very efficient Linux Memory Management System, I find it hard to believe...
Kernel memory is not swappable, so building in a driver (=y) permanently uses some memory unlike building a module (=m) and not loading it.
Distribution: VM Host: Slackware-current, VM Guests: Artix, Venom, antiX, Gentoo, FreeBSD, OpenBSD, OpenIndiana
Posts: 1,023
Rep:
Quote:
Originally Posted by Jan K.
Do the Linux kernel really allocate RAM for modules not in use? From what little I've grasped about the very efficient Linux Memory Management System, I find it hard to believe...
Quote:
dmesg | grep Memory:
substract
Quote:
dmesg | grep Freeing
regarding modules:
Quote:
lsmod | wc
first column will tell you how many modules are loaded at specific time
and
Quote:
find /lib/modules/name/ -type f | wc -l
will tell how many modules were compiled
I think that adding items as build in instead modules should be avoided. Whoever wants to run kernel without initrd should build custom kernel.
if you were able to use the huge kernel
without an initrd previously, you should now be able to use the generic
kernel without an initrd. The kernel is a bit bigger, but we probably have
enough RAM these days that it won't make a difference.
..And hast thou slain the Jabberwock?
O frabjous day! Callooh! Callay!
They chortled in their joy!
'Twas bryllyg...
So far the new generic kernel has not needed a initrd on any of my machines, virtual or bare metal. The only exception is -current that I have running on my proxmox server. That is because that VM still needs the virtio_scsi module. but thanks to Pat's heads up in the changelog I was prepared.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.