\1 I continue to struggle with @ParityTech's software design decisions. My #Parity node keeps dropping peers. The advice I get is "upgrade to the latest unstable version". Parity is even configured to auto-update itself by default. Why do I have to run at the edge just to work?
2\ Parity is either (a) consumer software or (b) bad software.
It's (sometimes) OK when consumer software forces you to upgrade b/c, as a consumer, you're dumb & insecure. Business (or prosumer) software achieves a higher level of security & control by sacrificing ease of use.
It's (sometimes) OK when consumer software forces you to upgrade b/c, as a consumer, you're dumb & insecure. Business (or prosumer) software achieves a higher level of security & control by sacrificing ease of use.
3\ Consider: if Parity upgrades itself automatically that means /usr/bin/parity can edit itself. I have to completely trust that the Parity code, DNS, &c. prevents any peer from causing my Parity to change to something unintended. I hate this "feature", so I turned it off.
\4 I want the config owned by root:wheel, chmod'd 640, with Parity running as its own user. This way, only I (root) can make changes. If Parity has a bug which allowed insecure updates, the OS would have my back and prevent it from changing itself. More manual, but more secure.
\5 Shipping Parity to auto-update itself is insecure and reveals a development culture which cannot commit to supporting a release cycle with long-term stable versions. (To say this is impossible implies Ethereum is "in beta". Is it?)
What is the most stable ETH node? #Geth?
What is the most stable ETH node? #Geth?
\6 As a PS, I have an EC2 instance running bitcoind v. 0.99 from 2013 and it is *still* syncing and I never have issues. I've decided to let it run till it breaks, if it ever does. That is what stable, production software looks like!
