..you can call it 15.0-alpha1

[Jimmy Johnson]

Some words here from our leader:
Current (pre-release) ChangeLog for x86_64
http://www.slackware.com/changelog/current.php?cpu=x86_64
--
Jimmy Johnson

Slackware64 Current - AMD A6-9225 - EXT4 at sda9
Registered Linux User #380263

[Henrik Carlqvist]

Post by Jimmy Johnson
Current (pre-release) ChangeLog for x86_64
http://www.slackware.com/changelog/current.php?cpu=x86_64
--
Jimmy Johnson
Slackware64 Current - AMD A6-9225 - EXT4 at sda9 Registered Linux User
#380263

At the time of this writing the "15.0-alpha1" version has Linux kernel
5.10.16 which is the latest stable version of the Linux kernel. However,
earlier released Slackware versions has instead been shipped with the
latest longterm kernel which at the time of this writing is 5.4.98.

Two things can happen with the 5.10 line of the kernel:

1) It might become the next longterm which means that it will be
supported with new bugfix releases.

2) It might become End Of Life which means that no new bugfix releases
will be made and that anyone running such a version should upgrade to a
newer stable line or a longterm line.

regards Henrik

[Aragorn]

Post by Henrik Carlqvist

Post by Jimmy Johnson
Current (pre-release) ChangeLog for x86_64
http://www.slackware.com/changelog/current.php?cpu=x86_64

At the time of this writing the "15.0-alpha1" version has Linux
kernel 5.10.16 which is the latest stable version of the Linux
kernel. However, earlier released Slackware versions has instead been
shipped with the latest longterm kernel which at the time of this
writing is 5.4.98.
1) It might become the next longterm which means that it will be
supported with new bugfix releases.
2) It might become End Of Life which means that no new bugfix
releases will be made and that anyone running such a version should
upgrade to a newer stable line or a longterm line.

It was announced quite a while ago already that 5.10 will indeed be the
next LTS kernel. However, it will not be marked as such yet for
whatever remaining time 5.11 still hasn't been declared stable.

As I understand it, 5.10 introduces quite a few significant changes,
which coupled to the fact that Nvidia have decided to stop supporting
older cards and ditto drivers, has been (and still is) causing a lot of
issues over at the Manjaro forum, where I am a moderator.

One or two of the problems with Nvidia might be related to a recent
change in the way the kernel allows the proprietary Nvidia driver to
interface with it, and I believe this would be one of the changes that
5.10 has introduced.

Of course, the people most affected by this issue are the n00bs, and it
is not an unsurpassable problem for those familiar with a hands-on
approach, as I expect Slackware users to be.

But so anyway, for now, 5.4 remains the most recent LTS kernel, and if
you have an older Nvidia graphics adapter and you need the proprietary
drivers — nouveau just isn't "there" yet — then sticking with 5.10 is
the path of least hassles. I myself am not an Nvidia user — this
system here has integrated Intel graphics — but I've been running the
5.4 kernel from before it was declared LTS, and it's a goodie. :)

If it ain't broke, don't fix it, and all that jazz...

[Henrik Carlqvist]

Post by Aragorn
It was announced quite a while ago already that 5.10 will indeed be the
next LTS kernel.

Great! Then kernel 5.10 is the obvious choice for the upcoming Slackware
15.0.

regards Henrik

[Mike Small]

Post by Aragorn
But so anyway, for now, 5.4 remains the most recent LTS kernel, and if
you have an older Nvidia graphics adapter and you need the proprietary
drivers — nouveau just isn't "there" yet — then sticking with 5.10 is
the path of least hassles. I myself am not an Nvidia user — this
system here has integrated Intel graphics — but I've been running the
5.4 kernel from before it was declared LTS, and it's a goodie. :)

Are people telling you that the Nouveau driver isn't adequate for
them? It's all I've used on my old Elitebook. Never tried the
proprietary driver figuring something like this would eventually
happen. Granted, I don't put the card through its paces, but I have
the impression that people aren't giving the Nouveau driver enough
credit. The only issues I've had were on NetBSD (yes, recent NetBSD
has Nouveau, god love em), where acceleration seemed not to work, but
on Slackware it seems flawless for my card.

Oh, well, I can say that when I upgraded Debian to Buster I saw sudden
slowness that made watching DVDs impossible, but I can't say if that
was a Nouveau problem or something else. Never properly diagnosed it
since it was impetus for switching back to my Slackware 14.2 partition
and remembering a preference for Slackware over Debian.

I'm feeling a little nervous about the upgrade to 15.0, whether that
DVD playing slowness will happen there too, maybe being caused by
newer kernel behaviour. Also wondering if I will have to remember to
plug in my USB devices in the same slot every time to avoid getting
new device names like I had to on Debian, but maybe eudev didn't take
the unpredictably predictable device naming scheme from its mother
project.

- Mike Sm.

[Rich]

Also wondering if I will have to remember to plug in my USB devices
in the same slot every time to avoid getting new device names like I
had to on Debian, but maybe eudev didn't take the unpredictably
predictable device naming scheme from its mother project.

The 'fix' for that problem has always been to add user custom udev
rules to map the specific USB devices to static device names you pick.
Then the device names for the devices are guaranteed to not change when
the device is moved from port to port. I presume eudev has the same
custom rules capability of the original udev in this case.

[Mike Small]

Post by Rich

Also wondering if I will have to remember to plug in my USB devices
in the same slot every time to avoid getting new device names like I
had to on Debian, but maybe eudev didn't take the unpredictably
predictable device naming scheme from its mother project.

The 'fix' for that problem has always been to add user custom udev
rules to map the specific USB devices to static device names you pick.
Then the device names for the devices are guaranteed to not change when
the device is moved from port to port. I presume eudev has the same
custom rules capability of the original udev in this case.

Think I might mask (or, shocking, delete) 80-net-name-slot.rules or
use the kernel argument net.ifnames=0 instead. No doubt these new
names are handy for some people (Mitt Romney style people,
i.e. corporations?), but for my uses they're more cruft.

Are you using current? Is the new naming scheme there?

- Mike Sm.

[Rich]

Post by Mike Small

Post by Rich

Also wondering if I will have to remember to plug in my USB devices
in the same slot every time to avoid getting new device names like I
had to on Debian, but maybe eudev didn't take the unpredictably
predictable device naming scheme from its mother project.

The 'fix' for that problem has always been to add user custom udev
rules to map the specific USB devices to static device names you pick.
Then the device names for the devices are guaranteed to not change when
the device is moved from port to port. I presume eudev has the same
custom rules capability of the original udev in this case.

Think I might mask (or, shocking, delete) 80-net-name-slot.rules or
use the kernel argument net.ifnames=0 instead. No doubt these new
names are handy for some people (Mitt Romney style people,
i.e. corporations?), but for my uses they're more cruft.
Are you using current? Is the new naming scheme there?

No, not using current. I'm just saying that the way to correct the
fact that pluggable device X receives different device names on
different ports has been to add a udev rule specific to that device to
force assign a static name to the device. I'm presuming, but do not
know, that eudev supports a similar, or the same, ruleset.

[Mike Small]

Post by Rich

Post by Mike Small

Post by Rich

Also wondering if I will have to remember to plug in my USB devices
in the same slot every time to avoid getting new device names like I
had to on Debian, but maybe eudev didn't take the unpredictably
predictable device naming scheme from its mother project.

The 'fix' for that problem has always been to add user custom udev
rules to map the specific USB devices to static device names you pick.
Then the device names for the devices are guaranteed to not change when
the device is moved from port to port. I presume eudev has the same
custom rules capability of the original udev in this case.

Think I might mask (or, shocking, delete) 80-net-name-slot.rules or
use the kernel argument net.ifnames=0 instead. No doubt these new
names are handy for some people (Mitt Romney style people,
i.e. corporations?), but for my uses they're more cruft.
Are you using current? Is the new naming scheme there?

No, not using current. I'm just saying that the way to correct the
fact that pluggable device X receives different device names on
different ports has been to add a udev rule specific to that device to
force assign a static name to the device. I'm presuming, but do not
know, that eudev supports a similar, or the same, ruleset.

Thanks. I hope I didn't sound bratty. Work has a udev issue I'm stuck
on which is making me get frustrated with udev. In my probably not well
informed view of matters udev seems like yet another Linux userland
design that overgrew the problems it was meant to address. It seems to
fit the pattern of the adage... "We had problem X. We made Y. Now we
have two problems."

- Mike Sm.

[Rich]

Post by Rich
No, not using current. I'm just saying that the way to correct the
fact that pluggable device X receives different device names on
different ports has been to add a udev rule specific to that device
to force assign a static name to the device. I'm presuming, but do
not know, that eudev supports a similar, or the same, ruleset.

Thanks. I hope I didn't sound bratty. Work has a udev issue I'm
stuck on which is making me get frustrated with udev. In my probably
not well informed view of matters udev seems like yet another Linux
userland design that overgrew the problems it was meant to address.
It seems to fit the pattern of the adage... "We had problem X. We
made Y. Now we have two problems."

I fully understand your sentiment. And delving into the black hole
that is udev rules is not a fun experience by any measure of "fun".
But at the moment it *is* the way to make sure that pluggable devices
receive static names. So we are stuck with it until someone else
builds an alternative, and the alternative gains enough traction to
start taking over from udev.

The one item is that once you figure out the syntax of the first rule
for the first pluggable device, the rest often simplify into more or
less copy/paste of that rule and editing the appropriate device
identifiers to match what returns from the subsequent device. However,
the hill one has to climb to get that first rule working is both very
steep and much taller than it probably should have been (largely due to
less than stellar overall documentation).

[Aragorn]

Post by Mike Small

Post by Aragorn
But so anyway, for now, 5.4 remains the most recent LTS kernel, and
if you have an older Nvidia graphics adapter and you need the
proprietary drivers — nouveau just isn't "there" yet — then sticking
with 5.10 is the path of least hassles.

^^^^
That should have read "5.4".

Post by Mike Small

Post by Aragorn
I myself am not an Nvidia user — this system here has integrated
Intel graphics — but I've been running the 5.4 kernel from before it
was declared LTS, and it's a goodie. :)

Are people telling you that the Nouveau driver isn't adequate for
them?

Many are, yes, but then again, this is over at the Manjaro forum.
Manjaro seems to attract a lot of hardcore gamers — we supply our own
version of Steam, and it's installed by default.

CUDA is another reason why people want the proprietary driver. nouveau
doesn't support CUDA.

Post by Mike Small
It's all I've used on my old Elitebook. Never tried the proprietary
driver figuring something like this would eventually happen. Granted,
I don't put the card through its paces, but I have the impression
that people aren't giving the Nouveau driver enough credit. The only
issues I've had were on NetBSD (yes, recent NetBSD has Nouveau, god
love em), where acceleration seemed not to work, but on Slackware it
seems flawless for my card.

Well, the project itself is commendable and deserves credit. After
all, the nouveau developers had to start from scratch, without any
support whatsoever from ever-invidious Nvidia.

Post by Mike Small
Oh, well, I can say that when I upgraded Debian to Buster I saw sudden
slowness that made watching DVDs impossible, but I can't say if that
was a Nouveau problem or something else. Never properly diagnosed it
since it was impetus for switching back to my Slackware 14.2 partition
and remembering a preference for Slackware over Debian.

I don't think I've ever used nouveau myself. On the machines I had
which featured an Nvidia graphics adapter, I've always used the
proprietary driver, but my previous machine — which was a refurbished
box — had an onboard Radeon, which uses a GPL'd in-kernel driver, and
both this machine here and my laptop have integrated Intel graphics,
which of course also uses a GPL'd driver.

Post by Mike Small
I'm feeling a little nervous about the upgrade to 15.0, whether that
DVD playing slowness will happen there too, maybe being caused by
newer kernel behaviour. Also wondering if I will have to remember to
plug in my USB devices in the same slot every time to avoid getting
new device names like I had to on Debian, but maybe eudev didn't take
the unpredictably predictable device naming scheme from its mother
project.

Last time I looked into eudev — in my Gentoo days — it did indeed
feature the persistent naming scheme that upstream udev has, but in both
upstream udev and eudev, the behavior can be overridden, either by way
of a kernel boot parameter or by way of a udev rule; I'm not certain
which, but I do know that it can be done.

[Jimmy Johnson]

Post by Mike Small
Are people telling you that the Nouveau driver isn't adequate for
them? It's all I've used on my old Elitebook. Never tried the
proprietary driver figuring something like this would eventually
happen. Granted, I don't put the card through its paces, but I have
the impression that people aren't giving the Nouveau driver enough
credit. The only issues I've had were on NetBSD (yes, recent NetBSD
has Nouveau, god love em), where acceleration seemed not to work, but
on Slackware it seems flawless for my card.
Oh, well, I can say that when I upgraded Debian to Buster I saw sudden
slowness that made watching DVDs impossible, but I can't say if that
was a Nouveau problem or something else. Never properly diagnosed it
since it was impetus for switching back to my Slackware 14.2 partition
and remembering a preference for Slackware over Debian.
I'm feeling a little nervous about the upgrade to 15.0, whether that
DVD playing slowness will happen there too, maybe being caused by
newer kernel behaviour. Also wondering if I will have to remember to
plug in my USB devices in the same slot every time to avoid getting
new device names like I had to on Debian, but maybe eudev didn't take
the unpredictably predictable device naming scheme from its mother
project.

I've been using the free nouveau driver for many years without problem,
but now with the linux kernel version 5.x there is no audio while using
nvidia, gf119 HDMI audio controller, installing the nvidia legacy driver
the hdmi audio does work, but cause plasma to crash. I get the same
results with other systems using the version 5.x kernel and nvidia. But
with other systems it's easy to install a up to date version 4.x kernel,
but not so easy with slackware. With each update/upgrade to current I
hope the audio will start working, but not yet. So far testing slackware
current alpha-15 has been nice and quiet around here. Give me that
old-time rock-n-roll!

Wishing I had a amd/ati card to put in this box and just get rid of the
nvidia.

[Rinaldi]

Post by Jimmy Johnson

Post by Mike Small
Are people telling you that the Nouveau driver isn't adequate for
them?  It's all I've used on my old Elitebook. Never tried the
proprietary driver figuring something like this would eventually
happen. Granted, I don't put the card through its paces, but I have
the impression that people aren't giving the Nouveau driver enough
credit. The only issues I've had were on NetBSD (yes, recent NetBSD
has Nouveau, god love em), where acceleration seemed not to work, but
on Slackware it seems flawless for my card.
Oh, well, I can say that when I upgraded Debian to Buster I saw sudden
slowness that made watching DVDs impossible, but I can't say if that
was a Nouveau problem or something else. Never properly diagnosed it
since it was impetus for switching back to my Slackware 14.2 partition
and remembering a preference for Slackware over Debian.
I'm feeling a little nervous about the upgrade to 15.0, whether that
DVD playing slowness will happen there too, maybe being caused by
newer kernel behaviour. Also wondering if I will have to remember to
plug in my USB devices in the same slot every time to avoid getting
new device names like I had to on Debian, but maybe eudev didn't take
the unpredictably predictable device naming scheme from its mother
project.

I've been using the free nouveau driver for many years without problem,
but now with the linux kernel version 5.x there is no audio while using
nvidia, gf119 HDMI audio controller, installing the nvidia legacy driver
the hdmi audio does work, but cause plasma to crash. I get the same
results with other systems using the version 5.x kernel and nvidia. But
with other systems it's easy to install a up to date version 4.x kernel,
but not so easy with slackware. With each update/upgrade to current I
hope the audio will start working, but not yet. So far testing slackware
current alpha-15 has been nice and quiet around here. Give me that
old-time rock-n-roll!
Wishing I had a amd/ati card to put in this box and just get rid of the
nvidia.

I found several reports of Nvidia (binary or nouveau), HDMI, dpms, and
kernel 5.10.* behaving badly with plasma (and xfce4 here).

Basically with +dpms when the HDMI monitor was put to sleep it never
woke up. Required at least killing X and restarting or a full reboot.
Switching xwmconfig back and forth from kde to xfce worked sometimes.

The only "cure" I have found is to xset -dpms and crank up the
Xscreensaver. This is not a power management solution but it does
provide a blank screen (settings) that will resume when input is
provided (kbd/mouse).

There appears to be a lot of growing pains with Nvidia and Linux.

Rinaldi

[Jimmy Johnson]

crank up the Xscreensaver. This is not a power management solution but
it does provide a blank screen (settings) that will resume when input is
provided (kbd/mouse).

Will it override power management settings? If it does that could be a
good thing to try. Normally I use 60min to screen turn off, no dimming,
no sleep, no hibernate.

[Rinaldi]

Post by Jimmy Johnson

crank up the Xscreensaver.  This is not a power management solution but
it does provide a blank screen (settings) that will resume when input is
provided (kbd/mouse).

Will it override power management settings? If it does that could be a
good thing to try. Normally I use 60min to screen turn off, no dimming,
no sleep, no hibernate.

The xset -dpms turns off power management. Or you cqan do it through
System Settings.

You can run xscreensaver-demo for a full setup.

Rinaldi