Dear <person smarter on Nix than me>, It seems to me that the version 1.10 of Nix package manager does not allow the local repository of packages to be anywhere else than the
/nix/<some subfolder> The configure script parameter --with-store-dir did not have any effect on the <nix installation home>/etc/profile.d/nix.sh The question is, is it a bug or if it is intended to be that way, then why the option to install the storage repository to $HOME/<something optional>/nix was disqualified from single user use case? The requirement to have root access for creating the /nix does not allow the Nix package manager to be used as a dependency of an applications software. In the role of the dependency the Nix would be automatically compiled and populated as a subtask of the build script. After setup the Nix would manage the packages for that, specific, applications software. The beauty of it would be that it would all be automatic, no manual fiddling with any OS level setup. The use of an application specific Nix repository instance would be a fail-safe mechanism that is used after the checks have determined that the global version of Nix repository is not available. The point here is deployment reliability. Not every small business can afford to have a professional networks administrator fiddle with the software for hours. The extra time and network traffic and disk space, CPU-s and RAM that is used due to the use of private Nix repository instances is cheaper than the human labor. (To put it bluntly: nobody likes slow and bloated software, but we still do not write in assembler, because the hardware is cheaper than human labor.) Besides, one of the main sales arguments for the cursed Java is that its applications are "cheap" to deploy. The background is that for reliability reasons it makes sense to deliver applications software for small businesses not just on a USB stick, but small businesses should be able to install Raspberry Pi like small computers to their LAN. That way they can replace their laptops, desktops, whatever else without having any effect on the availability of their business critical software. In theory there are various "cloud options", including the various Raspberry Pi co-location options and alike, but IN PRACTICE the issue with the cloud is that its reliability becomes really shoddy due to the various censorship issues. For example, GitHub has been blocked in China and in Russia, tor daemons are censored by most cloud operators, there is the net neutrality issue with the various Internet Service Providers. The Estonian community bared even a cyper attack, when all major banks and vital services went down and people could literally not buy food from food stores due to the fact that people do not use cache that much any more https://en.wikipedia.org/wiki/2007_cyberattacks_on_Estonia not to mention the lessons learned from the Soviet era. So, currently, my recommendation is to use multiple Raspberry Pi-s that serve their services over Tor from multiple physical locations and the software architecture would have to be built from ground up with an assumption that in stead of a single domain, single server, there are multiple servers that mirror each other and the mirrors are not the same, the mirrors are out of sync. An applications software would pick one of the mirrors to be the prime mirror and the application would write to the rest of the mirrors in a background thread. The mirrors would also sync themselves, but they probably have "enough" to "talk" about, so the applications just speed up the syncing a little bit. For the end user there would be no difference between the current, single-public-internet-domain systems and the new, improved version. The end users would just have one Raspberry Pi at their LAN running a special proxy server that maintains the relationships between the various server addresses, which can be Tor network domains, GNUnet network domains, Freenet domains, and the LAN URL of the web application address. >From business perspective, that's the most reliable and cost effective solution that I am currently able to come up with. The role of the Nix package manager would be to simplify applications development and deployment. Hence the requirement that the /nix should not be the only location for storing packages. Regards, martin.v...@softf1.com P.S. wget from Tor network URL-s can be used by executing torsocks wget theTorNetworksite.onion/something _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev