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

Sat Nov 7 11:15:33 CET 2015

Also see
https://nixos.org/wiki/How_to_install_nix_in_home_%28on_another_distribution%29

On Sat, Nov 7, 2015 at 11:13 AM, Rok Garbas <rok at garbas.si> wrote:

> hi martin,
>
> this works for me to build everything under different nix prefix, eg.
> /opt/foo
>
>
> NIX_PREFIX=/opt/foo \
>     NIX_STORE_DIR=$NIX_PREFIX/store \
>     NIX_STATE_DIR=$NIX_PREFIX/var/nix \
>     NIX_DB_DIR=$NIX_PREFIX/var/nix/db \
>         nix-build release.nix
>
> still you need to know in advance the location you want to install to.
> hope this helps
>
> Quoting Martin Vahi (2015-11-07 04:34:22)
> >
> > 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
> >
> >
> > _______________________________________________
> > nix-dev mailing list
> > nix-dev at lists.science.uu.nl
> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
> --
> Rok Garbas - http://www.garbas.si
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20151107/cab2525e/attachment-0001.html 