Oh cool, I didn't know it could! Regardless, advanced routing is still something that RabbitMQ has that isn't in NATS. It's not useful for every system, but it is a differentiator. I usually reach for NATS + Jetstream these days, with its object and KV systems it's a really great "all-in-one" for basic stuff.
Slackbots like DailyBot are great for fully async standups. We've found that many topics a better handled on a live conversation, so support both live and async use cases as well as alternating between live and async
It might sound a bit pedantic, but kustomize strictly avoids the "Infrastructure as Code" space and stays in the "Infrastructure as Data" space. The main difference is that since it just deals with "data", you can build any higher level tooling on this. One of the major proponents of this idea is Brian Grant from Google. He tweets about this from time to time. Here is a recent one: https://twitter.com/bgrant0607/status/1404461906186833927
Is this distinction really about whether the customisation language is declarative? It seems to me that Dhall has the advantages Brian Grant attributes to "Infrastructure as Data", although it is an executable specification.
The difference between the AGPL and traditional GPL is simple: The AGPL seeks to close a "loophole" that allows a company or organization to modify GPL'ed software and use it to provide a service — but without actually distributing changes. So a company can take a package like, say, WordPress and modify the software significantly to sell a service — but hold back changes because it's not technically "distributing" or "propagating" the software. The AGPL goes a bit further and says that if the program is "intended to interact with users through a computer network" and if the version that you received gives users "the opportunity to request transmission to that user of the Program's complete source code," you have to maintain that functionality and distribute the modified version.
1. the software is conveyed in a "User Product", and
2. that conveyance occurs as part of a transaction in which the right of possession and use of that product is transferred to the recipient.
A "User Product" is defined as 'either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling'.
In other words, it only covers software that is installed on actual physical hardware when that hardware is sold (or rented, etc) to the consumer.
For a sale of a service, it is completely out of scope.
This is probably the most misunderstood clause in GPLv3, with people thinking that it some sort of general anti-DRM clause. Almost everybody, for example, thinks that it is why you can't have GPLv3 code on the Apple app store, but because it only applies to conveyances that are part of the transaction by which you acquire your iPhone or iPad it in fact does not apply to software purchased later from the app store. Apple's app store DRM is perfectly compatible with GPLv3.
The incompatibility between the app store and GPL is that the license agreement for the app store says you won't redistribute the app or reverse engineer it. GPL does not allow adding additional license restrictions like that, and so you can't satisfy both the app store license and GPL.
Agreed, it's much better than Travis. But the GP is right, it's more "hack blocks together", where each action does its own thing and acts on the files independently, and there isn't much control over the whole process. Heck, they don't even fully support the entire YAML spec (I'd give citations on that but I'm writing from my phone, and don't have the time to pull it up).
I haven't used GitLab for a while because most of the projects I'm working on are on GitHub, so I can't comment on GitLab CI.
It's much better than Travis in every way except one: GitHub Actions pull request checks are against the PR branch, while Travis pull request checks are against a merged tree.
The most common case where this matters is if someone pushes a failing commit to master, and then all PRs based on that commit will also fail, and then a fix is pushed to master. With Travis, you just need to re-run checks, but with GitHub actions, all those PRs need to be rebased on the new master.
Yeah, that's interesting. Being able to run the runner on my own instance on Google cloud is so easy to troubleshoot. I've not played with actions but when I need to shell into my runner and check something, having root and owning the machine makes that really fast.
https://docs.nats.io/nats-concepts/subject_mapping#for-traff...