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.
I am not sure that the word locale be properly used in the README. I see nothing in the POSIX specification that defines a multi-byte locale.
Does the quoted sentence means that e.g. when LANG set to fr_FR.utf8 instead of fr_FR writing [0-9] was slower than writing [[:digit:]] before this release? Maybe. I didn't check. What puzzles me is that the digits 0-9 are represented with one byte in both cases.
I am quite certain that GNU grep developers really mean it when they write "locale". GNU grep behavior (and speed as a consequence) is highly affected by locale (see numerous advice on the web on speeding up grep with LC_ALL=C).
Regarding speed difference between [0-9] and [[:digit:]], I can't answer why the former was slower than the latter using multi-byte locales (I'd need to inspect the source code to understand that), but it doesn't really surprise me.
What puzzles me is that the digits 0-9 are coded with one byte in both cases (which is true for the whole ASCII character set).
I'm not sure if we are talking about the same thing, but characters in UTF8 can have variable number of bytes per displayed character.
I won't go into details, because I don't know them, but maybe that's what you are asking about?
I'm not sure if we are talking about the same thing, but characters in UTF8 can have variable number of bytes per displayed character.
Indeed. But the digits <zero> to <nine> (that make up the <digit> character class in the POSIX aka C locale, according to the POSIX locale specification) are coded using one byte in UTF8.
However in other encodings these characters are written using two or four bytes. And if the specification requires that only these ten characters be included in the digit class in the POSIX locale, and that they be included in all locale definitions, other classeslocales may include also other numerical digits. Thus in such locales '[[:digit:]]' can include more characters than '[0-9]'.
Sorry for the digression.
PS Reading /usr/share/i18n/i18n it seems that for <0>..<9> the reference for glibc be ISO C 99 (in this case at least consistent with POSIX) and that additional digits can be included in the 'outdigit' class:
Code:
% The "digit" class must only contain the BASIC LATIN digits, says ISO C 99
% (sections 7.25.2.1.5 and 5.2.1).
digit /
<U0030>..<U0039>
% The "outdigit" information is by default "0" to "9". We don't have to
% provide it here since localedef will fill in the bits and it would
% prevent locales copying this file define their own values.
% outdigit /
We can list the languages registered in glibc that include digits outside the <0>..<9> range:
Code:
grep -r outdigit /usr/share/i18n/locales
Last edited by Didier Spaier; 07-04-2017 at 06:25 AM.
Reason: s/other classes/other locales/, sorry.
I don't know if someone is interested by the slackware database with all addresses I have collected?
THANK YOU SO MUCH!! I have been collecting a similar list of URLs for my Slackhammer project. It is tedious work, and this will speed matters along nicely :-)
Newbie here, apologies if this has been discussed previously (tldr below).
I'm running Slackware 14.2 x64 as a VM in Hyper-V (using Windows at work) and I initially had some trouble booting after installation because the hv_vmbus and hv_storvsc modules required by Hyper-V aren't loaded by the huge-kernel. I'm loading these modules with an initrd, but after every kernel upgrade I have to re-make the initrd before rebooting. If I forget to do this I can't boot and I'll have to boot the installation media and chroot to the system so that i can re-make the initrd (I came to my senses and made a recovery boot in lilo with a specific kernel and initrd after having to do this a couple of times ).
Also after a kernel upgrade, if you try to use the mkinitrd_command_generator.sh, it'll complain about modules for the running kernel not being installed, so you basically have to run the mkinitrd command with the options manually, getting no help from the script (I just dump the output of the script to a file for later, add the modules and execute it after changing the kernel version before rebooting to a new kernel).
Tldr: Is it possible to have the huge-kernel include the Hyper-V modules (hv_vmbus and hv_storvsc)? It might save others from some extra work or even let them run Slackware under Hyper-V without any know-how.
Tldr: Is it possible to have the huge-kernel include the Hyper-V modules (hv_vmbus and hv_storvsc)? It might save others from some extra work or even let them run Slackware under Hyper-V without any know-how.
Most probably not.
Your best bet is to use generic kernel, then all the modules load without problem.
And if there's problem with loading modules into generic kernel, then you need to report it, because it's Slackware's error.
And module not loading into huge kernel isn't Slackware error.
Your problem most probably is related to duplicated symbols in modules and huge kernel.
Modules are built out of generic kernel and that cause some modules not to load into huge kernel.
Also after a kernel upgrade, if you try to use the mkinitrd_command_generator.sh, it'll complain about modules for the running kernel not being installed, so you basically have to run the mkinitrd command with the options manually, getting no help from the script (I just dump the output of the script to a file for later, add the modules and execute it after changing the kernel version before rebooting to a new kernel).
The mkinitrd_command_generator.sh script does support the -k option allowing you to specify a different kernel than the one you're running. You can also use -m to have it add the required modules to the command it spits out as well.
Check out /usr/share/mkinitrd/mkinitrd_command_generator.sh --longhelp for more details.
Quote:
Originally Posted by atelszewski
And module not loading into huge kernel isn't Slackware error.
Your problem most probably is related to duplicated symbols in modules and huge kernel.
Modules are built out of generic kernel and that cause some modules not to load into huge kernel.
I think you're misunderstanding (or maybe I am). The modules aren't included with huge, so it requires an initrd to load them. Once they use the initrd, whether loading the huge or generic, it works fine. They're just asking if the modules can be built-in on the huge kernel to prevent them from needing to rebuild the initrd every time a kernel upgrade is released.
Do that once, edit /etc/mkinitrd.conf as needed (for additions/deletions/etcetera), and then do this thereafter:
Code:
mkinitrd -c -k kernel_version -F
I tend to pass "-o /boot/initrd-$version.gz" to mine as well.
I poked around in mkinitrd sources some time ago, intending to allow for a way to pass an option that would automatically append a kernel version string to the initrd name, but it didn't appear to be as trivial as I wanted, so I gave up. I'd rather not introduce bugs to accompany a feature that nobody else has ever requested :-)
I bought Tomb Raider over Steam's summer sale since I haven't played a game in a while and it has Linux support. I had to add libunistring to multilib to get it working. I noticed that the version shipped with Slackware is 0.9.3 which is pushing 7 years old. The current version is 0.9.7, not sure if upgrading is necessarily needed but just FYI.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
).
