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.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 -- Rok Garbas - http://www.garbas.si
signature.asc
Description: signature
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev