Another warning: IPFS is extremely resource intensive (from CPU to bandwidth) .
I’m pretty disappointed they didn’t mention this in the article. If this gets any traction it will eat as much CPU and bandwidth you give it.
Running with Docker and limiting CPU is necessary along with a bandwidth limiter/policer/shaper.
Having run IPFS for a long while it also ends up in strange states and stops responding to requests. I’ve taken to using a monitoring system to GET a known CID and restart the IPFS container if it fails.
My bandwidth and hardware have 100% uptime but IPFS needs restart at least a couple of times a day on average (looking at logs).
There's a new project to make IPFS very performant (within limitations of the protocol, ofc). They've got some really great goals, hope they succeed.
TBH i love IPFS, and i wish i could get behind it and help.. but ever since they starting making Crypto i have moved away from it. I have no way of knowing if they're working on IPFS or if it's merely a means to a Coin.
I agree. IPFS saw the fork in the road and decided to go down the unsuccessful path - there's still time to fix the bugs that matter, but they've wasted a lot of time on infrastructure that will never materialize.
You can just renice/set Low priority to the process for the CPU part, no need for Docker. Bandwidth limiting functionality should be built-in, not sure if it actually is.
I’m pretty disappointed they didn’t mention this in the article. If this gets any traction it will eat as much CPU and bandwidth you give it.
Running with Docker and limiting CPU is necessary along with a bandwidth limiter/policer/shaper.
Having run IPFS for a long while it also ends up in strange states and stops responding to requests. I’ve taken to using a monitoring system to GET a known CID and restart the IPFS container if it fails.
My bandwidth and hardware have 100% uptime but IPFS needs restart at least a couple of times a day on average (looking at logs).
In short: this isn’t practical.