[atlas] Encouraging people to upgrade software probe versions

Hi,

To me it seems that there are oh-so-many ways of packaging and 
distributing this software to the match the multitude of needs (RPMs, 
DEBs, openwrt, docker, VMs, ...) and us giving support to multitude of 
these stretches our resources thin. As I wrote before, such packaging 
would be preferably achieved via professional maintainers.

 > Is there an actual reason, why it was decided to let users manage the
 > software probe installation?

The intention here is/was that many users already have their own machine 
(VM or server or home router or such) that can be used as the platform. 
One can also easily spin up and dedicate a new HW, like a lingering 
Raspberry Pi, to this.

Cheers,
Robert


On 2023-01-27 10:43, Simon Brandt via ripe-atlas wrote:
> Hi Robert,
> 
> The existence of software probes is great, but instead (or besides) of 
> providing packages or source code, why not distribute a prebuild VM as 
> OVF file?
> 
> Advantages:
> - The RIPE Atlas team manages the whole OS, like it's doing for the 
> hardware probes. Thus, updates can be deployed whenever needed.
> - You can even use OpenWRT as VM operatingsystem. This means all the 
> same premises/conditions as for hardware probes.
> - an OVF file is easier to deploy, for the community
> - RXTXRPT switch is obsolete
> - No more false RXTXRPT data, since the report counts all traffic of the 
> host, not only the traffic that is generated by the SW probe application.
> 
> Is there an actual reason, why it was decided to let users manage the 
> software probe installation?
> Please consider to distribute a prebuild VM *additionally* to the 
> existing ways and see what happens. I'm sure, most new users will choose 
> a prebuild VM.
> 
> 
> BR,
> Simon
> 
> 
> On 19.01.23 12:48, Robert Kisteleki wrote:
>>
>> That is reasonable; the difference is that we are not in control; the 
>> host OS is. Redhat/Fedora/derivatives as well as Debian/derivatives 
>> have an official solution to this via their package management 
>> services and I believe this is the standard way (surely with 
>> exceptions :-) ) of handling these matters. We are in the process of 
>> adopting these.
>>
> 
>