biolizard89 wrote:
Reproducible builds are very important, and I don't think Joseph or I want the project to be completely dependent something that Tor devs were unable to do with several orders of magnitude more funding.
At this moment reproducible builds are of secondary priority. What is important is that we get out a working product.
hla wrote:phelix wrote:IMHO we should not discard all the work we have put into NMControl when we are just about to have a usable product. It simply does not make sense to restart now.
ncdns (which provides DNS resolution) works today. It is the only currently available implementation of domain-names.md, as far as I'm aware. So if we compare the completion of the two implementations, ncdns wins, unless I'm mistaken.
domain-names.md is not the benchmark. Is ncdns ready to be deployed as a product (on Windows)?
phelix wrote:Why not have a competing second program? I think Go is a very interesting language but I for myself would have to dig into Go first which would take time and effort I would rather spend on other things. If you and others think they can create something better than current NMControl it's fine with me. But we should let the users decide and not force a single "official" software on them.
Who's suggesting we do that?
Well, as far as I understand the still vague question at hand it is suggested to "switch" from NMControl to something new based on ncdns.
People can use what they like - but it doesn't make sense to divide the limited energies available between two middleware stacks within the context of the project.
It does not make sense to have all developers switch from one language to another in the middle of a project either. Particularly not so as most other code and scripts are in Python, too. This will forbid some synergy effects (we are only partially using so far) and will divide the team.
phelix wrote:Whereas Go might be easier to create reproducible builds it is possible to simply run the python source directly (e.g. with Bitmessage this is pretty common).
I believe the issue pertains to creating reproducible builds of the Python interpreter itself.
Huh? At some point you will need to have a compiler for Go, too.
DNSSEC is essential to allowing d/ names to securely delegate to nameservers, which is necessary for large zones.
Who cares about large zones?
Moreover, the issues with getting DNSSEC support into browsers are basically the same issues as getting Namecoin TLSA verification support into browsers. They are essentially the same problem.
For TLS support it is not necessary for the browser to support anything but a (socks) proxy.
As far as I see it the two main arguments for Go, reproducible builds and a DNSSEC library are void.
phelix wrote:biolizard89 wrote:in Python it is difficult to know which exceptions to catch.
I don't see how you could get around this in any language. It was never a problem for though.
If the fallibility of a given function is explicitly declared, callers know they need to handle any errors which it returns. Unlike Python, Go is statically typed and uses returned error values. Therefore, it can be determined from the documentation whether the function can fail, and, when writing Go, all such failures are generally handled appropriately.
Wow, not having to worry about error handling is indeed an advantage.
This has been stated before but I would like to repeat it here for the record: Decision finding in NMControl development has already been slow and sometimes difficult in the past. I expect this to become way worse with three projects combined.
If you can find a good solution to this I will be interested.
I will continue working on NMControl as time permits and I hope others join me. But you are free to do your thing (btw please give it a proper name soon) and have it compete with NMControl. If you can pull it off and create something really better I will be happy to have one thing less on my list.