[Nix-dev] A Question About Nix Local Storage Path

[Martin Vahi]

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.Vahi at softf1.com

P.S. wget from Tor network URL-s can be used by executing
    torsocks wget theTorNetworksite.onion/something