Well, if he had proposed more concrete plans for what that body might do... but yeah, it seems too abstract that indeed sounds like a bureaucrat wanting to wrap everything under a big pile of paperwork.
I shared your fear some weeks/months ago so I was always using my harness in the cloud. However, latency started to become an issue when I traveled to other countries where I needed a VPN... so I ended up cooking skynot to be able to trust running my harness in my own computer: https://github.com/tarsgate/skynot (PRs welcome if you want to add support for another harness different than Pi)
That's why I don't even let my AI use my user account. If you are interested in this setup, use my tool 'skynot' or adopt a similar setup: https://github.com/tarsgate/skynot/
Funny to find this just now, when just yesterday I told an LLM "and please don't lecture me again on $factAboutSomeProgrammingSubject", and then the LLM proceeded to write wrong tests and just told me "alright, tests pass, I'm sorry for correcting you before...". It took me a while to find the wrong tests. Wasted time all around.
If you do a type check with None, and there is some value inside (so it is Some, not None), it is IMPOSSIBLE that the .value that you extract underneath is gone. This is an important race-condition that you might run into due to the nature of TS/JS, but by boxing the value with an immutable Option type, you're protected.
Also this prevents people to run into NullReferenceException (or UndefinedRefsExceptions, or whatever is called in this ecosystem) for people that didn't turn strictNullChecks ON.
The real issue is the cancer practice in our software development industry of updating dependencies for the sake of updating.
Deps should be updated when you need some features or bugfixes from the new versions; not just when DependaBot prompts you to do it.
I see value in DependaBot and things like that only to check that your module still passes your CI with upgraded dependencies (and if not, then it's worth looking at the failure, to be prepared for the updgrade in the future).
If you mean that if it reaches a certain point, the entire system will collapse, it means you don't understand the difficulty adjustment. If it's too expensive to mine, then some miners leave, which makes blocktimes be longer, but not to worry because the consequence of that it just that difficulty will go down, which means that you need less hashrate to mine (and maybe some of those miners that leave will come back because it is profitable again for them). This means that it is essentially impossible for all miners to leave at the same time; some of them stay even if at a loss, and some of them are just hobbyists that can already feed their miners with solar power (so there's really no loss for them in leaving them connected).
Are there incentives for nodes to join the swarm (become a seeder)? If yes, how exactly, do they get paid in a decentralized way? Any URL where to get info about this?
Yup, in my TODO list (I've only recently published this package). For now you can just check the tests, or a SO answer I wrote a while ago (before I published the idea as an npm package): https://stackoverflow.com/a/78937127/544947
> Go was not satisfied with one billion dollar mistake, so they decided to have two flavors of NULL
Thanks for raising this kind of things in such a comprehensible way.
Now what I don't understand is that TypeScript, even if it was something to make JavaScript more bearable, didn't fix this! TS is even worse in this regard. And yet no one seems to care in the NodeJS ecosystem.
<selfPromotion>That's why I created my own Option type package in NPM in case it's useful for anyone: https://www.npmjs.com/package/fp-sdk </selfPromotion>