As from 2 days ago we have the following Rock-on availability changes:
- 3 Additions
New rock-ons
-
Folding@home Linuxserver.io (Github link) I am delighted to have added this particularly pertinent and most welcome addition to our growing catalog. This projects, by default, allows folks to donate a portion of their systems processing power towards ‘Any disease’ - which as one might imagine now prioritises ‘you know what’. If your Rockstor system can spare it I would encourage you to consider this most welcome addition. This is currently a CPU only implementation but few NAS arrangements have GPU anyway and there are ‘pertinent’ CPU ‘work units’ available as of writing.
-
PostgreSQL 9.5 (Github link) Thanks to forum member @Hooverdan for this polished addition prepared in response to a forum discussion by @AudioDan24 as their project at the time was hosting a database for DaVinci Resolve. This is somewhat new ground for Rockstor as this one has no Web-UI. We do have ‘in the works’ capabilities developed by the venerable @Flox to cater for less ‘all in one’ more idealised containers such as this, i.e. single service units, but this work is, alas, not our current priority. But we are aiming to be able to setup private networks between Rock-ons to allow for more idealised single service Rock-ons such as this. All in good time however and as always, bit by bit.
-
PostgreSQL 10.6 (Github link) Thanks to Github user holmesb for there patience and persistence in proposing and pruning another specifically versioned Postges Database Management System (DBMS), which was actually the basis for our above 9.5 addition. It would seem that many services expect particular versions of these cornerstone server systems and so we now have two key versions available.
Here we see a potential flaw / short-coming in our not currently exposing the capability to select specific versions of such servers as PostgreSQL, it’s not always that straight forward however, as folks may expect to re-use an existing config and simply re-install their Rock-on with a different tag and the same share, but if we indicate those Rock-ons that would suffer form such sensitivities we may in the future be able to have a one size (Rock-on) that fits all available ‘tags’ for the given image. @Hooverdan and @Flox have begun this ‘journey of discovery’ on how we can maintain our ease of use and not have an ever growing list of PostgreSQL Rock-ons or the like, see Github issue #218 by @Hooverdan for the first step in this journey.