https://www.superhouse.tv/product/wheelchair-control-breakou... is the result

found via https://twitter.com/imadsousou/status/1032680311753072640

In my experience with a particular open source project, more than half of new contributors started by communicating privately with myself or some other leader in the project. This is only bad if the communication never moves out of private conversation. I've found it normally takes a few nudges to get people to build their confidence and participate publicly.

Interestingly, it's not only new contributors who suffer from this. I've been told by some of the most prolific contributors to our project that they are still intimidated to speak out publicly. Many times these feelings come from deep-seated cultural norms that don't really fit with traditional Western/American ways of communicating. And that's ok! We all learn together how to best communicate with each other. And we get a healthier community and better code out of it.

There's different levels of "open source" (everything from one-way code dumps to full-on maintained-as-a-whole-distributed-global-team). In my experience, it's easier to start with a simple "here's the code, bug reports welcome". This starting point is generally an easier sell to management who's worried about project management taking too much time away from other work.

Like all things, practice, start small, and grow from there. Get's easier as you go. But yeah--licenses/legal, written policies, governance, marketing, time prioritization, and more all take a lot of time to figure out.

NB: My own background in open source biases me to thinking open source is "easy". It's not; it takes a lot of work. The good news is that there's a lot of tools and help available for anyone wanting to start.

Comments URL: https://news.ycombinator.com/item?id=14876083

Points: 6

# Comments: 1

It's an object storage engine (think S3, but it's open source and you can put it in your own data center) that's excellent at storing unstructured data.

It's completely deployable and usable without any other OpenStack projects.

There's S3 API compatibility for it. It supports globally distributed clusters. It supports multiple storage polices that can be either replicated or use erasure coding. It's designed for very high availability, very high durability, and high aggregate throughput.

One of my favorite features is being able to create sharable, expiring signed URLs to any object in the cluster.

Some of the common uses for Swift include storing user-generated content (eg images, videos, game saves), static web assets, movies, scientific data sets, backups, document sharing, VM and container images, etc.

API docs: - https://developer.openstack.org/api-ref/object-storage/

Docs: - http://swift.openstack.org

Vagrant All-In-One setup: - https://github.com/swiftstack/vagrant-swift-all-in-one

Come say hi! - #openstack-swift on freenode IRC (I'm notmyname)

The only way to durably store data so that it survives a hardware failure (e.g. drive dying) is to store more than one copy. Full replicas are the simplest way to do this, but you've got a relatively high overhead (e.g. Store 1GB of data with 3x replicas, and you store 3GB of data). Erasure codes are a way to effectively store fractional replicas, so you only use 1.5x or 1.7x of the original data.

Erasure codes are great when you've got a lot of data and you need high durability but don't want to pay for the storage space required for full replicas.

Why don't we always use erasure codes for everything? EC isn't great when you've got small bits of data, and since there's a bit of math involved in reading and writing the EC data, EC has higher latency than simple replicas.

https://www.swiftstack.com/blog/2015/04/20/the-foundations-o... is a great into to how erasure codes work.

I've been working on Swift for the past 6 years, and I'd be happy to help with your OpenStack Swift API integration. See my profile for contact info.

Comments URL: https://news.ycombinator.com/item?id=12365956

Points: 339

# Comments: 164

There are two versions of ISA-L. The open-source one includes some optimized erasure code libraries. The other version is free (as in beer) AFAICT but it requires signing a license agreement with Intel. This version also includes some other optimized libraries for hashing, crypto, and stuff like that.

https://github.com/openstack/liberasurecode is a plugable C library that you can use for erasure coding. It supports some simple EC algorithms itself and works with jerasure and ISA-L.

https://github.com/openstack/pyeclib is a Python wrapper for liberasurecode.

I'm curious about how you're managing the data on a drive itself. Are you storing the blocks as individual files on a filesystem? Are you doing direct management of the block device itself? Something else?

http://adrift.org.au