A few days ago I posted an article about Ninite, a software installation service that helps install multiple applications and repositories – especially handy if you’ve just done a fresh install.

In the article I mentioned that:

  • Ninite didn’t work for me
  • and Ninite sent some system information back to their servers.

Since then, I’ve been chatting with Patrick Swieskowski, Ninite’s co-founder, who wanted to clear up some facts.

In the post I mentioned that Ninite ran a script that “reports your kernel version and Ubuntu release” to Ninite – this isn’t entirely true as Patrick explained. While there is a script in the .deb you download from Ninite, and it does send information home, it doesn’t send you kernel version but rather your architecture (32 bit / 64 bit) and Ubuntu version.

“The architecture plus the Ubuntu version is sent back with success/failure status of each app so we can improve the installer. The machine architecture and Ubuntu version are sent in the User-Agent header to _every website you visit_ and we already know what apps you picked since we made the installer for you.  The only added information in that report is whether things worked.”

Patrick also wanted to explain how the script actually works:

“[The generated .deb] just adds the right repositories and keys, runs apt-get, and then kicks off report.py to let us know if something breaks.  There’s really no “mystery that is Ninite,” everything we do is right there if you open it up.  See the ninite.sh file in the .deb.”

Lastly, Patrick said that they’ve mainly been testing with gDebi – which is perhaps why Ninite didn’t work for me when I opened up with the Software Center on Ubuntu 10.10.

I hope this clears up some of the details about how Ninite works and what information it sends back, and why. By all means, go and check it out and test it – I’m sure Patrick and the gang would love to hear further feedback.

ninite