-\section faq_stupid Stupid Questions
-
-\subsection faq_GridSim Are SimGrid and GridSim the same ?
-
-Are you kidding ? SimGrid is plain C and GridSim is written in
-Java... I'm sarcastic but I'm pissed of all these poeple arguing that
-their software is well-structured and higly portable thanks to Java. A
-C program can also be structured in an object-oriented way and be
-highly portable (just try to run Java on IRIX... ;).
-
-According to different published papers, both SimGrid and GridSim seem
-to have the same kind of goal but I have never succeeded in compiling
-GridSim (but I may not be very objective since I always have troubles
-when trying to run java programs) and its documentation has not
-enlightened me. If you have suceeded and can tell me more about it,
-please tell me.
-
-\subsection faq_stupid_MSG What is MSG and why do you like it ?
+\section faq_SG Where has SG disappeared ?!?
+
+OK, it's time to explain what's happening to the SimGrid project. Let's
+start with a little bit of history.
+
+* Historically, SimGrid was a low-level toolkit for scheduling with
+classical models such as DAGs. That was SimGrid v.1.* aka SG, written by
+Henri Casanova. I had been using it in its earliest versions during an
+internship at UCSD.
+
+Then we have realized that encoding distributed algorithm in SG was a
+real pain.
+
+* So we have built MSG on top of SG and have released SimGrid v.2.*. MSG
+offered a very basic API to encode a distributed application easily.
+However encoding MSG on top of SG was not really convenient and did not
+use the DAG part since the control of the task synchronization was done
+on top of MSG and no more in SG. We have been playing a little bit with
+MSG. We have realized that:
+
+ \li 1) the platform modeling was quite flexible and could be "almost"
+ automated (e.g. using random generator and post-annotations);
+
+ \li 2) SG was the bottleneck because of the way we were using
+ it. We needed to simulate concurrent transfers, complex load
+ sharing mechanisms. Many optimizations (e.g. trace integration)
+ were totally inefficient when combined with MSG and made extending SG
+ to implement new sharing policies, parallel tasks models, or failures
+ (many people were asking for these kind of features) a real pain;
+
+ \li 3) the application modeling was not really easy. Even though the
+ application modeling depends on people's applications, we thought
+ we could improve things here. One of our target here was realistic
+distributed applications ranging from computer sensor networks like
+the NWS to peer-to-peer applications;
+
+* So we have been planning mainly two things for SimGrid 3:
+
+ \li 1) I have proposed to get rid of SG and to re-implement a new kernel
+ that would be faster and more flexible. That is what I did in the
+end of 2004: SURF. SURF is based on a fast max-min linear solver
+using O(1) data-structures. I have quickly replaced SG by SURF in
+MSG and the result has been that on the MSG example, the new
+version was more than 10 times faster while we had gain a lot of
+flexibility. I think I could still easily make MSG faster but I
+have to work on MSG now (e.g. using some of the O(1)
+data-structures I've been using to build SURF) since it has become
+the bottleneck. Some MSG functions have been removed from the API
+but they were mainly intended to build the platform by hand (they
+had appeared in the earliest versions of MSG) and were therefore
+not useful anymore since we are providing a complete mechanism to
+automatically build the platform and deploy the agents on it.;
+
+ \li 2) GRAS is a new project Martin and I have come up with. The idea is
+to have a programming environment that let you program real
+distributed applications while letting you the ability to run it in
+the simulator without having to change the slightest line of your
+code. From the simulation point of view, GRAS performs the
+application modeling automatically... Up until now, GRAS works on
+top MSG for historical reasons but I'm going to make it work
+directly on top of SURF so that it can use all the flex and the
+speed provided by SURF.
+
+Those two things are working, but we want to make everything as clean as
+possible before releasing SimGrid v.3.
+
+So what about those nice DAGs we used to have in SimGrid v.1. ? They're not
+anymore in SimGrid v.3. Let me recall you the way SimGrid 3 is organized:
