The future of OpenSUSE Leap (rant)
Hi, I'm the manager of a small IT firm with a focus on Linux and Open Source software. On my servers I'm running a mix of various RHEL clones like CentOS, Oracle Linux and Rocky Linux. On the desktop side, I've been using OpenSUSE Leap with KDE since version 15.0. Leap is powering all the desktop clients in our local school, and everybody (school staff, teachers, students) is very happy with it. I just finished polishing up my bone-headed post-install configuration script for Leap 15.4: https://gitlab.com/kikinovak/opensuse-lp154/-/blob/main/setup.sh And I just learned that SUSE will phase out Leap after the 15.5 release. So here's a few thoughts I want to share with the distribution maintainers. 1. Perennity anyone ? Duh ? 2. After the CentOS debacle in 2020, it looks like distribution maintainers love pissing off their userbase by pulling the rug from under their feet. Hint: we hate it. 3. Some official SUSE guy on Twitter who shall remain unnamed likes to explain on a regular basis that rolling releases are the future and folks who rely on releases are utterly clueless. As someone who tried to maintain a dozen production client desktops based on Arch Linux as far back as 2006 and failed miserably after a udev update broke everything, here's a thought from my professional experience. My Number One Fight Club rule: YOU DO NOT USE ROLLING RELEASES IN A PRODUCTION ENVIRONMENT. Yes, I shouted that out loud. 4. Yes, I have Tumbleweed running on a spare sandbox PC. Yes, it works nicely. No, I will never (ever) use it in production. 5. Stop reinventing the wheel please. You young punks remind me of myself when I was three years old and tried to "repair" my parent's perfectly functional alarm clock. Cheers from the blazing hot South of France, Niki Kovacs (https://tinyurl.com/2p8tk495) -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12
* Nicolas Kovacs <info@microlinux.fr> [06-19-22 08:15]:
Hi,
I'm the manager of a small IT firm with a focus on Linux and Open Source software. On my servers I'm running a mix of various RHEL clones like CentOS, Oracle Linux and Rocky Linux. On the desktop side, I've been using OpenSUSE Leap with KDE since version 15.0.
Leap is powering all the desktop clients in our local school, and everybody (school staff, teachers, students) is very happy with it.
I just finished polishing up my bone-headed post-install configuration script for Leap 15.4:
https://gitlab.com/kikinovak/opensuse-lp154/-/blob/main/setup.sh
And I just learned that SUSE will phase out Leap after the 15.5 release.
So here's a few thoughts I want to share with the distribution maintainers.
1. Perennity anyone ? Duh ?
2. After the CentOS debacle in 2020, it looks like distribution maintainers love pissing off their userbase by pulling the rug from under their feet. Hint: we hate it.
3. Some official SUSE guy on Twitter who shall remain unnamed likes to explain on a regular basis that rolling releases are the future and folks who rely on releases are utterly clueless. As someone who tried to maintain a dozen production client desktops based on Arch Linux as far back as 2006 and failed miserably after a udev update broke everything, here's a thought from my professional experience. My Number One Fight Club rule: YOU DO NOT USE ROLLING RELEASES IN A PRODUCTION ENVIRONMENT. Yes, I shouted that out loud.
4. Yes, I have Tumbleweed running on a spare sandbox PC. Yes, it works nicely. No, I will never (ever) use it in production.
5. Stop reinventing the wheel please. You young punks remind me of myself when I was three years old and tried to "repair" my parent's perfectly functional alarm clock.
Cheers from the blazing hot South of France,
Niki Kovacs (https://tinyurl.com/2p8tk495)
I happen to be a tumbleweed user. Yes, I run tumbleweed in a production environment and have since it's introduction as green something or other and yes, I have occasional problems, but no more than Leap users and Tumbleweed has remained a rolling release since it's inception. Dependable and solid. You young punks do like to rant online. keep warm. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
Am 19.06.22 um 14:09 schrieb Nicolas Kovacs:
Hi,
I'm the manager of a small IT firm with a focus on Linux and Open Source software. On my servers I'm running a mix of various RHEL clones like CentOS, Oracle Linux and Rocky Linux. On the desktop side, I've been using OpenSUSE Leap with KDE since version 15.0.
Leap is powering all the desktop clients in our local school, and everybody (school staff, teachers, students) is very happy with it.
I just finished polishing up my bone-headed post-install configuration script for Leap 15.4:
https://gitlab.com/kikinovak/opensuse-lp154/-/blob/main/setup.sh
And I just learned that SUSE will phase out Leap after the 15.5 release.
Yes, following SUSE Linux Enterprise, and what is wrong with that? https://en.opensuse.org/openSUSE:Roadmap "openSUSE Leap is always based on the newest SUSE Linux Enterprise Server available to the date, which means Leap would have a major version update is a successor to SUSE Linux Enterprise 15 becomes available." Peter
Hi, all -- ...and then Peter McD said... % % Yes, following SUSE Linux Enterprise, and what is wrong with that? % % https://en.opensuse.org/openSUSE:Roadmap [snip] BTW, I can't edit it, but this typo ... Leap would have a major version update is a successor ... s/is a/if a/ probably should be fixed. Maybe that would have solved the whole question ;-) HTH & HANW :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt
Hi again, all -- ...and then davidtg-robot@justpickone.org said... % % BTW, I can't edit it, but this typo % % ... Leap would have a major version update is a successor ... % % s/is a/if a/ % % probably should be fixed. Maybe that would have solved the whole % question ;-) The problem with going reading is that I keep finding things ... :-) https://en.opensuse.org/Lifetime ... Leap 15 successor is not know yet ... s/know/known/ HTH & HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt
David T-G wrote:
Hi again, all --
...and then davidtg-robot@justpickone.org said... % % BTW, I can't edit it, but this typo % % ... Leap would have a major version update is a successor ... % % s/is a/if a/ % % probably should be fixed. Maybe that would have solved the whole % question ;-)
The problem with going reading is that I keep finding things ... :-)
https://en.opensuse.org/Lifetime
... Leap 15 successor is not know yet ...
s/know/known/
Both edits done. -- Per Jessen, Zürich (36.1°C)
Le 19/06/2022 à 17:05, David T-G a écrit :
BTW, I can't edit it, but this typo
... Leap would have a major version update is a successor ...
s/is a/if a/
probably should be fixed. Maybe that would have solved the whole question ;-)
Ah ! Yes ! That answers the question. Thanks very much. I'll go rub this piece of information under the Distrowatch chief editor's nose. :o) -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12
Le 19/06/2022 à 14:47, Peter McD a écrit :
Yes, following SUSE Linux Enterprise, and what is wrong with that?
https://en.opensuse.org/openSUSE:Roadmap
"openSUSE Leap is always based on the newest SUSE Linux Enterprise Server available to the date, which means Leap would have a major version update is a successor to SUSE Linux Enterprise 15 becomes available."
Allow me to clarify this. What I meant is: what happens with OpenSUSE Leap after 15.5 is EOL ? Will there be a subsequent release based on the next SUSE Linux Enterprise ? Or will there be some major paradigm change involving a MicroOS base and (Linus forbid) Flatpaks, as some folks suggested ? On the one hand, the demise of OpenSUSE Leap on the horizon seems to have been started by Distrowatch and Reddit. But then, no one at SUSE seems to want to confirm anything about the future of Leap beyond the 15.5 release. Hence my bewilderment. -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12
On Mon, 20 Jun 2022 17:26:31 +0200 Nicolas Kovacs <info@microlinux.fr> wrote:
Or will there be some major paradigm change involving a MicroOS base and (Linus forbid) Flatpaks, as some folks suggested ?
I have no issues with flatpacks that work, and I vaguely remember applications that (during installation or compilation, I forget which) offered the user their 'bundled depends' if the required ones could not be found system-side. Did I dream that or was it already a form of flatpacking? As for the future of Leap ('twas a good rant after all) I only ask to be forwarned early enough, OS'es being just plug-ins for my favorite apps. -- https://i.imgur.com/b6voLxD.png
Le 21/06/2022 à 00:01, bent fender a écrit :
I have no issues with flatpacks that work, and I vaguely remember applications that (during installation or compilation, I forget which) offered the user their 'bundled depends' if the required ones could not be found system-side. Did I dream that or was it already a form of flatpacking? As for the future of Leap ('twas a good rant after all) I only ask to be forwarned early enough, OS'es being just plug-ins for my favorite apps.
While I may use Flatpaks for the odd required proprietary beast where the packagers have done a shitty job (Microsoft Teams for example), I try to avoid it whenever possible. - Some stuff depends on obsolete and/or unmaintained libraries. - One of the numerous advantages of our favorite Unix clone is that shared libraries are effectively *shared*. This advantage goes out of the window with Flatpak and turns our Linux system into something that "works" like Microsoft Windows under the hood, where each application comes with its own bundled and redundant dependencies. Of course there's always Debian, Slackware and FreeBSD to preserve some sanity in the FOSS galaxy. So far OpenSUSE Leap has been a nice combination of sanity and ease of use. -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12
Le 19/06/2022 à 14:52, Andrei Borzenkov a écrit :
Care to post a link to this information?
Here you go : https://distrowatch.com/weekly.php?issue=20220613#news -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12
Nicolas Kovacs wrote:
I'm the manager of a small IT firm with a focus on Linux and Open Source software. On my servers I'm running a mix of various RHEL clones like CentOS, Oracle Linux and Rocky Linux. On the desktop side, I've been using OpenSUSE Leap with KDE since version 15.0.
You can look up my credentials/profile here, _if_ you can be bothered: https://en.opensuse.org/User:pjessen
And I just learned that SUSE will phase out Leap after the 15.5 release.
Where did you learn that from?
So here's a few thoughts I want to share with the distribution maintainers.
I suspect most of the maintainers are best reached on the factory list.
Number One Fight Club rule: YOU DO NOT USE ROLLING RELEASES IN A PRODUCTION ENVIRONMENT. Yes, I shouted that out loud.
+1. SUSE's customers would also agree with you.
4. Yes, I have Tumbleweed running on a spare sandbox PC. Yes, it works nicely. No, I will never (ever) use it in production.
Ditto, all of those. I have occasionally played with the idea of putting TW on my main office desktop, but I need that to be in working order for 10-12 hours a day.
5. Stop reinventing the wheel please. You young punks remind me of myself when I was three years old and tried to "repair" my parent's perfectly functional alarm clock.
There are lots of reasons why that won't work. To attract "young talent" any organisation or business has to keep re-inventing something.
Cheers from the blazing hot South of France,
Switzerland at only 34C at the moment, but it'll get really hot in a couple of hours. -- Per Jessen, Zürich (34.4°C)
On 19/06/2022 15:42, Per Jessen wrote:
Nicolas Kovacs wrote:
And I just learned that SUSE will phase out Leap after the 15.5 release.
Where did you learn that from?
It was "discussed" on last week's Distrowatch Weekly: https://distrowatch.com/weekly.php?issue=20220613#news with subsequent befuddlement in the comments below. Amongst the contributors to these comments, 'SpiralLinux', also creator and maintainer of GeckoLinux, confirms the DistroWatch interpretation. The DW writer claims nobody from SUSE will comment. It's led to a lot of subsequent discussion and uncertainty across the Internet.
Cheers from the blazing hot South of France,
Switzerland at only 34C at the moment, but it'll get really hot in a couple of hours.
Cheers from the fireball heart of France at only 38° and less breeze :) gumb
On 2022-06-19 07:42, Per Jessen wrote:
Nicolas Kovacs wrote:
5. Stop reinventing the wheel please. You young punks remind me of myself when I was three years old and tried to "repair" my parent's perfectly functional alarm clock.
There are lots of reasons why that won't work. To attract "young talent" any organisation or business has to keep re-inventing something.
Whatever happened to "If it ain't broke, don't fix it"? New features, yes, of course, but if the stuff runs well and runs reasonably fast, do not rewrite the code simply because the new code is "more elegant". There must always be a damn good reason to re-code something that works, and "it looks better" is not a good reason.
Cheers from the blazing hot South of France,
Switzerland at only 34C at the moment, but it'll get really hot in a couple of hours.
Greetings from western Canada, where summer has not yet arrived :( No, I will not be coming to visit you at Christmas -- Switzerland gets way too much snow :D
Darryl Gregorash wrote:
On 2022-06-19 07:42, Per Jessen wrote:
Nicolas Kovacs wrote:
5. Stop reinventing the wheel please. You young punks remind me of myself when I was three years old and tried to "repair" my parent's perfectly functional alarm clock.
There are lots of reasons why that won't work. To attract "young talent" any organisation or business has to keep re-inventing something.
Whatever happened to "If it ain't broke, don't fix it"?
It died in a car crash long ago. Or something like that.
New features, yes, of course, but if the stuff runs well and runs reasonably fast, do not rewrite the code simply because the new code is "more elegant". There must always be a damn good reason to re-code something that works, and "it looks better" is not a good reason.
I completely agree with you, you are preaching to the choir. However, I also realise that it is not how it works. The younger generation with an itch to scratch have to be allowed to do just that. Otherwise they go elsewhere. We might also all succumb to a complete lack of innovation, being left as octogenarians reminiscing over Leap 18 and how swell HTTP was. The challenge for openSUSE is to let people fix what ain't broke - without breaking it.
Cheers from the blazing hot South of France,
Switzerland at only 34C at the moment, but it'll get really hot in a couple of hours.
Greetings from western Canada, where summer has not yet arrived :( No, I will not be coming to visit you at Christmas -- Switzerland gets way too much snow :D
That's good, coming from a Canuck :-) You would be surprised - if only we did. The photo on my user page is more than 10 years old. -- Per Jessen, Zürich (29.9°C)
Darryl Gregorash wrote:
On 2022-06-19 14:10, Per Jessen wrote:
Darryl Gregorash wrote:
The challenge for openSUSE is to let people fix what ain't broke - without breaking it.
Uh huh, sure.. what could possibly go wrong? I'm sure someone wrote up a law that applies to all this.
Like I said, that is the challenge, especially in our do-o-cracy. I have myself recently resigned from a "post" because our infrastructure software was unnecessarily rewritten. I would much prefer the old adage, but there are other things at stake here. -- Per Jessen, Zürich (28.2°C)
On 2022-06-19 15:13, Per Jessen wrote:
Like I said, that is the challenge, especially in our do-o-cracy. I have myself recently resigned from a "post" because our infrastructure software was unnecessarily rewritten.
Speaking of which, does anyone know the situation @SUBJ? Last I checked, it still wasn't working up to expectations (which is a polite way of putting it :D )
Darryl Gregorash wrote:
On 2022-06-19 15:13, Per Jessen wrote:
Like I said, that is the challenge, especially in our do-o-cracy. I have myself recently resigned from a "post" because our infrastructure software was unnecessarily rewritten.
Speaking of which, does anyone know the situation @SUBJ? Last I checked, it still wasn't working up to expectations (which is a polite way of putting it :D )
Yeah. Sigh. I'll be happy to discuss it in private, my opinion is probably too controversial to be aired here. -- Per Jessen, Zürich (28.9°C)
On 2022-06-21 11:28, Per Jessen wrote:
Darryl Gregorash wrote:
On 2022-06-19 15:13, Per Jessen wrote:
Like I said, that is the challenge, especially in our do-o-cracy. I have myself recently resigned from a "post" because our infrastructure software was unnecessarily rewritten.
Speaking of which, does anyone know the situation @SUBJ? Last I checked, it still wasn't working up to expectations (which is a polite way of putting it :D )
Yeah. Sigh. I'll be happy to discuss it in private, my opinion is probably too controversial to be aired here.
Would a decent translation of that be that you are walking back your comment about letting the children play? lol
Darryl Gregorash wrote:
On 2022-06-21 11:28, Per Jessen wrote:
Darryl Gregorash wrote:
On 2022-06-19 15:13, Per Jessen wrote:
Like I said, that is the challenge, especially in our do-o-cracy. I have myself recently resigned from a "post" because our infrastructure software was unnecessarily rewritten.
Speaking of which, does anyone know the situation @SUBJ? Last I checked, it still wasn't working up to expectations (which is a polite way of putting it :D )
Yeah. Sigh. I'll be happy to discuss it in private, my opinion is probably too controversial to be aired here.
Would a decent translation of that be that you are walking back your comment about letting the children play? lol
Haha, yes and no - nice one though. I think everyone, whatever itch they are scratching, needs to be aware of their environment. If not, they need to be made aware. That conflicts with our do-o-cracy idea though. It's not easy. -- Per Jessen, Zürich (26.5°C)
Am 19.06.22 um 22:10 schrieb Per Jessen:
The challenge for openSUSE is to let people fix what ain't broke - without breaking it.
So how can I as a simple user fix the compile errors that nVidia drivers have with the new kernel 5.18.1? Would it have been very hard for Suse to check and give me some information like: "We Tumbleweed guys tested current nVidia drivers with this new kernel. It does not work. It throws compile errors. So for the time being and for your benefit we will not install 5.18.1 on your machine and keep the older kernel. Please read here: <some further Suse information about this problem>" ? Wondering Pete
* Peter Maffter <petermaffter@yahoo.de> [06-19-22 18:37]:
Am 19.06.22 um 22:10 schrieb Per Jessen:
The challenge for openSUSE is to let people fix what ain't broke - without breaking it.
So how can I as a simple user fix the compile errors that nVidia drivers have with the new kernel 5.18.1?
Would it have been very hard for Suse to check and give me some information like: "We Tumbleweed guys tested current nVidia drivers with this new kernel. It does not work. It throws compile errors. So for the time being and for your benefit we will not install 5.18.1 on your machine and keep the older kernel. Please read here: <some further Suse information about this problem>" ?
I was running nvidia on 5.18.1 and now 5.18.4 with GTX 3060 TI. but not the ".run" file. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
Am 20.06.22 um 00:34 schrieb Peter Maffter:
Am 19.06.22 um 22:10 schrieb Per Jessen:
The challenge for openSUSE is to let people fix what ain't broke - without breaking it.
So how can I as a simple user fix the compile errors that nVidia drivers have with the new kernel 5.18.1?
Would it have been very hard for Suse to check and give me some information like: "We Tumbleweed guys tested current nVidia drivers with this new kernel. It does not work. It throws compile errors. So for the time being and for your benefit we will not install 5.18.1 on your machine and keep the older kernel. Please read here: <some further Suse information about this problem>" ?
I run into this once or twice per year which is not that bad and extremely infuriating when it happens. From my point of view, the main problem is that most updates run without a hitch. So when it happens, I usually want to do something. And I can't because the computer behaves oddly. Since this is rare, I don't do a full backup before every update. Now I have an unknown problem and must spend time to find out what it is instead of doing what I planned to do. The next problem is that my PC knows what's wrong (it has written an error somewhere) but I have to find this error, first. It's also not always clear which of the many errors that I find are the reason for the current problem. So there is a lot of knowledge involved which the opensuse devs have - so many issues are obvious for them - but not for me. Anyway. I think there are two solutions for this "package X often breaks when Y is also installed" problem: a) Set up an automated build system tries to compiles all the involved packages when one of them changes. For NVIDIA, you'd need a server somewhere with an NVIDIA card installed. NVIDIA should be able and willing to set this up - this would help their business. If this build fails, it's not allowed to push the new package(s) to any repo. The obvious drawback here is that it could block security fixes in the kernel which would work for all those people without an nvidia driver. b) Add a mechanism to zypper or rpm for brittle&important package combinations where someone says "I tested this combination and it works" or maybe even "we know this combination won't work; don't try". If the computer which is running "zypper up" has a different combination, it should stop and warn the person trying to update. If the combinations is known broken, zypper should refuse to continue. Maybe people running opensuse could get a tool to report "works for me" and "fails for me" to get more combinations into the system that are good or dangerous. Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://blog.pdark.de/
* Aaron Digulla <digulla@hepe.com> [07-26-22 15:22]:
Am 20.06.22 um 00:34 schrieb Peter Maffter:
Am 19.06.22 um 22:10 schrieb Per Jessen:
The challenge for openSUSE is to let people fix what ain't broke - without breaking it.
So how can I as a simple user fix the compile errors that nVidia drivers have with the new kernel 5.18.1?
Would it have been very hard for Suse to check and give me some information like: "We Tumbleweed guys tested current nVidia drivers with this new kernel. It does not work. It throws compile errors. So for the time being and for your benefit we will not install 5.18.1 on your machine and keep the older kernel. Please read here: <some further Suse information about this problem>" ?
I run into this once or twice per year which is not that bad and extremely infuriating when it happens.
From my point of view, the main problem is that most updates run without a hitch. So when it happens, I usually want to do something. And I can't because the computer behaves oddly. Since this is rare, I don't do a full backup before every update.
Now I have an unknown problem and must spend time to find out what it is instead of doing what I planned to do.
The next problem is that my PC knows what's wrong (it has written an error somewhere) but I have to find this error, first. It's also not always clear which of the many errors that I find are the reason for the current problem. So there is a lot of knowledge involved which the opensuse devs have - so many issues are obvious for them - but not for me.
Anyway.
I think there are two solutions for this "package X often breaks when Y is also installed" problem:
a) Set up an automated build system tries to compiles all the involved packages when one of them changes.
For NVIDIA, you'd need a server somewhere with an NVIDIA card installed. NVIDIA should be able and willing to set this up - this would help their business.
If this build fails, it's not allowed to push the new package(s) to any repo.
The obvious drawback here is that it could block security fixes in the kernel which would work for all those people without an nvidia driver.
b) Add a mechanism to zypper or rpm for brittle&important package combinations where someone says "I tested this combination and it works" or maybe even "we know this combination won't work; don't try".
If the computer which is running "zypper up" has a different combination, it should stop and warn the person trying to update. If the combinations is known broken, zypper should refuse to continue.
Maybe people running opensuse could get a tool to report "works for me" and "fails for me" to get more combinations into the system that are good or dangerous.
fwiw: I have utilized nvidia for many years and it is not uncommon for any particular nvidia card to fail for a particular kernel/driver or for the driver to be issued somewhat late. that said, it is infrequent and is simple to boot the previous kernel and not be concerned with anything else. soon another driver and/or kernel will be issued and solve the problem. the important thing is to accurately report the conditions and equipment so the maintainers may determine the correction needed. emphasis on "accurately report the conditions and equipment" it is virtually impossible to test against all possible conditions! -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
Am 26.07.22 um 22:31 schrieb Patrick Shanahan:
fwiw: I have utilized nvidia for many years and it is not uncommon for any particular nvidia card to fail for a particular kernel/driver or for the driver to be issued somewhat late. that said, it is infrequent and is simple to boot the previous kernel and not be concerned with anything else. soon another driver and/or kernel will be issued and solve the problem.
In my case, that approach didn't work. This is frustrating since I know a bit about software: https://stackoverflow.com/users/34088/aaron-digulla Also, I feel like there are a dozen different solutions for this problem. All of them work but not always. I, for example, have never tried to boot an old kernel because someone said you should never do this because the user space tools on disk might break when the kernel suddenly changes which could lead to all kinds of strange problems.
the important thing is to accurately report the conditions and equipment so the maintainers may determine the correction needed.
emphasis on "accurately report the conditions and equipment"
it is virtually impossible to test against all possible conditions!
I don't agree at all. I think we are in this mess because: 1. The kernel doesn't have a stable binary driver API like, say, the AmigaOS already had in 1984. 2. The kernel comes with a ton of config options. This makes is very versatile but also brittle because you if you're not very careful, you have a combinatory explosion of test cases. 3. Software should have a unit test code coverage between 40-60%. What's the coverage for kernel 5.14? And don't tell me you can't test hardware drivers. I did it in AROS and in commercial software as well. Yes, testing the peeking and poking in hardware registers is expensive to test but still not impossible. A coverage of 40% is still easy to achieve because drivers contain a lot of other code (config processing, error handling, management, ...). 4. There is no centralized automated CI system where everyone working on the kernel or a driver can push patches and drivers to see if they even compile. 5. Every Linux company spends countless hours on maintaining their own kernel patches. So even if your code works with the vanilla kernel, there is a good chance that it won't work with anything else. 6. Many developers don't care to write useful error messages: Ones that contain all the information necessary to fix the issue. All of these things are this way because someone wants them to be that way. Linus opposes the idea of a stable external and driver API in the kernel (while ranting that the stupid desktop guys change their API all the time...). There are good reasons for his stance but one of the drawbacks is that drivers break every now and then. And then, even someone with 300'000+ points on stackoverflow has a hard time to fix it. And I have to waste your time asking questions. For these reasons: A mess like this doesn't happen by pure chance. It takes meticulous planning and careful execution by many smart people over many years. ;-) Anyway ... thanks for your time. Good night, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://blog.pdark.de/
On 28.07.2022 01:51, Aaron Digulla wrote:
Also, I feel like there are a dozen different solutions for this problem. All of them work but not always. I, for example, have never tried to boot an old kernel because someone said you should never do this because the user space tools on disk might break when the kernel suddenly changes which could lead to all kinds of strange problems.
So you claim that kernel update magically changes installed programs to become incompatible with any previous kernel version making it impossible to boot any previous kernel version.
On 26/07/2022 21.20, Aaron Digulla wrote:
Am 20.06.22 um 00:34 schrieb Peter Maffter:
Am 19.06.22 um 22:10 schrieb Per Jessen:
The challenge for openSUSE is to let people fix what ain't broke - without breaking it.
So how can I as a simple user fix the compile errors that nVidia drivers have with the new kernel 5.18.1?
Would it have been very hard for Suse to check and give me some information like: "We Tumbleweed guys tested current nVidia drivers with this new kernel. It does not work. It throws compile errors. So for the time being and for your benefit we will not install 5.18.1 on your machine and keep the older kernel. Please read here: <some further Suse information about this problem>" ?
I run into this once or twice per year which is not that bad and extremely infuriating when it happens.
From my point of view, the main problem is that most updates run without a hitch. So when it happens, I usually want to do something. And I can't because the computer behaves oddly. Since this is rare, I don't do a full backup before every update.
Now I have an unknown problem and must spend time to find out what it is instead of doing what I planned to do.
There is a warning somewhere that if you use Tumbleweed and have an Nvidia card with the proprietary driver, things like this will happen now and then. Thus, if this is a problem for you, either don't use Nvidia or don't use Tumbleweed. Now don't start asking me for a cite, because I don't remember where I read this, years ago, maybe more than a decade ago :-P -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.3 (Legolas))
* Carlos E. R. <robin.listas@telefonica.net> [07-26-22 18:29]:
On 26/07/2022 21.20, Aaron Digulla wrote:
Am 20.06.22 um 00:34 schrieb Peter Maffter:
Am 19.06.22 um 22:10 schrieb Per Jessen:
The challenge for openSUSE is to let people fix what ain't broke - without breaking it.
So how can I as a simple user fix the compile errors that nVidia drivers have with the new kernel 5.18.1?
Would it have been very hard for Suse to check and give me some information like: "We Tumbleweed guys tested current nVidia drivers with this new kernel. It does not work. It throws compile errors. So for the time being and for your benefit we will not install 5.18.1 on your machine and keep the older kernel. Please read here: <some further Suse information about this problem>" ?
I run into this once or twice per year which is not that bad and extremely infuriating when it happens.
From my point of view, the main problem is that most updates run without a hitch. So when it happens, I usually want to do something. And I can't because the computer behaves oddly. Since this is rare, I don't do a full backup before every update.
Now I have an unknown problem and must spend time to find out what it is instead of doing what I planned to do.
There is a warning somewhere that if you use Tumbleweed and have an Nvidia card with the proprietary driver, things like this will happen now and then. Thus, if this is a problem for you, either don't use Nvidia or don't use Tumbleweed.
no, boot an earlier kernel and wait for correction.
Now don't start asking me for a cite, because I don't remember where I read this, years ago, maybe more than a decade ago :-P
then refrain from spreading FUD! -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
On 27/07/2022 03.21, Patrick Shanahan wrote:
* Carlos E. R. <robin.listas@telefonica.net> [07-26-22 18:29]:
On 26/07/2022 21.20, Aaron Digulla wrote:
Am 20.06.22 um 00:34 schrieb Peter Maffter:
Am 19.06.22 um 22:10 schrieb Per Jessen:
The challenge for openSUSE is to let people fix what ain't broke - without breaking it.
So how can I as a simple user fix the compile errors that nVidia drivers have with the new kernel 5.18.1?
Would it have been very hard for Suse to check and give me some information like: "We Tumbleweed guys tested current nVidia drivers with this new kernel. It does not work. It throws compile errors. So for the time being and for your benefit we will not install 5.18.1 on your machine and keep the older kernel. Please read here: <some further Suse information about this problem>" ?
I run into this once or twice per year which is not that bad and extremely infuriating when it happens.
From my point of view, the main problem is that most updates run without a hitch. So when it happens, I usually want to do something. And I can't because the computer behaves oddly. Since this is rare, I don't do a full backup before every update.
Now I have an unknown problem and must spend time to find out what it is instead of doing what I planned to do.
There is a warning somewhere that if you use Tumbleweed and have an Nvidia card with the proprietary driver, things like this will happen now and then. Thus, if this is a problem for you, either don't use Nvidia or don't use Tumbleweed.
no, boot an earlier kernel and wait for correction.
Now don't start asking me for a cite, because I don't remember where I read this, years ago, maybe more than a decade ago :-P
then refrain from spreading FUD!
Patrick, please stop insulting me. Or maybe you lost your memory, or are too biased to remember. Official info: <https://en.opensuse.org/Portal:Tumbleweed> «Third Party Drivers Due to the fast pace of kernel upgrades on Tumbleweed, 3rd party kernel driver modules may not be fast enough to catch up with the latest kernel version. In the unlikely case that your kernel driver module does not work on Tumbleweed, please consider using openSUSE Leap instead. NVidia’s proprietary driver generally works very well with Tumbleweed.» The previous incantation of the welcoming page used more direct wording. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.3 (Legolas))
* Carlos E. R. <robin.listas@telefonica.net> [07-27-22 06:06]:
On 27/07/2022 03.21, Patrick Shanahan wrote:
* Carlos E. R. <robin.listas@telefonica.net> [07-26-22 18:29]:
On 26/07/2022 21.20, Aaron Digulla wrote:
Am 20.06.22 um 00:34 schrieb Peter Maffter:
Am 19.06.22 um 22:10 schrieb Per Jessen:
The challenge for openSUSE is to let people fix what ain't broke - without breaking it.
So how can I as a simple user fix the compile errors that nVidia drivers have with the new kernel 5.18.1?
Would it have been very hard for Suse to check and give me some information like: "We Tumbleweed guys tested current nVidia drivers with this new kernel. It does not work. It throws compile errors. So for the time being and for your benefit we will not install 5.18.1 on your machine and keep the older kernel. Please read here: <some further Suse information about this problem>" ?
I run into this once or twice per year which is not that bad and extremely infuriating when it happens.
From my point of view, the main problem is that most updates run without a hitch. So when it happens, I usually want to do something. And I can't because the computer behaves oddly. Since this is rare, I don't do a full backup before every update.
Now I have an unknown problem and must spend time to find out what it is instead of doing what I planned to do.
There is a warning somewhere that if you use Tumbleweed and have an Nvidia card with the proprietary driver, things like this will happen now and then. Thus, if this is a problem for you, either don't use Nvidia or don't use Tumbleweed.
no, boot an earlier kernel and wait for correction.
Now don't start asking me for a cite, because I don't remember where I read this, years ago, maybe more than a decade ago :-P
then refrain from spreading FUD!
Patrick, please stop insulting me. Or maybe you lost your memory, or are too biased to remember.
Official info:
<https://en.opensuse.org/Portal:Tumbleweed>
«Third Party Drivers
Due to the fast pace of kernel upgrades on Tumbleweed, 3rd party kernel driver modules may not be fast enough to catch up with the latest kernel version. In the unlikely case that your kernel driver module does not work on Tumbleweed, please consider using openSUSE Leap instead.
NVidia’s proprietary driver generally works very well with Tumbleweed.»
The previous incantation of the welcoming page used more direct wording.
but you only quote that which puts your comment in better light. reading further explains that AMD drivers are more of a problem and does not explain that merely reverting to the previous working kernel for a short time is most generally a working answer. Tumbleweed is a solid, working distro which requires some knowledge and loving care. it is *not* a haphazard collection of applications as you usually attempt to convey. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
Le 19/06/2022 à 22:10, Per Jessen a écrit :
The challenge for openSUSE is to let people fix what ain't broke - without breaking it.
The german language has the verb "verschlimmbessern", which means "breaking something while trying to improve it". Here in France we say "Le mieux est l'ennemi du bien". -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12
On 2022-06-20 09:38, Nicolas Kovacs wrote:
Le 19/06/2022 à 22:10, Per Jessen a écrit :
The challenge for openSUSE is to let people fix what ain't broke - without breaking it.
The german language has the verb "verschlimmbessern", which means "breaking something while trying to improve it".
Here in France we say "Le mieux est l'ennemi du bien".
I rather prefer David Rankin's comment about children playing with crayons :D
Nicolas Kovacs wrote:
Le 19/06/2022 à 22:10, Per Jessen a écrit :
The challenge for openSUSE is to let people fix what ain't broke - without breaking it.
The german language has the verb "verschlimmbessern", which means "breaking something while trying to improve it".
Genau.
Here in France we say "Le mieux est l'ennemi du bien".
Heh, nice one. Thanks for that. -- Per Jessen, Zürich (28.8°C)
On Mon, 20 Jun 2022 17:38:36 +0200 Nicolas Kovacs <info@microlinux.fr> wrote:
Le 19/06/2022 à 22:10, Per Jessen a écrit :
The challenge for openSUSE is to let people fix what ain't broke - without breaking it.
The german language has the verb "verschlimmbessern", which means "breaking something while trying to improve it".
Here in France we say "Le mieux est l'ennemi du bien".
Or maybe "Le miaou est l'ennemi du chien"? :)
On Sun, 19 Jun 2022 14:09:57 +0200 Nicolas Kovacs <info@microlinux.fr> wrote:
Hi,
I'm the manager of a small IT firm with a focus on Linux and Open Source software. On my servers I'm running a mix of various RHEL clones like CentOS, Oracle Linux and Rocky Linux. On the desktop side, I've been using OpenSUSE Leap with KDE since version 15.0.
Leap is powering all the desktop clients in our local school, and everybody (school staff, teachers, students) is very happy with it.
I just finished polishing up my bone-headed post-install configuration script for Leap 15.4:
https://gitlab.com/kikinovak/opensuse-lp154/-/blob/main/setup.sh
And I just learned that SUSE will phase out Leap after the 15.5 release.
So here's a few thoughts I want to share with the distribution maintainers.
1. Perennity anyone ? Duh ?
2. After the CentOS debacle in 2020, it looks like distribution maintainers love pissing off their userbase by pulling the rug from under their feet. Hint: we hate it.
3. Some official SUSE guy on Twitter who shall remain unnamed likes to explain on a regular basis that rolling releases are the future and folks who rely on releases are utterly clueless. As someone who tried to maintain a dozen production client desktops based on Arch Linux as far back as 2006 and failed miserably after a udev update broke everything, here's a thought from my professional experience. My Number One Fight Club rule: YOU DO NOT USE ROLLING RELEASES IN A PRODUCTION ENVIRONMENT. Yes, I shouted that out loud.
I'm a little confused about all this release business. To me a release means a garanteed bulletproof edition of something, you know, like windows the last release of which was XP, or if you want then a car like a 1959 Fleetwod Convertible. A release NEVER meant a clay model or a bleeding edge test-bed! A rolling-release means a release that is a departure from what a release was before ONLY in that in never needs to be reinstalled. Just because it's rolling, a release is still the same release that release always meant before. Smooooth and nice try but it don't sell! A rolling-release yes, but not according to the definition the industry is trying to cook for itself. Think of a car for which one gets new engines or bumpers but that forever remains and garanteed and a Fleetwood Convertible. So what now, what will Leap users be expected to do, go capital letter EXPERIMENTAL or buy commercial? I've been using TW for the not at all infrequent sessions when Leap didn't work, and it also has had not infrequent failed states.
bent fender wrote:
I'm a little confused about all this release business. To me a release means a garanteed bulletproof edition of something, you know, like windows the last release of which was XP, or if you want then a car like a 1959 Fleetwod Convertible.
From a support perspective, a release is a point of reference. For cars and Windows, support and spareparts are required, for instance. For openSUSE, we have lifecycles during which we provide some support and fixes.
A release NEVER meant a clay model or a bleeding edge test-bed!
Around here it sometimes does resemble one. There is no business support model here, and somethings are definitely being submitted for testing into the greater community with openSUSE releases. -- Per Jessen, Zürich (29.7°C)
On 2022-06-19 14:19, Per Jessen wrote:
bent fender wrote:
A release NEVER meant a clay model or a bleeding edge test-bed!
Around here it sometimes does resemble one. There is no business support model here, and somethings are definitely being submitted for testing into the greater community with openSUSE releases.
Perhaps there are difference of opinion on just what "greater community" means. Some might take it to mean only developers plus all the guinea pigs who sign up to test the stuff. To me, at least in the current sense, that term definitely does not mean "everyone".
Darryl Gregorash wrote:
On 2022-06-19 14:19, Per Jessen wrote:
bent fender wrote:
A release NEVER meant a clay model or a bleeding edge test-bed!
Around here it sometimes does resemble one. There is no business support model here, and somethings are definitely being submitted for testing into the greater community with openSUSE releases.
Perhaps there are difference of opinion on just what "greater community" means.
I think it it means "every user of openSUSE".
Some might take it to mean only developers plus all the guinea pigs who sign up to test the stuff. To me, at least in the current sense, that term definitely does not mean "everyone".
I guess it depends much on whether you consider yourself to be to part of the community or "merely" just a user. I'm going out on a limb here, but I think I would say the "openSUSE community" is comprised of everyone who _contributes_ in some or other way, minor, major, whatever. There is a gazillion ways to do that, but nobody has any obligation to do so and those who don't are much valued users in the "greater openSUSE community" anyway. I hesitate abusing the word "community" - it's like saying anyone who uses public transport is part of a community, but when we (openSUSE) release something new, a new default filesystem for instance, we still unleash it onto our entire user base. Is that the "greater openSUSE community"? -- Per Jessen, Zürich (27.9°C)
Am 19.06.22 um 22:19 schrieb Per Jessen:
Around here it sometimes does resemble one. There is no business support model here, and somethings are definitely being submitted for testing into the greater community with openSUSE releases.
Does this mean with Tumbleweed I was a "tester" without knowing it regarding the new kernel and nVidia drivers and nobody tested this (at least once) before with that 5.18.1 kernel and nvidia drivers before "releasing" Tumbleweed? :-( See subject: "Tumbleweed with 5.18.1 : Problem with NVidia driver" Pete
Peter Maffter wrote:
Am 19.06.22 um 22:19 schrieb Per Jessen:
Around here it sometimes does resemble one. There is no business support model here, and somethings are definitely being submitted for testing into the greater community with openSUSE releases.
Does this mean with Tumbleweed I was a "tester" without knowing it regarding the new kernel and nVidia drivers and nobody tested this (at least once) before with that 5.18.1 kernel and nvidia drivers before "releasing" Tumbleweed? :-(
Yes and no. You most certainly tested it and no, you most certainly knew nothing about it. Everytime a user reports a problem with Tumbleweed, it is because of something that was not tested. -- Per Jessen, Zürich (26.6°C)
Am 20.06.22 um 00:36 schrieb Per Jessen:
Peter Maffter wrote:
Am 19.06.22 um 22:19 schrieb Per Jessen:
Around here it sometimes does resemble one. There is no business support model here, and somethings are definitely being submitted for testing into the greater community with openSUSE releases.
Does this mean with Tumbleweed I was a "tester" without knowing it regarding the new kernel and nVidia drivers and nobody tested this (at least once) before with that 5.18.1 kernel and nvidia drivers before "releasing" Tumbleweed? :-( Yes and no. You most certainly tested it and no, you most certainly knew nothing about it. Everytime a user reports a problem with Tumbleweed, it is because of something that was not tested.
Thanks for confirming that nobody from the Tumbleweed guys tested kernel 5.18.1 with the current nVidia driver NVIDIA-Linux-x86_64-390.151.run resulting in compile errors and sending me into not having graphics or X11. :-( Otoh does this mean that users of older graphic cards like GTX 570 should not use Tumbleweed because nobody will test such a combination? BR Pete
On 2022-06-20 00:45, Peter Maffter wrote:
Am 20.06.22 um 00:36 schrieb Per Jessen:
Peter Maffter wrote:
Am 19.06.22 um 22:19 schrieb Per Jessen:
Around here it sometimes does resemble one. There is no business support model here, and somethings are definitely being submitted for testing into the greater community with openSUSE releases.
Does this mean with Tumbleweed I was a "tester" without knowing it regarding the new kernel and nVidia drivers and nobody tested this (at least once) before with that 5.18.1 kernel and nvidia drivers before "releasing" Tumbleweed? :-( Yes and no. You most certainly tested it and no, you most certainly knew nothing about it. Everytime a user reports a problem with Tumbleweed, it is because of something that was not tested.
Thanks for confirming that nobody from the Tumbleweed guys tested kernel 5.18.1 with the current nVidia driver NVIDIA-Linux-x86_64-390.151.run resulting in compile errors and sending me into not having graphics or X11. :-(
The documentation re Tumbleweed says that Tw is machine tested, which obviously covers what people have been able to design into those automated tests. Obviously there are new problems that only humans can find, and yes, you are that human (that's what being bleeding edge means: you sometimes bleed). That said, Nvidia is external, how kernel changes affect the drivers is often found out after the kernel is published.
Otoh does this mean that users of older graphic cards like GTX 570 should not use Tumbleweed because nobody will test such a combination?
There is actually a recommendation somewhere in the Tumbleweed docus to NVidia users that there can be problems, and that perhaps not everybody should use it. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
On Mon, Jun 20, 2022 at 9:20 AM Carlos E. R. <robin.listas@telefonica.net> wrote: ...
That said, Nvidia is external, how kernel changes affect the drivers is often found out after the kernel is published.
I have Linux HA systems running Tumblweed and the DRBD kernel driver was lost after updating to kernel 5.18. So it has nothing to do with "being external" - DRBD KMP is provided by Tunbmeweed. There is no policy that says "every KMP must be rebuilt against a new kernel before this kernel will be made available ''. Now those systems are just for playing so I do not care. But it can be pretty frustrating for "production use".
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2022-06-20 at 10:01 +0300, Andrei Borzenkov wrote:
On Mon, Jun 20, 2022 at 9:20 AM Carlos E. R. <> wrote: ...
That said, Nvidia is external, how kernel changes affect the drivers is often found out after the kernel is published.
I have Linux HA systems running Tumblweed and the DRBD kernel driver was lost after updating to kernel 5.18. So it has nothing to do with "being external" - DRBD KMP is provided by Tunbmeweed. There is no policy that says "every KMP must be rebuilt against a new kernel before this kernel will be made available ''.
I was rather thinking of the ...run file they provide, and then the rpm we generate and that they provide.
Now those systems are just for playing so I do not care. But it can be pretty frustrating for "production use".
Yep. - -- Cheers, Carlos E. R. (from openSUSE 15.3 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYrBybBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV69QAnjPt7hzkOVaJNlbiTyfu YcRi0glWAJ0Q6jnI1rXQchtl5n0MtnLp4fytCQ== =P8EO -----END PGP SIGNATURE-----
Andrei Borzenkov wrote:
On Mon, Jun 20, 2022 at 9:20 AM Carlos E. R. <robin.listas@telefonica.net> wrote: ...
That said, Nvidia is external, how kernel changes affect the drivers is often found out after the kernel is published.
I have Linux HA systems running Tumblweed and the DRBD kernel driver was lost after updating to kernel 5.18. So it has nothing to do with "being external" - DRBD KMP is provided by Tunbmeweed. There is no policy that says "every KMP must be rebuilt against a new kernel before this kernel will be made available ''.
Now those systems are just for playing so I do not care. But it can be pretty frustrating for "production use".
+1 I was quite upset some years back when HP(E) pulled the cciss driver from the kernel, replacing it with hpsa. That would typically have been fine, except you had to add some option to enable hpsa to support older raid cards :-( -- Per Jessen, Zürich (29.1°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland.
Am Montag, 20. Juni 2022, 00:45:05 CEST schrieb Peter Maffter:
Otoh does this mean that users of older graphic cards like GTX 570 should not use Tumbleweed because nobody will test such a combination?
That could prove quite true; on the other hand, users with **newer** hardware (my laptop, for example) will end up **having** to use TW since Leap with its "SLES-backwards-compatible-to-the-onboard-computer-of-noahs-arc' legacy won't be working all that well. Trust me, I've tried with leap first. Don't get me wrong, I definitely understand, and agree with, the backwards compatibility line of thinking - for ENTERPRISE systems. But IMO Leap itself never was, and should never pretend to be, an enterprise OS. Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org Jabber (XMPP): lemmy@tuxonline.tech Matrix: @mathias:eregion.de IRC: [Lemmy] on freenode and ircnet (bouncer active) keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
Le 20/06/2022 à 09:08, Mathias Homann a écrit :
Don't get me wrong, I definitely understand, and agree with, the backwards compatibility line of thinking - for ENTERPRISE systems. But IMO Leap itself never was, and should never pretend to be, an enterprise OS.
Leap's half-enterprise/half-rolling concept may seem weird but solves some problems here. It's "just the right dose of new". Servers are all running RHEL clones here. We also tried to base our desktop systems on these, but regularly had problems with newer and/or exotic hardware. Which led to interesting situations like "OK, this third-party kernel and driver repository allows me to configure either my video card or my Wi-Fi, but not both". :o) -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12
Peter Maffter wrote:
Otoh does this mean that users of older graphic cards like GTX 570 should not use Tumbleweed because nobody will test such a combination?
Hi Pete, I expect users of any hardware older than e.g. 10 years will find that the testing in TW is minimal bordering on non-existent. The focus of TW is the bleeding edge, the forefront. Older hardware is not deliberately left out, but it's just not the focus so will receive a lot less attention. -- Per Jessen, Zürich (29.2°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland.
* Per Jessen <per@computer.org> [06-21-22 13:25]:
Peter Maffter wrote:
Otoh does this mean that users of older graphic cards like GTX 570 should not use Tumbleweed because nobody will test such a combination?
Hi Pete, I expect users of any hardware older than e.g. 10 years will find that the testing in TW is minimal bordering on non-existent. The focus of TW is the bleeding edge, the forefront. Older hardware is not deliberately left out, but it's just not the focus so will receive a lot less attention.
as in "not generally available" to test past previously experienced problems. I am using an 11 year old desktop with few problems that I can not personally solve. that said, the most general problem is the need to utilize nvidia drivers for graphics work. and I am still using said machine, although I have just obtained a new, "bleeding" edge 20 core i7 36Gb with nVidia RTX 3060 Ti 8Gb. and it works tooooo. it is somewhat difficult to test on machinery not generally available, which allows the state "testing in TW is minimal bordering on non-existant." but the "general statement" testing in TW is minimal is NOT TRUE. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
Patrick Shanahan wrote:
it is somewhat difficult to test on machinery not generally available, which allows the state "testing in TW is minimal bordering on non-existant." but the "general statement" testing in TW is minimal is NOT TRUE.
It wasn't a general statement, it was quite clearly focused on hardware older than 10 years. I have however also found that many less-than-general cases are not tested either. Switching a virtual console to power-saving mode stopped working years ago. Recently, in the openSUSE infrastructure, we even had a Leap 15.4 upgrade issue, due to non-testing. Presumably also in TW. -- Per Jessen, Zürich (23.8°C)
* Per Jessen <per@computer.org> [06-21-22 15:34]:
Patrick Shanahan wrote:
it is somewhat difficult to test on machinery not generally available, which allows the state "testing in TW is minimal bordering on non-existant." but the "general statement" testing in TW is minimal is NOT TRUE.
It wasn't a general statement, it was quite clearly focused on hardware older than 10 years. I have however also found that many less-than-general cases are not tested either. Switching a virtual console to power-saving mode stopped working years ago. Recently, in the openSUSE infrastructure, we even had a Leap 15.4 upgrade issue, due to non-testing. Presumably also in TW.
so, perhaps the "non-testing" is due to a lack of usage. not unlike most software and not unique to Tw? fwiw, the difference between 90% and 88% is not labled substantial :) -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
Patrick Shanahan wrote:
* Per Jessen <per@computer.org> [06-21-22 15:34]:
Patrick Shanahan wrote:
it is somewhat difficult to test on machinery not generally available, which allows the state "testing in TW is minimal bordering on non-existant." but the "general statement" testing in TW is minimal is NOT TRUE.
It wasn't a general statement, it was quite clearly focused on hardware older than 10 years. I have however also found that many less-than-general cases are not tested either. Switching a virtual console to power-saving mode stopped working years ago. Recently, in the openSUSE infrastructure, we even had a Leap 15.4 upgrade issue, due to non-testing. Presumably also in TW.
so, perhaps the "non-testing" is due to a lack of usage.
More likely the lack of creation of test-cases in openQA. -- Per Jessen, Zürich (23.1°C)
Per Jessen composed on 2022-06-21 21:32 (UTC+0200):
Switching a virtual console to power-saving mode stopped working years ago.
What do you mean? consoleblank= isn't what you need? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Felix Miata wrote:
Per Jessen composed on 2022-06-21 21:32 (UTC+0200):
Switching a virtual console to power-saving mode stopped working years ago.
What do you mean? consoleblank= isn't what you need?
Correct. I mean - I have about 200 servers on KVM switches in my downstairs server-room. None have any X, they are all operated over a few consoles. None of them switch into power-saving mode after some period of inactivity. -- Per Jessen, Zürich (22.9°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland.
On 6/21/22 14:49, Felix Miata wrote:
Per Jessen composed on 2022-06-21 21:32 (UTC+0200):
Switching a virtual console to power-saving mode stopped working years ago.
What do you mean? consoleblank= isn't what you need?
You can actually just write a systemd service and enable that, e.g. ## systemd service file to restore default blanking and powerdown for # virtual consoles after a given timeout period (5-min blank, 6-min powerdown) # this functionality was originally provided by the kernel defaults setting # /sys/module/kernel/parameters/consoleblank 600 (now 0-disabled). the # blanking and powerdown were delegated to systemd to implement, but no ## service was ever provided by systemd to accomplish this fundamental task. [Unit] Description=Enable virtual console blanking and poweroff [Service] Type=oneshot Environment=TERM=linux StandardOutput=tty TTYPath=/dev/console ExecStart=/usr/bin/setterm -blank 5 -powerdown 6 [Install] WantedBy=multi-user.target -- David C. Rankin, J.D.,P.E.
David C. Rankin wrote:
On 6/21/22 14:49, Felix Miata wrote:
Per Jessen composed on 2022-06-21 21:32 (UTC+0200):
Switching a virtual console to power-saving mode stopped working years ago.
What do you mean? consoleblank= isn't what you need?
You can actually just write a systemd service and enable that, e.g.
David, if you can provide proof that it works, please do. We are not nincompoops here, but it simply does _not_ work. -- Per Jessen, Zürich (21.4°C) Слава Україні! Slava Ukraini!
On 6/23/22 14:03, Per Jessen wrote:
David C. Rankin wrote:
On 6/21/22 14:49, Felix Miata wrote:
Per Jessen composed on 2022-06-21 21:32 (UTC+0200):
Switching a virtual console to power-saving mode stopped working years ago.
What do you mean? consoleblank= isn't what you need?
You can actually just write a systemd service and enable that, e.g.
David, if you can provide proof that it works, please do. We are not nincompoops here, but it simply does _not_ work.
Sorry for the late reply Per, https://man7.org/linux/man-pages/man1/setterm.1.html It does work ask advertised, I package it for AUR, e.g. https://aur.archlinux.org/packages/console-blanking The service file is simply: [Unit] Description=Enable virtual console blanking and poweroff [Service] Type=oneshot Environment=TERM=linux StandardOutput=tty TTYPath=/dev/console ExecStart=/usr/bin/setterm -blank 5 -powerdown 6 [Install] WantedBy=multi-user.target You can change the target if you want it outside of multi-user. -- David C. Rankin, J.D.,P.E.
On 2022-06-21 19:22, Per Jessen wrote:
Peter Maffter wrote:
Otoh does this mean that users of older graphic cards like GTX 570 should not use Tumbleweed because nobody will test such a combination?
Hi Pete, I expect users of any hardware older than e.g. 10 years will find that the testing in TW is minimal bordering on non-existent. The focus of TW is the bleeding edge, the forefront. Older hardware is not deliberately left out, but it's just not the focus so will receive a lot less attention.
Hum! That contrasts with TW having a 32 bit release, and Leap not. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Carlos E. R. wrote:
On 2022-06-21 19:22, Per Jessen wrote:
Peter Maffter wrote:
Otoh does this mean that users of older graphic cards like GTX 570 should not use Tumbleweed because nobody will test such a combination?
Hi Pete, I expect users of any hardware older than e.g. 10 years will find that the testing in TW is minimal bordering on non-existent. The focus of TW is the bleeding edge, the forefront. Older hardware is not deliberately left out, but it's just not the focus so will receive a lot less attention.
Hum!
That contrasts with TW having a 32 bit release, and Leap not.
Not really. The QA testing being done is the same. I very much hesitate running any PAE TW kernel. -- Per Jessen, Zürich (23.4°C) Слава Україні! Slava Ukraini!
On 6/19/22 07:09, Nicolas Kovacs wrote:
Cheers from the blazing hot South of France,
Niki Kovacs (https://tinyurl.com/2p8tk495)
Niki, Thank you, for a well written and reasoned rant. Lord knows I have my share. I've not looked beyond the 15.5 roadmap, but ever since SuSE/openSUSE reversed the role of the open-source release feeding into SLE a couple of years back, it did leave me scratching my head. In practice, however they want to explain it, it still works largely the way it was intended. The community still provides feedback, authors bugs, etc... as part of the development process that helps ensure the community release minimizes the number of bugs that get through to bewilder paying clients. Rolling releases have the Achilles's heel of having to coordinate among various upstream packages to make a desktop work. It's trivial to keep your vanilla distro running in a rolling manner without anything that taints the kernel, but mix nvidia (or other proprietary drivers), and kernel updates and you have a real recipe for downtime until whatever new incompatibility can be resolved -- which sometimes can take weeks. (look at Virtualbox and the 5.18 kernel now, Larry had a patch a month ago, be we still have no 6.1.36 release from Oracle) Distributions have always had the uncanny ability to snatch defeat from the jaws of victory (or throw the baby out with the bathwater, pick your metaphor). Mandrake was one of the first shining examples of that. It would be a dumbfounding stroke of negligence to get rid of the QA and development help SuSE/openSUSE gets from the normal release cycle that has supported them to date. Who knows, you keep putting kids with Crayons in charge, sometimes you end up in places you don't want to be... I don't have time to worry about what some idiot says on social media, I'm not a bird, I don't tweet, but you would hope that cooler heads would prevail in preserving the SuSE/openSUSE model that has worked well for 20+ years. While it lasted, the "Evergreen" idea for a LTS release worked really well as a model extending a release and allowing a flexible upgrade timeline. But it too has fallen victim to that uncanny ability as well. But through it all, another very good 15.4 release was made (aside from a mirror hiccup or two) and many bugs were authored, many fixed, and the SLE codebase is the better for it. It's hard to see a desire to change that process by eliminating the community release model -- whatever they call it next. -- David C. Rankin, J.D.,P.E.
Le 20/06/2022 à 07:12, David C. Rankin a écrit :
Rolling releases have the Achilles's heel of having to coordinate among various upstream packages to make a desktop work. It's trivial to keep your vanilla distro running in a rolling manner without anything that taints the kernel, but mix nvidia (or other proprietary drivers), and kernel updates and you have a real recipe for downtime until whatever new incompatibility can be resolved -- which sometimes can take weeks. (look at Virtualbox and the 5.18 kernel now, Larry had a patch a month ago, be we still have no 6.1.36 release from Oracle)
Thank you for your eloquent answer, David. I'd say I like my Linux distribution as I like my motorcycle: boring. Of course it's fun to fool around on a Honda VTR 1000 Firestorm (I know, I did it). But when I'm planning a trip around Europe, I'd rather use my battered old BMW 750 which doesn't look very sexy but which takes me to the end of the world. The problem has been stated in an earlier post, and you can even read it in various distribution release notes. All the "exciting" new features, all the "technology previews". When I read "exciting", I understand "half-baked implementation of something that will potentially ruin my weekend because I will have to find a fix". There's a curious phenomenon going on in the Free and Open Source world. Whenever something reaches a state nearing perfection, the developers/maintainers toss it out and start again from scratch. Remember the transition from GNOME 2.32 to 3.0? Remember the upgrade from the latest KDE in the 3.x series to 4.0? Red Hat's implementation of KDE was one of the cleanest I've ever seen. So clean that they decided to ditch it completely and go for GNOME (meh). I get it: you have to change things to go forward. But sometimes - as in the cases stated in the last paragraph - progress comes in the form of a huge regression, and the user ends up with a series of components that have to be potty-trained again from scratch. That's precisely the "raison d'être" of a release. Provide a platform that sports no surprises, with security updates over the whole support cycle. Part of my job consists in teaching computer students here at the École des Mines d'Alès, and go figure, most of them have a hard time to grasp the concept of Long Term Support and low-risk security updates. They all run Arch, BTW. :o) My initial rant was fueled by the fear that OpenSUSE Leap in its current form might just go away or be replaced by something so exciting it's barely usable. Yes, I first read about it on Distrowatch and then asked about it in the forum. Maybe it's just an unfounded rumour after all, go figure.
But through it all, another very good 15.4 release was made (aside from a mirror hiccup or two) and many bugs were authored, many fixed, and the SLE codebase is the better for it. It's hard to see a desire to change that process by eliminating the community release model -- whatever they call it next.
Yes, OpenSUSE Leap is one of the nicest things that ever happened to the Linux workstation. So one word to the OpenSUSE maintainers. It JustWorks(tm). That's where the *real* excitement is. Cheers, Niki -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12
On 6/20/22 00:44, Nicolas Kovacs wrote:
There's a curious phenomenon going on in the Free and Open Source world. Whenever something reaches a state nearing perfection, the developers/maintainers toss it out and start again from scratch. Remember the transition from GNOME 2.32 to 3.0? Remember the upgrade from the latest KDE in the 3.x series to 4.0? Red Hat's implementation of KDE was one of the cleanest I've ever seen. So clean that they decided to ditch it completely and go for GNOME (meh).
Chuckling so hard I almost fainted.... Oh lord, you are singing to the choir. Most of my rants on this list have been about just that point. Yes, we lived through 11.0 with KDE 4.0.4a as the default desktop, and 200+ bugs later it wasn't much better. And don't even get me on my Gtk soapbox -- the general toolkit that became a basic library for Gnome, the 1000s of developers that had relied on the general nature of the toolkit be damned. But beyond the details, from a desktop standpoint, it all boils down to "Can I just get work done?" or do I have to spend an hour of my day collecting data and authoring a bug report for something that broke or doesn't work correctly. I'd much rather just use fluxbox or icewm and just work than fight with a file-manager that used to work perfectly but now can open up twice looking the same way it did the last time I opened it, etc.., etc... Your paragraph captures the program concisely. Imagine 10,000 person business that had committed to the Linux desktop in 2006 and trained all its employees to use a spectacularly good KDE3. And then less than two years later, after a long weekend for their IT team, they sit down to KDE 4.0.4a. The only thing worse would be if you had been a gnome theme writer for the past 15 years only to have what you tediously wrote today broken by the next (and almost every) minor version release of Gtk since (with planned continued breakage until 4.14 I think I read). There is a reason Gimp still has parts of Gtk+2 in it -- they deprecated the rulers in Gtk+3, despite the whole damn toolkit originating as the Gimp Tool Kit... (go figure) So in short, I feel and share your pain. The problem can be summarized as this. Projects used to go to great lengths to be community oriented (what's good for the community), and now we see that being replaced by what's expedient for the project. Linux isn't the same as it was 20 years ago, and that's a shame. But at the same time, it still fills a very important space for users around the globe (as well as being profitable for the parent companies). It brings the "means of creation" (be it documents, graphics, video, IT infrastructure, etc.) to the masses. The basic bargain is still the same, we will give you the means of creations, but please give back and help make it better. And while I may not agree with all the decisions various parts of the desktops or toolkits have taken over the last 20 years, the basic bargain is still the same. One other area I feel and share your pain is HEAT. I live in Texas, and yes we are used to HOT, but this June has shattered records all over the state. And that's a whole additional soapbox ... one no matter how bad we want to fix it -- we may be beyond the point where we can make any difference. Pleasant thought... -- David C. Rankin, J.D.,P.E.
On 2022-06-20 02:15:38 David C. Rankin wrote:
|On 6/20/22 00:44, Nicolas Kovacs wrote: |> There's a curious phenomenon going on in the Free and Open Source world. |> Whenever something reaches a state nearing perfection, the |> developers/maintainers toss it out and start again from scratch. |> Remember the transition from GNOME 2.32 to 3.0? Remember the upgrade |> from the latest KDE in the 3.x series to 4.0? Red Hat's implementation |> of KDE was one of the cleanest I've ever seen. So clean that they |> decided to ditch it completely and go for GNOME (meh). | |Chuckling so hard I almost fainted.... | | Oh lord, you are singing to the choir. Most of my rants on this list | have been about just that point. Yes, we lived through 11.0 with KDE | 4.0.4a as the default desktop, and 200+ bugs later it wasn't much better. | And don't even get me on my Gtk soapbox -- the general toolkit that | became a basic library for Gnome, the 1000s of developers that had relied | on the general nature of the toolkit be damned.
Do you ever get the impression that the Linux Distro community is working hard to urge all their desktop users to convert back to Windoze? Leslie -- Operating System: Linux Distribution: openSUSE Leap 15.4 x86_64 Desktop Environment: Trinity Qt: 3.5.0 TDE: R14.0.12 tde-config: 1.0
participants (17)
-
Aaron Digulla -
Andrei Borzenkov -
bent fender -
Carlos E. R. -
Darryl Gregorash -
Dave Howorth -
David C. Rankin -
David T-G -
Felix Miata -
gumb -
J Leslie Turriff -
Mathias Homann -
Nicolas Kovacs -
Patrick Shanahan -
Per Jessen -
Peter Maffter -
Peter McD