KDE Developers Are Currently Seeing 150~200 Bug Reports Per Day

[rhavenn]

To put this in perspective, KDE normally gets 900-1500 bug reports a month but currently they are track to receive 4500-6000 bug reports in the first month of release.

But I'm a troll, idiot, asshole, dummy, moron, stupid, don't know what I'm talking about and so on, because I expect a project to thoroughly test their software before releasing it.

This is the epitome of being a half-assed project, if Microsoft or Apple released an OS that was garnering 6000 bug reports a month, spite the vastly higher usage of Windows and Mac OS compared to Linux+KDE, then the open source zealots would be crowing up a storm.

But because this is an open source project then it's OK.

Serious question, if KDE wasn't free and you had to pay a per seat license to use it would the community be OK with a release that wasn't thoroughly tested and bug free?

I think we know the answer to that.

You have literally zero idea how many bug reports MS gets per month for, lets say, Windows 11. If if you adjust that to a "install base %" so they're equal in size...you have no idea. It could be higher. It could be lower.

Personally, Arch upgraded to 6.0.1 and outside of not liking the new floating task bar and changing it I didn't notice any issues. Everything continued to work as before.

Also, unless you go through every single bug you have no idea if they're duplicates, high lighting issues with other software that just doesn't work right because that project owner didn't update their stuff yet or where the problem is. KDE gets a lot of bugs thrown at it that aren't necessarily KDE's problem.

[mdedetrich]

Fuzzying may probably address some of the items above but not all of them. I've not heard of the KDE project employing this very powerful debugging technique. Would be nice to hear from ngraham about that.

In the open source software I maintain we use property/fuzzy based testing along with a language with stronger compile guarantees but I think in the case of a DE like KDE, most of the benefit of fuzzing would come from the hardware side of things at which point you are just simulating hardware which is such a massive can of worms because as you rightly pointed out there are so many hardware combinations and ontop of that you would need to make sure that you are not fuzzying invalid states that can never occur in reality.

The only thing I think that would drastic effect of improvement quality of KDE software without requiring ridiculous resources is using more typesafe languages like Rust, its not going to make the unknowns safer but it will make the knowns much safer which makes it easier to identify where underlying issues are. This is going to be a hard sell however given that KDE is literally tied to the Qt framework which is written in C++ and actually has a custom compiler with moc (although someone could translate this to Rust).

Modern C++ is definitely safer than old school C++ so that can help, but it still doesn't come close to Rust

[schmidtbag]

You base this one what exactly?

Do I really need to spell it out for you? If it was 24K bug reports for just Plasma, Dolphin, Phonon, and other KDE essentials then that would be a lot more concerning, but since it includes bugs from all applications you see here, that's a lot spread out. As Nate pointed out, about 1/6 that is specific to Plasma, which is the most important. That's actually not that bad all things considered.
That being said, one of the other things to consider (and has already been pointed out) are programs like Krita, Kdenlive, and a slew of web browsers. I wouldn't be surprised if those collectively make up for at least 1/3 of the bug reports, and I'm sure most people don't use them.

The are not being squashed, as the article makes clear they are growing at a rate of 150 to 200 a day.

So by your logic, you stand outside an ant hill with a hammer, smashing the ants as they leave. Since the queen is pumping out new ants every day, that therefore means none have actually died. Am I getting that right?

BTW, for those that don't know, these bugs also represent security vulnerabilities or attack vectors.

And? Show me any worthwhile OS or DE that doesn't have such things. Seems to me you're just grasping at straws.

When you want to write a virus what you do is you read the developers' documentation provided by the software vendor and you look for legitimate functionality to exploit for nefarious means. That's one avenue, another is you look at bug reports that show unexpected or unwanted behavior to ordinary usage.

Considering KDE 6.0 is no longer in testing, you're not wrong, but you also seem over-paranoid. Perhaps I'm naive in thinking that the chances of someone finding and successfully deploying an exploit in one of the existing bugs before it is patched is virtually nonexistent, but we're talking about a rather small demographic here: you have to be a Linux user, a KDE user, someone on a distro that currently supports KDE 6, and someone who is "technologically challenged" (in the sense that they wouldn't notice something being amiss, or do something known to be stupid regarding malware). So, we're talking a few hundred people at most worldwide.
But let's say the potential to wreak havoc is high, so you look at the top 10 most reproducible bugs: the problem now is, those are also the priority of the developers. So even if several of those bugs are absolutely exploitable, the chances that it will actually reach someone before the next update is pretty slim. After all, the only people who would be affected are those who are actually experiencing the bugs in the first place, so they're going to be the most antsy to update ASAP. Those who don't experience hardly any bugs aren't as much at risk. That's not to say they're not at risk, it's just a lower chance.

In the case of KDE you have 24,000, and counting, ways to screw up someone's system.

Except as you should already be aware: that's 24K across all KDE apps. I wouldn't be surprised if most KDE users don't use most of those apps. Also like mentioned before: some of the bugs are bound to be repeats while others may be fixed by a single underlying cause. So, it's not really that dire - this is expected of a major update. What would be concerning is if there were 24K bugs for Plasma alone, and remained that way for over a year. That would be a catastrophic failure of a project.

And in case you think Linux based OS are somehow immune, I point you to Metasploitt that has 464 active exploits for Linux or all the malicious apps that show up in the Snap store on a regular basis.

It isn't immune but it is inherently less vulnerable than Windows. I've witnessed malware on a Linux server before; I know it's legit. If you're really that appalled by the security vulnerability of a first release of a major DE update, then don't use it. That's like buying a Smart Car and complaining about the potential of losing your legs if you get into a head-on collision at highway speeds.

People apologizing for KDE does not change the fact that this is a huge issue.

It's not a huge issue. It's to be expected. Just wait for a few more releases if you care that much.

[danilw]

Modern C++ is definitely safer than old school C++ so that can help, but it still doesn't come close to Rust

If context is another C++ vs Rust...

Modern project is:
1. use multithreading
2. use multithreading for network
3. use multithreading to load/save files
4. use GPU to render even UI
5. use USB and/or other devices.
6. use million libraries

Does Rust protect from multithreading your logic bugs - no.
Does Rust protect from multithreading bugs with network - no.
Does Rust protect from multithreading file read/write bugs - no.
Does Rust have any protection against GPU-bugs - no.
Does Rust have any protection against device-communication bugs - no.
And it insanely painful to use external libraries that you do need for every project, you will no reimplement hundred of thousand lines logic from some library in Rust.

[mdedetrich]

Does Rust protect from multithreading your logic bugs - no.
Does Rust protect from multithreading bugs with network - no.

Uh yes it does? I mean it prevents multiple access to the same areas of memory by different threads, and also same resources such as networking. Its not going to solve all logic bugs, but if have a bug regarding multiple thread access it will

Does Rust protect from multithreading file read/write bugs - no.

Yes it does, look at ripgrep code

I mean this is solvable with a few minutes of googling, have a read of https://kerkour.com/multithreading-in-rust

Does Rust have any protection against GPU-bugs - no.
Does Rust have any protection against device-communication bugs - no.

This is yes and no because it depends on how much of the logic is implemented in drivers and how much is done in Rust. On Rust's side it most definitely can prevent these issues but if there is an issue in driver then obviously it cannot do anything about it

And it insanely painful to use external libraries that you do need for every project, you will no reimplement hundred of thousand lines logic from some library in Rust.

Sorry to break your bubble but this is already happening, people are re-implementing these libraries in Rust as we speak.

[anda_skoa]

The only thing I think that would drastic effect of improvement quality of KDE software without requiring ridiculous resources is using more typesafe languages like Rust, its not going to make the unknowns safer but it will make the knowns much safer which makes it easier to identify where underlying issues are. This is going to be a hard sell however given that KDE is literally tied to the Qt framework which is written in C++

It is possible to write programs that use Qt but for which the application logic is written in Rust: https://github.com/KDAB/cxx-qt

and actually has a custom compiler with moc

That is a common misunderstanding and also a bit understandable given the tool's name.

However it is not a compiler but a code generator.
Its output is normal C++ code and compiled by the developer's C++ compiler with the rest of the project's C++ files.

Quite similar to how protoc generates code for protobuf messages and gprc interfaces, or how various tools generate code for D-Bus interfaces.

In all these cases they take tedious and repetitive task of the developer's hands.
Not necessary but highly value in both developer productivity as well as correctness of the output.

[mdedetrich]

It is possible to write programs that use Qt but for which the application logic is written in Rust: https://github.com/KDAB/cxx-qt

Nice but I am more talking about the core Qt framework being in C++, although this is definitely helpful for end user applications

That is a common misunderstanding and also a bit understandable given the tool's name.

However it is not a compiler but a code generator.
Its output is normal C++ code and compiled by the developer's C++ compiler with the rest of the project's C++ files.

Well the difference between a code generator and a compiler can be a bit bening (i.e. is typescript a compiler or code generator even though its target is javascript?)

Quite similar to how protoc generates code for protobuf messages and gprc interfaces, or how various tools generate code for D-Bus interfaces.

I don't think that protobuf/grpc are the best example because this is talking about message serialization which is a lot more clear cut

In all these cases they take tedious and repetitive task of the developer's hands.
Not necessary but highly value in both developer productivity as well as correctness of the output.

Oh yes, but iirc (this was over 10 years ago) moc did a lot more than just trivial boilerplate, it did actually have some logic in there hence the bluriness between compiler/code generator.

But in any case the distinction is largely irrelevant here

[sophisticles]

That is very convenient for you, isn't it?

You propose a lofty plan and then claim it is impossible to execute when challenged to do it.

Well, if you'd be doing what you've been proposing then it would also be your software.

But is seems you are trying to avoid to "own up" and taking responsibility at all cost.

Have you never read anything i have posted?

I don't working for free, if you want me to fix something you have to pay me a fair market wage.

The current state of KDE, Gnome and the rest, is a glowing example of the quality of programmers that you get when your project depends solely on volunteers.

If you look at the Linux kernel, it is in much better shape in large part because the top code guy, Linus, is a guy with a Masters Degree in Computer Science and is compensated 1.7 million dollars a year to work on the kernel.

If KDE or Gnome had a central person with a Master Degree in Computer Science that earned 1.7 million a year and was responsible for maintaining the code base, then they would be fantastic desktop environments.

Being open source is not what makes the Linux kernel what it is, what makes it a top notch kernel is that you have one highly educated figure that controls al code submissions and has final says in what does and does not get in.

What KDE has is a bunch of volunteers, with questionable coding skills, and apparently an include everything and the kitchen sink code acceptance policy.

Lastly, there is zero benefit for me to fork the project because all the fixes to the GPL software also have to be GPL, I wouldn't own a thing.

If they re-license it under an MIT license, I'll fork it and show them how it's done, of course the source will be closed and the DE will be a commercial only product.

[sophisticles]

It is understandable that you find two different numbers of the same thing confusing, but this is based on a misinterpretation of what Nate had written.

The number 24 000 is across the whole range of KDE's products.

4000 of which are associated with Plasma, the KDE DE product.
Given that it has to deal with system differences in a much wider scope than most other products it is likely the largest per product count.

Thanks, even though my tiny little brain understood the distinction, i still appreciate the fact that you needed to exercise your fingers a bit.

[sophisticles]

Releasing binaries is quite a recent thing.

For many years they just released source archives but supporting platforms like Windows or mobile operating systems requires releasing respective binaries.

No need to wait for Plasma 7.

KDE Neon has existed for a couple of years now. It is one of the reasons Plasma 6.0 got such a wide up-take within days after release.

Why would KDE want to severely limit its user base?

If a software distribution provider wants to put in the effort of making KDE software available to their clients then KDE is happy to reach more users.

Quite a number of them are even contributing resources in one form or another.

Way to cherry pick quotes.

Reread my statement in context of the whole post.