Just from the ars article alone I have extreme doubt of what the phone system(AOSP copy job) on release is the same as the code in open harmony repos

- app that is binary , so you can't build it from source, but is using dynamic libraries, then you can use autoPatchelfHook to tell nix to patch the binary to swap out the libraries to nix's version

- app that uses a lot of hard coded file system path that you would prefer not to patch them all out, then you can use buildFHSUserEnv to package/run the application/package in full FHS-compatible scenario

but the main point is that, nix is extreme in its approach, and the best approach in my opinion, is to do swapping step by step, ex:

you want to convert a existing project to nix, lets say nodejs

- you add the main deps in the default.nix (nodejs, yarn, high level utility needed to build)

- use sandBox false to allow building the app with yarn/npm in internet accessible(by default nix uses sandBox which disallow internet inside build step, which causes issue like npm install not working, etc)

- confirm working, then start using tool likes yarn2nix, other similar, and convert the packages itself to a usable set of nix packages

though I do agree that nix have the knowledge bias issue, and alot of my learning of nix involve me looking at the nixpkg sources itself and sometime even the nix's code

Comments URL: https://news.ycombinator.com/item?id=18741677

Points: 2

# Comments: 0

A portion on the issues is arguing whether should this kind of repo use Github as the discussions platform

Comments URL: https://news.ycombinator.com/item?id=16923598

Points: 3

# Comments: 3

  data "template_file" "eth_service" {
    	filename = "./files/eth.service"
  	vars {
  		wallet_address = 
  "${var.wallet_address}"
  	}
  
  }

ExecStart=/tmp/ethminer -G -F eth-us.dwarfpool.com:80/${wallet_address}