On Wednesday 30 October 2002 05:06, Donavan Pantke wrote:
You know, has anyone ever actually done a ps -auxf or similar, and see if these other windows are, in fact, child processes from the main one that got started? That could easily explain the problem: copy-paste would only work between members of the process group.
I knew there must be correct terms for this. You fit the explanation in one sentence. It is easy to notice that a large number of problems users experience are described, and often solved, in this sort of empirical manner. I wonder sometimes if people who program for Linux/KDE actually understand what's being discussed. I'd venture to say that much of the linux user angst is created by users' inability to integrate their empirical knowledge. I've been using linux since SuSE 5-something, 5.3 I think. I've learned a lot. But without a proper framework it all looks just a collection of ad hoc pieces of information. Many people say that linux should win desktop from the other os, and this would become possible when users would not need to know what child processes are. Maybe one day it will happen. But as it is, linux is used, managed and advocated by people who are commonly referred to as "geeks". Geeks may share the belief that linux is the best and willing to spend a lot of time tinkering with it, but not all of them went to programming college or professionally wrote in C for many years. Many users actually seem to be ashamed of demanding certain features/fixes for themeselves, they demand it on behalf of joe sixpack or business production environment. I think this often happens because of lack of knowledge. Now look at this again: "copy-paste would only work between members of the process group". It already looks a fraction of a problem it seemed to be. This may be turned into a meaningful bug report or a feature request. Or, it can safely be lived with. In short, I think SuSE should put more effort at consolidating their geeky consumer base, in particular, providing more abstract, theoretical info on how things work. How do you call what. How it all is woven together. How to investigate a bug and submit a comprehensive bug report. What can developers do for you and what they can't. As it is, most documentation deals with how to set up and use the various system components. But it provides very little in the way of background necessary to, for example, talk to developers without blushing. An amaising feature of linux is that the developers are at arm's lenth - you can report a bug, see it getting fixed, and the fix find its way back to your computer. What commercial software development houses can boast such incredible flexibility and pace? Yet, this resource is incredibly underused because users don't know how to articulate various problems they are experiencing. Regards, Serguei