Update Proposal for Storage Node Operators

I’ve just bought one. I planned to get one in half a year anyway for my lab, there was a promo yesterday, and if it still manages to earn some storj tokens before I’ll need to use it, all the better… though this is a case of an experienced SNO with an opportunity. Can’t imagine a random person joining fresh this way.

Anyway, when it will be installed, I’ll be at around 0.65 W/TB, going down from 0.8 W/TB. Yay!

S3FS is slow and its design as a FUSE file system does not allow it to avoid some problems. This
is visible even when connecting directly to AWS S3 from an AWS EC2 machine, i.e. the most favorable conditions. I’ve never seen it being used for anything but some lightweight dev work. Emulating a file system is hard work, if you can avoid it, you do so. S3 is usually integrated directly into devops or ETL tools, only then it’s solid. This is also I suggested Storj Inc. worked more on integrations. In my backyard that would be tools like Apache Camel, Apache Airflow, Django and so on, but there are tons of them.

The worrying thing though right now is that right now it’s not easy to write a compliant implementation without linking to golang and leveraging the existing libuplink code, and having to link to golang from non-golang environments is an obstacle that makes deployment troublesome.