On 5/5/12 16:43 , Jérôme Benoit wrote: 
On Sat, 05 May 2012 12:22:15 +0200
Philip Homburg <philip.homburg@ripe.net> wrote:


I don't know about SamKnows, but for RIPE Atlas, talks contain a lot
of details about how the system works. To the extent that there is a
well defined road map, we talk about it.

I'm having hard time to find the roadmap and the talks on the RIPE Atlas
web site as a public user with no account. But I might have not
searched enough. Where are they ?
There is not a single comprehensive road map. What is there, is just bits and pieces. Most of it was discussed during the most recent RIPE meeting. The talks by Robert and Daniel should be online.

To list some things that have been mentioned:

      

        
As much as I like open source projects, I really don't see it working 
for the current Atlas system.


      

      
It work very well, we do it since age but we took a very different
approach : 

The measurement agent is designed as a standalone component with that
requirement : 

* Must be portable, that mean all measurements must be implemented
  natively.   
* Datagram-based measurement are divided in four components
    - packets forge 
    - packets injection
    - packets capture
    - packets filter 
Each component work is mapped to a dedicated thread (an Lwt job more
precisely, which bring in a very nice way to manipulate packets in a
asynchronous fashion). 

    

    Note that for Atlas, it has to work on an underpowered CPU without
    MMU and with 8 MB of memory. 

    

      
* Other measurement can be mapped with a plugin dynamically loaded (the
  API is not stable yet)
* A syntax (that is not yet finished) permit to express what a
  measurement will do. The syntax is thought as a way to express
  what the software functionalities are and how each component
  interact with each other. I give a working example just to show
  the idea : 

    

    

    However, I think this would be a great area the community can work
    on. Plenty of people has expressed interest in something more
    general than what is currently implemented in Atlas.

    

    So if people can come up with a design that is both secure and can
    work on 8 MB probes, then maybe that can be used to create a common
    interface to the different measurement platforms.

    

      

      

        
Probe are just too fragile, the whole 
system is too complex.


      

      
? 

I fail to understand this argument. 
Every single piece of software is a complex system, that has never ever
be an argument to not opensource it. 
And for the fragility, probably a design issue of the probe (but I
can't known for sure, no source code to review). 

    

    

    Running an open source project is not a goal of the RIPE NCC. If
    that's supposed to be a goal then the members will have to ask for
    it through the appropriate channels. 

    

      

      

        
 Does releasing the Atlas source benefit the
RIPE community? I don't know. Fortunately, that is not my decision to
make.


      

      
RIPE call. I think RIPE have made a mistake by not going opensource
since the beginning. 

    

    I guess opinions differ there.

    


      

        
If you have a dedicated team in an open
source project, then you should be able to duplicate our work. You
can always for feedback on any design, or ask how we do things.


      

      
I do not know the list of active measurements an Atlas probe cover. 



    

    At the moment, ping, traceroute, tdig (dns), httpget, sslgetcert.