* Alexander Graf <agraf@xxxxxxx> wrote: > > Furthermore, another negative effect is that many times features are > > implemented not in their technically best way, but in a way to keep them > > local to the project that originates them. This is done to keep deployment > > latencies and general contribution overhead down to a minimum. The moment > > you have to work with yet another project, the overhead adds up. > > I disagree there. Keeping things local and self-contained has been the UNIX > secret. It works really well as long as the boundaries are well defined. The 'UNIX secret' works for text driven pipelined commands where we are essentially programming via narrow ASCII input of mathematical logic. It doesnt work for a GUI that is a 2D/3D environment of millions of pixels, shaped by human visual perception of prettiness, familiarity and efficiency. > The problem we're facing is that we're simply lacking an active GUI / > desktop user development community. We have desktop users, but nobody feels > like tackling the issue of doing a great GUI project while talking to > qemu-devel about his needs. Have you made thoughts about why that might be so? I think it's because of what i outlined above - that you are trying to apply the "UNIX secret" to GUIs - and that is a mistake. A good GUI is almost at the _exact opposite spectrum_ of good command-line tool: tightly integrated, with 'layering violations' designed into it all over the place: look i can paste the text from an editor straight into a firefox form. I didnt go through any hiearchy of layers, i just took the shortest path between the apps! In other words: in a GUI the output controls the design, for command-line tools the design controls the output. It is no wonder Unix always had its problems with creating good GUIs that are efficient to humans. A good GUI works like the human brain, and the human brain does not mind 'layering violations' when that gets it a more efficient result. > > So developers rather go for the quicker (yet inferior) hack within the > > sub-project they have best access to. > > Well - not necessarily hacks. It's more about project boundaries. Nothing is > bad about that. You wouldn't want "ls" implemented in the Linux kernel > either, right? :-) I guess you are talking to the wrong person as i actually have implemented ls functionality in the kernel, using async IO concepts and extreme threading ;-) It was a bit crazy, but was also the fastest FTP server ever running on this planet. Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
