What is your take on this?
47 karma · joined July 7, 2017
What is your take on this?
A system, like Pub/Sub, being a critical dependency or hard dependency does not make it a SPOF. Otherwise any system is a SPOF, creating absurd architectures that end up with more complexity and downtime than the original one. For example, I assume incident.io are yet to see if their added complexity of multiple event streams does not cause worse availability issues than what they had, by introducing complexity like problems with data consistency.
If the the underlying "system" components are not redundant and highly available, then you have a SPOF. eg. A single machine is what provides Pub/Sub.
In this case, what you have is a hard-dependancy with an avaialbility lower than what you want to achieve, but there are always shared hard-dependancies that they will have. There is no way around this. What we should aim for is that any system that is a critical dependancy or a hard dependancy with such a big blast radious, to be redundant and robust in itself. Not just the system, but the practices around it.
* You predownload the "image" which is the part that takes long in docker * You also run inside of `lima` which is already a virtualized layer
What is the thing that is faster? I do love microvms and firecracker, but this article makes no sense to me.
eg. Target their NPM and PYPI tokens, so they can push compromised packages.
I don't see any similarity between the two that would lead me to believe that there is influence. Why do you mention this?
This seems like a plug to your product more than anything else.
Is that not the case?
I was reading https://www.ubicloud.com/blog/ubicloud-hosted-arm-runners-10... but seems like a bit misleading to compare an ARM workload over QEMU vs a native ARM.
What about native x86 vs native x86 or at least native x86 vs native arm?
Bad replies, to bad replies
EDIT: OK, I see the main trick is to use PATH instead of shims.
> rtx does not use shims and instead updates PATH so that it doesn't have any overhead when simply calling binaries
There is a good reason `asdf-vm` uses shims, and is that it does not have to interplay or worry about other tools that set PATH and tools that need a reference to an executable could be simply set to `~/.asdf/shims`.
Ill take it for a spin, but this choice might have a lot of consequences that are not easy to foresee. A good example is `direnv` which as you mention in the README now requires to be set in `.envrc` and then disable global `rtx` hook I guess.
Do you plan to allow for self-hosting? eg. An org that wants to have a private version of this, or even internal version of it.
I believe there isn't and that is part of the problem with GDPR in my experience.
Is this confirmed by anyone else?
I have not seen metris or blogs that prove this "uptick in build efficiency" or an increase productivity.
While I do like the idea behind bazel, I hate repeating deps in things like "go_repository" with gazelle.
"This is what we did at <linktomynewsaas>".
Is this what guerilla marketing and HN have become?
Used to really love things like GitLab, but I dont like bloated sites/tools and IMO things like Space or the direction GitLab has taken create bloat as they start to heavily couple their own tools and "workflows".