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

[Rok Garbas]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20151107/932ceee7/attachment.bin