[Discussion] Why are severely broken point releases being released for Bookworm

[Borg]

The Debian market is a little more than internet surfing and games. Steam stats are of little relevance. That really is

"a fraction of a minority within a select group of a few"

This thread is related to Debian on the desktop, not servers.

See also my above comment:
viewtopic.php?p=793263#p793263

[CwF]

This thread is related to Debian on the desktop, not servers.

The subject is point releases, and they apply to all of Debian.

[steve_v]

Indeed, and this is in large part the attitude that pulls my chain which I alluded to earlier - Namely that the "average" (and largest / most important goup) of Debian users are desktop "web-browser & games" users, and and that anything introducing any friction whatsoever for them should be top priority. Corollary to that is the idea that the "new user experience" is of the utmost importance, as if simply using Debian (while also expecting a no-understanding(or effort)-required point-and-click "free windows") is somehow doing the project a huge favour.


Steam surveys are completely pointless, since they don't capture anyone or anything except gamers and PCs used for gaming, and they will be heavily skewed by the steamdeck. That's not even remotely a representative sample of total active Debian installs.

The outsized noise over this temporary, minor inconvenience is all coming from one small subset of the community, and it's the very definition of "vocal minority". Asking why this happened is one thing, claiming it's a critical component and userspace is completely broken is something else entirely.
The sky is not falling, just use a different kernel until the fix is released.

[el_koraco]

The sky is not falling, just use a different kernel until the fix is released.

But the reputation, the attracting of new Steam users!

[steve_v]

Uh huh. (assuming sarcasm). I don't know where this "attracting new users" at all costs mentality comes from, but it's proper irritating... As is the fixation on proprietary software and out-of-the-box support for FOSS-hostile hardware.
Yes, we do like adding new people to the community, and Debian does have pretty reasonable support for proprietary closed-source crap software. Are those things tippy-top priority and the primary criteria on which to judge release quality? Hell no.


What really gets me here is the ridiculous hyperbole. From thread titles alone:
"Severely broken"
"System breaking"
"Update screwed"
"Broke GPU"

FFS, it's one optional driver in the non-free repo... A driver with a long, long history of random breakage and a properly uncooperative upstream, factors which anyone using it should be well aware of by now.
A GPU driver failure is not a broken system. The fix is already in proposed-updates, and until then there is a trivial and obvious workaround.

Optional closed-source drivers in non-free getting less rigorous testing than the ~60000 other packages in main (including an alternative FOSS driver for the same hardware)? Shock and horror.
Nvidia driver borkage? Again? Oh noes, how games?.. Yawn.
What's the big deal here?

[el_koraco]

Uh huh. (assuming sarcasm). I don't know where this "attracting new users" at all costs mentality comes from, but it's proper irritating... As is the fixation on proprietary software and out-of-the-box support for FOSS-hostile hardware.

It is the arguments Microsoft's troll army used to paddle back in the day. I guess people in the FOSS community have taken it to heart. We should all be better members of the community. I should file a bug report, because the last three kernels don't recognize my wifi card, yet here I am running the kernel from backports...

[LeeE]

Unfortunately, there isn't any real alternative to proprietary software and hardware for some workloads such as CUDA & OpenGL, and I can't see that changing anytime soon.

It would be ideal if, for example, Nvidia's drivers were released under an open-source license acceptable to Debian but if we accept that Nvidia's IP is owned by them then we have to accept that they have the freedom to chose how they release their software.

If Nvidia were to suddenly change their approach and release their drivers under an open-source license it would appear to bring them a number of predictable short and long term benefits, but it would also expose them to unpredictable risks, so if Nvidia is to be prudent then they're not going to change anything suddenly, and certainly not while the potential for disruption that might be caused by the rapid and widespread introduction of "AI" into so many areas of people's lives remains untested.

But things are not as bad as they might appear; both Nvidia and the open-source community have both worked together to reach a solution that is easy to use, whether it be via non-free packages in the repo or via Nvidia's download. I think both are to be commended for this.

I don't think there's a great chasm between to two sides, as it were, just a narrow fissure one could jump across. Trouble is, it looks awfully deep in places.

[pwzhangzz]

the last three kernels don't recognize my wifi card, yet here I am running the kernel from backports...

We always have a wifi usb card which operates under an open-sourced wifi driver ready, just in case. Running a proprietary hardware always carries a risk. Most of the time we don't know what wifi chip is embedded in a laptop before purchase (sometimes the same model even carries different wifi cards).

However, going back to the main issue of this thread, we do have a choice with regard to the video chips that we buy. I am always of this opinion that taking a risk of buying a nvidia-equipped machine and then complain about Debian developers not able to cover your own mistake, is manifestly unconscionable.

[pwzhangzz]

Unfortunately, there isn't any real alternative to proprietary software and hardware for some workloads such as CUDA & OpenCL, and I can't see that changing anytime soon.

Most CUDA programmers I know NEVER dare to upgrade their Linux kernel. Also, although CUDA is open source*, it has a special license that prohibits Linux developers from packaging it.

Fedora project team has announced that they will package ROCm in the upcoming version (Fedora 40). Really look forward to it (time to refresh my dnf skills ) Hope Debian Sid will follow suit.

When Blender 3 first came out, it only allowed (some) nvidia cards to run hardware acceleration ("cuda"). Nvidia cards were the exclusive choice for Blender developers. But now Blender's hardware acceleration is extended to many Radeon cards. With each Linux kernel upgrade, the performance of Radeon cards elevates.

* Only the front end of CUDA is open source, other than that, it is a proprietary API. In comparison, the entire ROCm is open source, except the firmware part.

[Chaussettes]

Indeed, and this is in large part the attitude that pulls my chain which I alluded to earlier - Namely that the "average" (and largest / most important goup) of Debian users are desktop "web-browser & games" users, and and that anything introducing any friction whatsoever for them should be top priority. Corollary to that is the idea that the "new user experience" is of the utmost importance, as if simply using Debian (while also expecting a no-understanding(or effort)-required point-and-click "free windows") is somehow doing the project a huge favour.


Steam surveys are completely pointless, since they don't capture anyone or anything except gamers and PCs used for gaming, and they will be heavily skewed by the steamdeck. That's not even remotely a representative sample of total active Debian installs.

The outsized noise over this temporary, minor inconvenience is all coming from one small subset of the community, and it's the very definition of "vocal minority". Asking why this happened is one thing, claiming it's a critical component and userspace is completely broken is something else entirely.
The sky is not falling, just use a different kernel until the fix is released.

I think we have different definitions of what a critical component is. If the average desktop user walks into this problem by blindly updating, assuming everything will be alright because this is Debian after all, or have automatic updates turned on in some form like with GNOME Software or unattended-upgrades, and they boot into a system that no longer will show them a desktop, they're stuck. If they encountered the wifi bug and are on a newer machine that does not have ethernet capability, that's a critical component. They are now isolated from being able to look up the problem or use the package manager to try to fix things. Both of these things break the ability for the user to use their computer normally. Both of these problems were known about prior to their releases but they were pushed anyway. That's the point of the thread and why a fair number of people in here are not so happy about it.

Maybe Debian is not trying to be a desktop distro for everyone, but I think it would do some good to have consideration that not everyone is technically capable and issues like this might just be entirely unfixable to them.

[cds60601]

the last three kernels don't recognize my wifi card, yet here I am running the kernel from backports...

We always have a wifi usb card which operates under an open-sourced wifi driver ready, just in case. Running a proprietary hardware always carries a risk. Most of the time we don't know what wifi chip is embedded in a laptop before purchase (sometimes the same model even carries different wifi cards).

This is key... Anyone that wishes to run Debian (or Linux for that matter) ought to be familiar with what is supported and what isn't. In the end, the onus falls on the end user for not educating themselves accordingly.
Imagine what these folks would be like if they were in the WindowsNT days when reading the HCL was a thing and supported hardware was far more limited...

[Borg]

I've always wondered why in most distributions there isn't a direct VESA (or UEFI-GOP) fallback mode for the graphical desktop that can be selected directly and manually by the user via the Grubs boot menu without the need to manually enter any parameters into Grub.

Debian does have a VESA fallback mode for Xorg, but it is chained. First Xorg tries to find a driver that matches the graphics card chip. If nothing is found, it tries to use the following in the following order fbdev, vesa and finally kernel-mode-setting. However, if it finds a suitable driver, it uses the driver. But if the driver loads and then fails when it should display the desktop, it is too late and the user is left with an unusable graphical system. From this point on, only the command line interface (cli) will help him, assuming he is able to switch to it and use it. And beginners are usually overwhelmed and unable to progress with the cli without help. They see a broken graphics mode and that's it.

[CwF]

I think we have different definitions of what a critical component is. If the average desktop user walks into this problem by blindly updating, assuming everything will be alright because this is Debian after all, or have automatic updates turned on in some form like with GNOME Software or unattended-upgrades, and they boot into a system that no longer will show them a desktop, they're stuck

This is a fair point well put.
This shouldn't happen.
As said, the upgrade should be blocked for nvidia in some way.
Then nvidia users are the only users delayed until unblocked from the upgrade.
The vast majority continue unaware.

This thread is a demonstration of the challenges to a new user to garner useful information and form realistic expectations. In this thread it is shown that veterans have the experience to expect these issues, and react with "yes, the sky is in fact blue."

Most CUDA programmers I know NEVER dare to upgrade their Linux kernel.

What a 'regular user' doesn't understand is serious production machines are often never upgraded. They are switched with an upgraded, tested, validated clone. Yes, budgets are involved. Lower budgets schedule a day for the upgrade, that starts with a complete backup. IMHO, automated upgrades are foolish. If anyone's computer is considered 'critical' they are responsible for adopting any methodology required. That means to learn and to adapt expectations on what they farm out to others. The biggest loser in this thread is the concept of self-responsibility, a dying trait. Ask yourself, do windows, mac, iOS and Android users occasionally get screwed? They do, and they're paying money for that. Yes Huxley, we know.

ROCm

that's good news
Frankly, I think nvidia is on the verge of becoming a Matrox in the consumer retail market. The situation is different since nvidia is a major in the commercial market and their lack concern for consumer end points is well established.

if it finds a suitable driver, it uses the driver.

If you used nouveau you would know it does not impede auto detection like an nvidia install does. I can take most of my images, place them in numerous machines with varied hardware, and they dynamically figure it out. I have >70,000 hrs on nouveau btw

[Borg]

if it finds a suitable driver, it uses the driver.

If you used nouveau you would know it does not impede auto detection like an nvidia install does. I can take most of my images, place them in numerous machines with varied hardware, and they dynamically figure it out. I have >70,000 hrs on nouveau btw

You didn't understand what I wrote at all.
If you were to read my post again and properly, you would notice that I didn't write anything about the subject of impeding, but that I basically said that the Nouveau driver is found, it is loaded and then it fails.

[CwF]

Nouveau driver is found, it is loaded and then it fails.

always? in all cases? Obviously not.
Scale your point. Your examples represent what part of the whole?

Sorry you got a bunk nvidia. The one I'm typing on now does fine. I will not be replacing it with another nvidia.

[Borg]

Nouveau driver is found, it is loaded and then it fails.

always? in all cases?

It depends on the bug.
My experiences so far were:
1. It either fails directly
2 or after the login screen
3. or when pushing the mouse around
4. or running something simple as glxgears.

The last bug i had in nouveau with my Geforce Go 6600 it was a graphical failure directly after login (in the list bug level number 2). This means, the desktop is running, but you only see a graphical unusable mess.
And that's the problem, because the fbdev or vesa driver will not help you at that point. A driver is already loaded, in this case nouveau. So the vesa driver will not rescue you here at this point.

If there was a way to directly select in the grub boot menu that the kernel should be loaded with the VESA driver and Xorg and no other graphic driver, then you would have a graphical rescue mode.
I know of another well known operating system with a lot of users that allows exactly that. This feature would be worth copying. And I bet it would help millions of Linux beginners right now.

Sorry you got a bunk nvidia. The one I'm typing on now does fine. I will not be replacing it with another nvidia.

I have 4 NVidia graphics cards¹) on 4 computers. 3 graphic cards are so old that I have to use the Nouveau drivers and for all 3 the Nouveau drivers fail in one of the 4 ways described above.
As I already mentioned in another comment in another thread, I even specifically install for these 3 machines classic 2d login managers and classic 2d desktop environments, that do not use modern OpenGL functions, such as Gnome or KDE do. This at least ensures mostly that instead of bug level 1 or 2, the error only occurs at bug level 3 or 4.

The worst, however, is bug level 3, because it deceives you into thinking that you have a functioning system, then you are working on something, look at the screen crookedly and BAM, graphical ERROR a mess. From then on there's nothing left to do except switch to a CLI and restart Xorg or even reboot the system, if Xorg doesn't give you keyboard control back.

This is a typical behavior of the nouveau drivers by my personal experience with 3 different NVidia cards and Nvidia chipsts. Clearly unusable for productive use.
Luckily I rarely need these 3 computers, the main work is done on the most current computer and this has still the proprietary NVidia drivers running which work great.

¹) Strictly speaking, I also have a Geforce 8800 GTS, so there are 5 cards, but this one is not built into any computer.

[Uptorn]

Corollary to that is the idea that the "new user experience" is of the utmost importance, as if simply using Debian (while also expecting a no-understanding(or effort)-required point-and-click "free windows") is somehow doing the project a huge favour.

I often struggle to find polite ways to state what you just perfectly described.

[Borg]

What I can add to my last comment is the following.

There seems to be a tendency. The older the Geforce graphics card is, the worse the result (bug level) is with the nouveau driver.
This could be viewed both positively and negatively.
The former means that things will get better with newer cards, but the latter means that years have passed by at the nouveau project and the old cards have not been taken much care of. It also means you can assume that once a card reaches a certain age, there will hardly be any bug fixes in the Nouvea drivers for this card.

The Geforce 4 4800 (NV25) was detected by nouveau but it was usually bug level 1. After the support for the proprietary nvidia drivers ended i started to use the old open source 2d only nv drivers for this card as long as they were available, because nouvea was unusable with this card.
The last proprietary drivers that supported this card was nvidia version 96.43.20.
https://www.x.org/releases/current/doc/ ... nv.4.xhtml

For the Geforce 6600 Go (NV43) i had to switch to the nouveau drivers after the end of life of around Debian 9 (stretch)
The last proprietary drivers that supported this card was nvidia version 304.137.
With this videocard, nouveau failed always at level 1 and 2 in Debian 10 and 11.
Debian 12 was a bright spot, the card worked until around September 2023 at level 3, then there was an update in one of the system components and suddenly it was bug level 2. This could mean that the desktop environment or one of its components is using some driver function that leads to the graphics bug. I read in the changelogs of some packages, that was in use and was updated shortly before that bug occured the first time. And in that changelog there was something mentioned that a kind of detection of something, possibly of the driver or a function of the driver was changed, and since then the login leads directly to the graphics bug level 2.
I haven't had time to look into it in more detail yet. But it was not the nouveau package. It is just a function that triggers a bug in the nouveau driver directly after login.

For the Geforce GTX 550 Ti (GF116) i used the nvidia drivers until and including Debian 11.
I switched to nouveau with Debian 12 when it was still at testing, but there is a nvidia-legacy package with nvidia driver version 390.147 in bullseye-backports, so it is an option i could use. But I haven't gotten around to it yet and I didn't need the computer either. But when i switched to debian 12 it was still at testing and thus there was no backports repository that included this legacy driver with the required version.
https://packages.debian.org/search?sear ... dia-legacy
With the nouveau drivers here the bug level was at level 3 and 4 at my last test.
This means I could force the graphics bug by running a program like glxgears (bug level 4) or I could use the desktop normally and the error would appear at some point (bug level 3).

Large desktop environments such as Gnome or KDE, which seem to make heavy use of 3D functions or functions that at least trigger a bug in nouveau, are out of the question with these cards with the nouveau driver.
So I typically use classic 2d window manager and the desktop environments on these machines. In this case it is mate on these cards, which is basically the unofficial successor of Gnome 2 and that was with a few exceptions a classic 2D desktop.

I would have to check the login manager used, but it is definitely not the login manager that Debian 12 currently uses by default.

So these workarounds help a little bit. But I'm far from recommending the nouveau driver to anyone as long as the nvidia drivers are supported and running.

EDIT:
And btw, here is the link to the feature matrix of the nouveau driver:
https://nouveau.freedesktop.org/FeatureMatrix.html

So for me the GPU families NV20, NV40 NV50 and NVC0 are relevant. My current graphics card belongs to the NV130 family, so its support by nouveau will be important in a few years for me.

[Borg]

Indeed, and this is in large part the attitude that pulls my chain which I alluded to earlier - Namely that the "average" (and largest / most important goup) of Debian users are desktop "web-browser & games" users, and and that anything introducing any friction whatsoever for them should be top priority. Corollary to that is the idea that the "new user experience" is of the utmost importance, as if simply using Debian (while also expecting a no-understanding(or effort)-required point-and-click "free windows") is somehow doing the project a huge favour.

It is doing the project a huge favour, because today's Debian users are tomorrow's Debian developers. At least a few of them.

Steam surveys are completely pointless, since they don't capture anyone or anything except gamers and PCs used for gaming, and they will be heavily skewed by the steamdeck. That's not even remotely a representative sample of total active Debian installs.

As I already said, you can filter out steamdeck users based on the graphics chip used. That's in my comment above.

The gamers also particularly include the young audience who do not manage servers today, but may do so tomorrow. And among these gamers are the developers of tomorrow.
You shouldn't be as naive as IBM here, as IBM was with OS/2 and because of this, among other things, lost the OS war against Microsoft.
Microsoft took care of gamers, first with WinG, then with DirectX and today they benefit from those who became developers for Windows software.

So give the young gamers the best experience on Debian and you will win them for tomorrow. That's how assimilation works.

[Chaussettes]

I think we have different definitions of what a critical component is. If the average desktop user walks into this problem by blindly updating, assuming everything will be alright because this is Debian after all, or have automatic updates turned on in some form like with GNOME Software or unattended-upgrades, and they boot into a system that no longer will show them a desktop, they're stuck

This is a fair point well put.
This shouldn't happen.
As said, the upgrade should be blocked for nvidia in some way.
Then nvidia users are the only users delayed until unblocked from the upgrade.
The vast majority continue unaware.

This is something I can agree with and think it would be an somewhat easily-implementable solution that would prevent issues like this from happening to both new and experienced users alike, while allowing Debian to push out updates at their own cadence without having to wait for NVIDIA specific patches