Guillaume:
I was preparing to send a note saying the same thing that Neal has said,
but he has probably written better than I could. Instead, let me offer
some thoughts that are more concrete:
There are many places in your notes where you write things like "X is
the solution", where X is some popular or interesting technical idea
(e.g. SASOS). In response to a statement of this form, a good architect
should always respond:
Perhaps, but the solution to *what*? What are the overall design
objectives that you are trying to achieve, how does X relate
to (support or interfere with) those objectives, and is X in fact
the best way to achieve those goals given what we know about the
alternative design options that are available to us.
The same response would apply to some of your posts on the BitC list.
We need to test your ideas against the metric I have given. Good design
is really hard, so this may be a discouraging process. Good designers
often have large investments in their ideas, so this discussions can
become quite heated at times.
On the other hand, it is *great* that you have many ideas to test! Be
patient, gentle, and persistent! [A combination, by the way, that I am
bad at sometimes.]
A starting point:
In all of the lists where you are active, you should ask the
participants to tell you what the design goals are. Given a more
complete sense of what the project is trying to achieve, you will have a
better sense of:
1) Which things you know about are actually relevant.
2) Which things the project community already knows about, and
may have already considered.
3) How to help that community build value more effectively.
shap
On Mon, 2006-08-07 at 14:58 +0200, Neal H. Walfield wrote:
Guillaume,
You seem to have studied a lot of non-mainstream techniques and want
to make use of them. I think it great that there are people looking
to take more of the results of the research community and attempting
to integrate them into real systems (which is not actually part of a
researcher's job).
I think that so far, your ideas have been, however, too broad: first,
what exactly are the problems you are trying to solve? You say on the
one hand security and performance. I agree that these are important.
On the other hand, you completely devalue legacy support. I think
this is the hardest problem and central to the adoption of new
systems.
In short, I think you need to define some goals, consider their
implications (in particular, what things are less important) and then
think about how these new techniques that you've pointed to will
facilitate those goals. Marcus and I have been doing this for some
time and have found that this articulation process it quite hard yet
rewarding in the insights that it brings.
Good luck,
Neal
_______________________________________________
L4-hurd mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/l4-hurd