Reminds me of the work Jonathan Oxer presented at LCA 2019 about the journey of reverse engineering and building a similar (and more capable) breakout board for wheelchairs. https://youtu.be/-9Rjh8qJk68
No, because path-style bucket names weren't originally required to conform to dns naming limitations. I don't know how they're going to migrate those older non-conforming buckets to the host-style form.
Azure has been running a Mongo-compliant DB under their Cosmos umbrella for quite a while. It's not clear to me that either Azure or AWS are actually running Mongo software under the hood or rather a proprietary DB that uses the Mongo wire protocol.
Doesn’t Azure also have a not-Mongo service also called DocumentDB? Is this the same code? These cloud services are confusing enough when they don’t borrow each other’s names.
It seems like Amazon may think so, with this line:
> Amazon DocumentDB implements the Apache 2.0 open source MongoDB 3.6 API by emulating the responses that a MongoDB client expects from a MongoDB server
That's great to hear that you're forcing yourself to keep communication in the open, when at all possible. That's one of the best ways to keep a community healthy.
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.
I'd encourage you to do it anyway. We're on the same journey at my company. Some of our product is based on a fairly large and active open source project. Others are much more limited and simply at the "here's the code, have fun" stage.
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.
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.
We had been using S3 in the past and needed to move to Swift due to high cost of S3. Our integration just took a day. Most of the things went smooth and as far as I remember, only some of the meta properties were different, that's all. I can't recommend Swift highly enough.
https://www.superhouse.tv/product/wheelchair-control-breakou... is the result