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.
This seems to have broken slackpkg for me using -current. I didn't think to save my old mirror file, but it's now looking for slackware64-15.0 folders that don't exist.
Reading between the lines there, I think Lennart was more upset that this was in the kernel rather than being left for systemd to "manage".
Besides, while sessions were invented to support job control in terminals, plenty of GUI launchers use setsid(2) to put GUI apps into their own session, so it's not just ttys this effects.
Anyway, as I said, In practice I found "nice" works better for me. I use this alias to create low-priority shells for background jobs to run in: alias nicesh="chrt -i 0 ionice -c 3 -- ${SHELL:-/bin/sh}"
Nope, that change should have been left until release day. Shipping a file that references locations that don't even exist yet is a bit sloppy.
Let's get inside the mind of the author. He has two obvious choices for a target: current and 14.2. Neither of them is "right". Current can't be considered right. It's not even a release. 14.2 is a release, but with the awkward caveat that it's a very long-in-the-tooth release, such that the percentage of notionally typical users who are running current rather than stable is higher than it might otherwise be. There is no right answer to this question. The user should choose. So he picked 15, which at least has the virtue that it will soon be right and once it is right it will be right for some time. In the mean time, the user must choose or the app will not work.
This is not a perfect solution. Often there is no obviously perfect solution, so you pick one and move on.
What he could have done is pick the default mirror based on the contents of /etc/slackware-version. Had he done so, on machines running current, this would have resulted in the same outcome: 15. I said in the previous paragraph that current can't be the right answer, but obviously I was wrong. If the machine is running current then current is the only right answer. But one thing we know is that /etc/slackware-version does not report that the version is current. You can't go by the contents of /etc/slackware-version at the moment. The extra work of reading /etc/slackware-version and producing a compliant mirror file does not get you very far. You would end up with a workable default for 14.2 machines.
I preserved my mirror file, though it probably took just as long to diff it against the new mirror file and then rm the new mirror file as it would have taken to edit the new mirror file.
The message I got was confusing - that's why I mentioned it seemed to be broken, and I don't recall this message last time slackpkg was updated in August.
Code:
You have selected a mirror for Slackware -current in /etc/slackpkg mirrors,
but Slackware version 15.0 appears to be installed.
Yeah, I got that impression too. Seems like he's quite cut up about it.
I'm waiting for the day he finally adds a fully integrated kernel to systemd... then it can be LennartOS vs the rest of the world.
He's gonna have a hard time getting people to make that switch if he keeps violating the fancy new Code Of Conduct. After all that complaining about Linus and his F word too..
He's gonna have a hard time getting people to make that switch if he keeps violating the fancy new Code Of Conduct. After all that complaining about Linus and his F word too..
I think he'd struggle even without the violations. I'd really love to see him try it.
Let's get inside the mind of the author. He has two obvious choices for a target: current and 14.2. Neither of them is "right". Current can't be considered right. It's not even a release. 14.2 is a release, but with the awkward caveat that it's a very long-in-the-tooth release, such that the percentage of notionally typical users who are running current rather than stable is higher than it might otherwise be. There is no right answer to this question.
I disagree. The slackpkg sources file, along with slackware-version and the os-release files should be the last and first ones changed either side of a release event. The only point at which the ones in current should be the same as the ones in a release are the few days surrounding a release where current and release are to all intents and purposes identical.
Thu Oct 28 01:11:07 UTC 2021
a/kernel-generic-5.14.15-x86_64-1.txz: Upgraded.
a/kernel-huge-5.14.15-x86_64-1.txz: Upgraded.
a/kernel-modules-5.14.15-x86_64-1.txz: Upgraded.
d/cmake-3.21.4-x86_64-1.txz: Upgraded.
d/kernel-headers-5.14.15-x86-1.txz: Upgraded.
k/kernel-source-5.14.15-noarch-1.txz: Upgraded.
We're going to go ahead and take both of those changes that were considered
in /testing. GazL almost had me talked out of the autogroup change, but it's
easy to disable if traditional "nice" behavior is important to someone.
-DRM_I810 n
-INLINE_READ_UNLOCK y
-INLINE_READ_UNLOCK_IRQ y
-INLINE_SPIN_UNLOCK_IRQ y
-INLINE_WRITE_UNLOCK y
-INLINE_WRITE_UNLOCK_IRQ y
PREEMPT n -> y
PREEMPT_VOLUNTARY y -> n
SCHED_AUTOGROUP n -> y
+CEC_GPIO n
+DEBUG_PREEMPT y
+PREEMPTION y
+PREEMPT_COUNT y
+PREEMPT_DYNAMIC y
+PREEMPT_RCU y
+PREEMPT_TRACER n
+RCU_BOOST n
+TASKS_RCU y
+UNINLINE_SPIN_UNLOCK y
kde/plasma-desktop-5.23.2.1-x86_64-1.txz: Upgraded.
l/imagemagick-7.1.0_12-x86_64-1.txz: Upgraded.
l/librsvg-2.52.3-x86_64-1.txz: Upgraded.
n/bind-9.16.22-x86_64-1.txz: Upgraded.
This update fixes bugs and the following security issue:
The "lame-ttl" option is now forcibly set to 0. This effectively disables
the lame server cache, as it could previously be abused by an attacker to
significantly degrade resolver performance.
For more information, see:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25219
(* Security fix *)
n/c-ares-1.18.1-x86_64-1.txz: Upgraded.
n/samba-4.15.1-x86_64-1.txz: Upgraded.
isolinux/initrd.img: Rebuilt.
kernels/*: Upgraded.
usb-and-pxe-installers/usbboot.img: Rebuilt.
k/kernel-source-5.14.15-noarch-1.txz: Upgraded.
We're going to go ahead and take both of those changes that were considered in /testing. GazL almost had me talked out of the autogroup change, but it's easy to disable if traditional "nice" behavior is important to someone.
It's a reasonable stance: there's a kernel parameter to disable the autogroup feature but not one to enable it, so going the way you have gives people both options, which is why I only wanted to raise awareness rather than argue against the change.
If anyone is interested in seeing how their workload will be divided into autogroups, in order to get a feel for the options impact, try this:
Code:
for sid in `ps -Ndo pid=`
do
printf "sid: %5d -----------------------------------\n" $sid
ps -s $sid -o cmd=
done
With autogroup enabled, each grouping will get an equal share of cputime.
With autogroup disabled each process gets an equal share, subject to niceness.
Last edited by GazL; 10-28-2021 at 08:03 AM.
Reason: typos
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
