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

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 à 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

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

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

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)

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)

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)

* Peter Maffter [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

* Aaron Digulla [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

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.

* Carlos E. R. [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

* Carlos E. R. [07-27-22 06:06]:

On 27/07/2022 03.21, Patrick Shanahan wrote:

...

* Carlos E. R. [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

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

On Mon, 20 Jun 2022 17:38:36 +0200 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".

Or maybe "Le miaou est l'ennemi du chien"? :)

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)

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)

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)

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)

-----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-----

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

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.

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)

Patrick Shanahan wrote:

* Per Jessen [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)

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.

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 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)

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.