RuckZuck.exe was downloaded 15'629 times in 2019 from https://github.com/rzander/ruckzuck. In 2018 it was 10'926, a light grow, but these numbers depends on the number of published releases ( we had 11 Releases in 2019 ).
An interesting number is the total downloads from GitHub in 2019: 200'293 downloads !!!
It seems that RuckZuck.exe no not the most popular File, it's the RuckZuck Provider for OneGet (179'295 downloads). The OneGet Provider is part of Device Commander, a cloud based client management solution, which indicates that RuckZuck is also used in Enterprise environments... and/or someone had a download loop as the high download numbers where only in Feb/March 2019..
The Repository includes 511 current Packages or 2'829 Packages, if we also count older Versions.
To evaluate product updates, there is a Mapping-Table with 65'957 Software-Items.
113'827 Software Packages where downloaded from RuckZuck. The Success/Failure ratio is weird as we had 161'151 Success and 117'770 Failures. Some Packages, like a Version of JavaRuntime, had 1'668 Downloads but 39'775 Failures. These numbers do not reflect the full Year as the RuckZuck Back-end was updated in July/August and I only have the numbers from the new Infrastructure...
Please: If you automate Software-Distribution with RuckZuck, keep an eye on your Success/Failure ratio and do not bomb RuckZuck with thousands of Requests... If a Package failed 10 times in series it will also fail the next 100 times...
Otherwise your IP can be blocked for a while.
Failures are important to identify broken links. Every failure will trigger an installation in a Sandbox to verify if it's a false positive or not. If you want to support this project by verifying failures, you can run a Test-Bot in a Win10 Sandbox
Since August 2019, 1'382 Packages where created. That's an average of ~9 Packages/Day... Thanks to all the contributors, who support this project by reporting Issues or creating Packages !!!
If I compare the usage of Packages, I can say that 20% of the Packages are used 80% of time... In other words, 80% of the work is only for 20% of the clients. As more and more enterprise customers are using RuckZuck it will become even more... I think 500 Packages in the Repository is manageable number, I do not have interests to have every little Software in this Repo. That's why I will also drop Products if there are not used...
The Infrastructure of RuckZuck has changed completely since 2018:
- Redis cache removed
- SQL removed
- no RuckZuck Account DB (..nothing can leak -> GDPR)
- Repository uploads are anonymous. You can enter your email address on the Author attribute if you want some feedback, but this Attribute is removed during approval.
- Azure Blob/Table storage for the Repository
- support for OnPrem RuckZuck Servers acting as Proxy and/or for local Repositories
- Content Delivery Network (CDN) for global caching of Metadata and..
- some Packages are already using RuckZuck CDN to distribute the binaries. Reasons can be:
- Vendor removed Product or Web-Site closed, but Product-Updates are still important
- Vendor Web Site has very poor performance
- Vendor does block non-interactive downloads but the license allows redistribution
- SignalR for real-time messages on the Web-Site (Service Bus is still there... )
- Azure Functions to side load some work
- Azure Log Analytics for monitoring
- Server REST API is now running on .NET Core 3.1 -> try the latest Docker Image if you want to cache the packages OnPrem..
Back-End activity example (one hour):
I've found two Sponsors to cover the costs for the Infrastructure. Thanks to itnetX and baseVISION to keep this thing running!
Let's look forward and see what happens in 2020 ....