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 <r...@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.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 > > _______________________________________________ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > >
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev