All of you who follow my blog for a medium to long time knows that I often take a look to minor issues. These are issues that have no direct impact on users. Summing them up, though, can easily give you big issues that do have a direct impact on users.
Take my crusade about copy-on-write pages. They don’t really make any difference taken one by one, but sum them up in a system, and it might as well make a huge difference.
It’s similar to the issue with wakeups that Intel brought on the table. It does not make much difference on its own for a single software, but add all of them together and you have a huge difference.
I wonder if we’ll ever get to a point where all these issues are well known by all the free software developers, and that just the new started projects need to be profiled to identify these issues. Unfortunately, I’m afraid this is not going to happen anytime soon. But it would be really interesting if common projects like Samba and Xorg started paying more attention to those issues.
I wonder what’s the best option to improve the situation. I actually thought about starting a Wiki listing all the problems if the apps, and then attaching patches for possible resolutions. I would hate to load a Wiki up on my blog though. As an option, I was thinking about using GIT and Emacs’s Muse, rebuilding the pages statically after every commit. Then it would also be possible to add stuff like graphs and similar to show the reduction in memory usage, or startup time, or whatever, which would then allow showing more easily what the changes improved.
I think solar was right in suggesting me to have more visual output of the changes. I’ve installed R yesterday, and I hope to be able to try learning how to use it soon, so that I can propose some graphs.
Anyway, any comment on this is very welcome, as I start to be quite tired to fight these issues alone, and having almost no feedback from upstream.
You could try collapsing down the misc issues you’ve pointed out in your blog into a set of docs- I strongly suspect this would be a rather useful resource while being easier to use then randomly flipping through your blog.Regarding getting to the point where “all these issues are known by FOSS devs”, willing to bet that’s an experience thing- folks should think about making their code performant (both mem/cpu), but there really isn’t any docs I’ve personally seen for profiling/making your codebase into a “good neighbor” in terms of wakeups/visibility/memory- what I know I’ve had to figure out myself via rooting around.Compressing your blog down (with backrefs and graphs of the gains) would definitely be a useful resource for people to flip through and try to deal with the issues themselves- might sound insane, but the hacking document for pkgcore tries to serve a similar (albeit python specific) goal. Said document I’ve had decent feedback from folk regarding- lot of the comments have been along the lines of “didn’t know about that, do now, thus doing the better route now”.
I think Ferringb hits the nail on its head. I think that providing good docs explaining the problems and how to solve them is way more useful than creating a site “blaming” devs from package x that they did not fix problem y (that they don’t see as a problem).To add: Even though I have a decent technical background I find it often difficult to “see” how relevant the points are that you raise. Besides working on representing things graphical you might also think about finding good examples that illustrate the problem clearly to somebody with less knowledge to motivate them to actually try to understand what you write.ps) It might be that good docs make it easier for others to stand up and help you as well.
As an OSS developer myself, I try to search google for “X best practices” when I use something new that I don’t know much about. Recently, it was DBus. There were no good docs explaining the common mistakes, but I pieced together enough information from various sources to make it all work.I’d recommend good docs as a solution, they are what help me the most. I’ve been trying to lower COW pages in the application I maintain because of these blog posts. The problem I had was that I didn’t <emph>know</emph> about the issue.Same thing for using the autotools properly. I haven’t found a really good doc on the subject yet. I’ve done what I think is correct by looking at others’ code, but I don’t have a good idea why I do X in one situation, and Y in another.I am always willing to proofread docs. I’m willing to learn a topic to help write better docs.Oh, and another thing that would help is this: provide some measurement of the problem. Graphs help a LOT. A way to measure the difference in a compiled (or running) binary would be even better. One you enable easy measurement, it is much simpler to fix the problems. This happened in the Linux Kernel with PowerTop and wakeups. As soon as there was a good measurement tool (PowerTop) the problem was solved pretty quickly (less wakeups).
Dawned on me what you’re trying to target is “death by a thousand cuts” btw- better phrasing then “many minor issues like a big issue”, plus it’s got that lovely pr angle needed 😉