Requests for -current (14.2-->15.0)

montagdude · 09-05-2018, 12:24 PM

Quote:

Originally Posted by jostber

Add sboui to the extra or an new contrib folder for Slackware. This is a nifty ncurses application for installing programs in Slackware with resolving dependencies.

https://github.com/montagdude/SlackB...r/system/sboui

Thanks for the plug. A clarification, though: it is only for SBo or similar SlackBuilds repositories.

Jeebizz · 09-05-2018, 04:38 PM

Maybe upgrade to 4.19 for the kernel since that is slated to be LTS? https://news.softpedia.com/news/it-s...s-522452.shtml

volkerdi · 09-05-2018, 04:50 PM

Quote:

Originally Posted by Darth Vader

Is there a reason for non enabling it at all?

It seems that nobody else is enabling it (that I could find). And the kernel developers upstream made a point to disable CONFIG_ZRAM_WRITEBACK in the 4.14 kernel series.

That's enough to make me wonder about side effects and to not enable it in these next kernels. But if you see other projects start to enable this, that might convince me. We're just usually not the first to turn such options on.

Darth Vader · 09-05-2018, 05:34 PM

Quote:

Originally Posted by volkerdi

It seems that nobody else is enabling it (that I could find). And the kernel developers upstream made a point to disable CONFIG_ZRAM_WRITEBACK in the 4.14 kernel series.

That's enough to make me wonder about side effects and to not enable it in these next kernels. But if you see other projects start to enable this, that might convince me. We're just usually not the first to turn such options on.

OK, I got it.

But how about enabling CONFIG_ZSWAP, which is an in-memory compressed cache for swap? Needs only "CONFIG_FRONTSWAP=y" and (preferable) "CONFIG_ZBUD=y" (or as module)

I do not think there's something to worry, because the feature should be manually enabled in kernel command-line, with "zswap.enabled=1" (so, who enable it probably known what s/he do) and personally I used this with great success since several months in a box with 4GB RAM, which happens to use the swap often.

While using that ZSWAP, my box behavior is much much better, and the responsiveness is kept even when it start to swap.

BTW, this one, the ZSWAP is used by other distributions, and it is available at least Arch, Fedora and openSUSE. Not sure about Debian and Ubuntu.

Some links:

https://wiki.archlinux.org/index.php/zswap
https://www.ibm.com/developerworks/c...ality7?lang=en

Drakeo · 09-05-2018, 06:51 PM

Quote:

Originally Posted by jostber

Add sboui to the extra or an new contrib folder for Slackware. This is a nifty ncurses application for installing programs in Slackware with resolving dependencies.

https://github.com/montagdude/SlackB...r/system/sboui

latest does not build he needs to update his SBO-Build to point to top of extracted blob and etc but a cool program. 1.1
easier to have a git pull checkout from his git. but hey his stuff

montagdude · 09-05-2018, 09:10 PM

Quote:

Originally Posted by Drakeo

latest does not build he needs to update his SBO-Build to point to top of extracted blob and etc but a cool program. 1.1
easier to have a git pull checkout from his git. but hey his stuff

I'm not sure what you mean. The latest version is 1.1, which is available on SBo and builds fine on 14.2. I have not tried on -current. But this is not the place for this discussion; please go here instead:

https://www.linuxquestions.org/quest...rs-4175602521/

volkerdi · 09-06-2018, 12:36 AM

Quote:

Originally Posted by Darth Vader

But how about enabling CONFIG_ZSWAP, which is an in-memory compressed cache for swap? Needs only "CONFIG_FRONTSWAP=y" and (preferable) "CONFIG_ZBUD=y" (or as module)

Next time I will. Thanks for the info.

gmgf · 09-06-2018, 01:27 AM

gdb-8.2:

http://www.gnu.org/software/gdb/download/ANNOUNCEMENT
http://ftp.gnu.org/gnu/gdb/gdb-8.2.tar.xz

burdi01 · 09-06-2018, 03:26 AM

Quote:

Originally Posted by Qury

Hi Pat,
Could you please add the below to current?

1, new directory /etc/ld.so.conf.d
2, start the /etc/ld.so.conf file with the below line:

Code:

include /etc/ld.so.conf.d/*.conf

This seems to be required by virtualbox guest additions.
As far as i recall, i also had to add a line for ardour in the past as well, so i believe other programs might benefit too.

In Current64 I am using (the official build of) VB for years now and never had to implement something like your above request.
If you want we could discuss things in a separate thread.

codeguy · 09-06-2018, 11:04 AM

I run two servers at work that run samba and winbindd to auth to Active Directory. I have to start winbindd myself in rc.local, which is fine ... but on a samba upgrade when I run "rc.samba restart" it would be really cool if it could also restart winbind if its already running. (Only if its already running though)

Thanks for your time.

abga · 09-06-2018, 02:33 PM

Quote:

Originally Posted by Darth Vader

How about enabling of CONFIG_ZRAM_WRITEBACK withing kernel?

Code:

CONFIG_ZRAM_WRITEBACK=y

This option is exceptionally useful for creating a "super-swap", in the form of a ZRAM device (compressed SWAP device in memory) backed up with a real SWAP partition.

The end result is ability to create a really fast and efficient memory SWAP design, doing something like

Code:

modprobe zram

echo 1 > /sys/block/zram0/reset

echo lz4 > /sys/block/zram0/comp_algorithm

echo /dev/sdb1 > /sys/block/zram0/backing_dev

echo 8G > /sys/block/zram0/disksize

mkswap /dev/zram0

swapon -p 100 /dev/zram0

To note that my example assumes that /dev/sdb1 is also itself an 8GB SWAP partition.

---------------------------------------------------------

In other hand, how about also enabling of ZSWAP options?

That ZSWAP also (alternatively) helps on getting a super-fast SWAP design and from my own experience it works exceptionally well.

Is there a reason for non enabling it at all?

You made me curious about this zram, not sure I can follow you on zram vs. zswap, but anyway thanks for pointing it out. I'm trying to understand what's the advantage of using zswap over setting the swappiness on 1 ( echo 1 > /proc/sys/vm/swappiness ). I'm compiling a lot under Slackware ARM on very limited RAM (512MB-1GB) on Raspberry boards and by setting the swappiness on 1 I am protecting the SDCards. Doing this for some time now and never had anything written in the actual swap partition until the whole available RAM was exhausted, very rarely and mostly due to my mistakes. zswap will create some CPU overhead for the compression and finally will also write in the swap if the available RAM will get entirely used.
I couldn't find any better references ATM but Wiki (hope they're not wrong about zram&zswap):
- swappiness
https://en.wikipedia.org/wiki/Swappiness
- on zswap & zram
https://en.wikipedia.org/wiki/Zswap
https://en.wikipedia.org/wiki/Zram
"When used as a compressed swap space, zram is similar to zswap, which is not a general-purpose RAM disk, but rather an in-kernel compressed cache for swap pages. However, unlike zswap, zram cannot use a hard disk as a backing store, i.e. it cannot move less-frequently used pages to disk. On the other hand, zswap requires a backing store, while zram does not."

abga · 09-06-2018, 02:55 PM

Quote:

Originally Posted by ivandi

Another 2>/dev/null. In rc.cpufreq. /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver doesn't exist in qemu VM.

Code:

# For CPUs using intel_pstate, always use the performance governor. This also
# provides power savings on Intel processors while avoiding the ramp-up lag
# present when using the powersave governor (which is the default if ondemand
# is requested on these machines):
if [ "$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver 2>/dev/null)" = "intel_pstate" ]; then
  SCALING_GOVERNOR="performance"
fi

Cheers

I missed this one and only noticed the changes in the changelog today. I was proposing some more changes in the thread where the intel_pstate driver limitations and script changes (performance governor) were discussed.
https://www.linuxquestions.org/quest...ml#post5898109
I'm not insisting on those changes as I usually fix things for myself, but I believe the actual script is still not optimal and maybe I should use this thread for my points.
- the sentence between the brackets is wrong and should be rewritten/removed, intel_pstate does not recognize ondemand as it is not supported and falls to its default powersave.

Code:

(which is the default if ondemand
# is requested on these machines):

- I proposed to allow the user to change/override the governor from within the rc.cpufreq script, as it was before, mainly because it's in this script where the alternatives are defined

Here is my proposal, containing ivandi's update, all changes highlighted in bold:

Code:

#If you want to manually choose a governor, pick one from above and provide it to the next line.
#Please note that the intel_pstate driver supports only the powersave and performance governors.
SCALING_GOVERNOR=
# For CPUs using intel_pstate, always use the performance governor. This also
# provides power savings on Intel processors while avoiding the ramp-up lag
# present when using the powersave governor (which is the default governor)
if [ -z "$SCALING_GOVERNOR" ]; then
if [ "$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver 2>/dev/null)" = "intel_pstate" ]; then
   SCALING_GOVERNOR="performance"
 else
   #Set the default governor as ondemand 
   SCALING_GOVERNOR="ondemand"
 fi
fi

Richard Cranium · 09-06-2018, 06:48 PM

Quote:

Originally Posted by Darth Vader

Just to remember that not long time ago I proposed two solutions for improving the handling of kernels - as in keeping the previous kernels alive:

1. To use in the kernel packages the concept of "incoming" folder to store the essential files (and moving them from the sight of removepkg), then them to be moved on final place by post-install script.

This proposal was refused because it complicate the life of our honorable Gurus, who eventually should remove in a manual way those files.

2. To modify the upgradepkg to actively refuse to upgrade the "kernel-X" packages, and just to install them. A small change on upgradepkg with advantage that later the user can uninstall the old kernel packages with "removepkg"

This proposal was refused by our BDFL, as it being out of scope of "upgradepkg" for now and ever.

slackroll does it this way:

Quote:

When kernel packages have pending upgrades, you can use two operations created specifically to handle the situation. kernel-upgrade will install the new kernel packages using installpkg instead of upgradepkg and then help you configure your boot loader for the new kernel. This means that, for a small time period, you will have two versions of the kernel packages installed. After a successful reboot to the new kernel, you can use the kernel-clean operation to remove the previous versions of those packages.

khronosschoty · 09-06-2018, 07:22 PM

Quote:

Originally Posted by orbea

Just a thought, but maybe it would be better if rc.local.template was installed instead of rc.local.new and users would simply copy it once instead of remove rc.local.new everytime?

Great suggestion.

55020 · 09-07-2018, 02:54 AM

Quote:

Originally Posted by Richard Cranium

slackroll does it this way:

And that shows 2 things:

(1) It can be done in a third party tool, so there's no need to do it in the core tools.

(2) Reasonable people [1] can prefer to do it a different way [2], so there's a need not to do it in the core tools.

[1] me
[2] have a permanent emergency kernel that is unlisted in /var/log/packages, instead of the "use installpkg" idea, which I personally consider to be, at best, distasteful.