3 ms·
KDE 4 had, for a long time, a misfeature relating to pthread_mutex_t support on OpenBSD (which was my fault, I suppose). A couple of years later I heard from a
by mpyne 14y ago
KDE 4 had, for a long time, a misfeature relating to pthread_mutex_t support on OpenBSD (which was my fault, I suppose).
A couple of years later I heard from an OpenBSD dev who noted the issue and recommended a workaround, which I implemented and hopefully means KDE works in OpenBSD now.
But other than that one dev I'm not aware of any OpenBSD users or devs noticing or complaining about that bug (which would have been quite noticeable from the terminal output at least).
Drawn whatever conclusions you will from that. ;)
- tobiasu 14y agoMy conclusion: Your typical KDE user is not in the position to do the non-trivial work of porting a large C++ code base. Nor does she know where to get started. Such bloatware needs at least one dedicated and interested developer on each target OS. We now have one, so there is quite some movement on this front in the recent months.
- mpyne 14y ago> Such bloatware needs at least one dedicated and interested developer on each target OS. That's correct. Although I'm one of the few who actually seems to care about portability as a good practice I don't have the time to run 5 different OS'es to verify each of my volunteered contributions works on every feasible POSIX platform. In the end someone who is interested in each of those platforms needs to help take on the task of ensuring that the software they use works on the platform they use (that is, if they wish for the software to work). This can be as simple as reporting bugs, helping with integration into platform-specific libraries (which KDE is usually very good about using through adapter libraries to ensure portability), reporting platform-specific bugs that need worked around, etc. Some projects are already taking a WONTFIX attitude to portability bugs. I will push where I can to make sure that KDE isn't one of them, but I can't change the number of hours in a day... non-Linux developers need to contribute too if they want a great KDE on that platform.
- papsosouid 14y agoIt is incredibly easy to have a buildfarm (entirely made up of virtual machines even) that can build and test your software across dozens of operating systems. When I install a large software package like KDE, and see that there are glaringly obvious bugs, I assume it is because the developers do not care enough to do the most trivial automated testing. So I simply uninstall it and use software that works. When you create an impression of "we don't care about you", people are much less likely to bother reporting issues.
- mpyne 14y ago> So I simply uninstall it and use software that works. Which is convenient, as then I feel less guilty about the issues I don't have time to triage, less alone fix. You don't think I personally care if you use KDE or not I hope... I contribute where I can, as time becomes available. If people find that useful, that's wonderful. If people don't find that useful, that's fine too. I've heard from many people who have found useful those things I've found time to implement, so I'll keep plugging along for now. As it turns out though, there actually is a build farm/continuous integration infrastructure that our wonderful sysadmins have setup for KDE by now: http://build.kde.org/ http://build.kde.org/ But CI isn't useful unless it results in actionable information, and it still requires developer action to make the fixes. We're accepting patches...
- papsosouid 14y agoYou seem to be confused. I was explaining why you don't see many bug reports, not threatening you with my not using KDE. I haven't tried KDE in like 12 years, it was just a general statement, not a comment on KDE specifically.
- mpyne 14y agoNo... we see tons of bug reports. Just not from OpenBSD users. If you're saying OpenBSD users are in general pickier about what software they install based on what practices are used to develop that software I'd certainly believe it. I've certainly done no studies myself to figure out why there are so few bug reports so I can't say any one reason is better than another.