This reminds me of the lessons from the book "Ishmael" by Daniel Quinn. One of the main characters is teaching another lessons throughout the book using a Montessori approach. One of the big lessons is to only take what you need, and to appreciate these things we take for granted. I highly recommend it if you haven't read it already.
Devil's advocate: 10 year old accounts are probably just as likely as any to get hacked into and used for crypto mining, and honestly I bet a majority of their customers don't even use GPU instances.
Well, they could also just mean their service is a multi-process program (as opposed to threads, which...are also processes), but it's not super clear.
Everyone else commenting is missing the point, because as you've said, Prometheus can discover targets via k8s endpoints/pods dynamically already, and you can run a sidecar to reload the config file.
The main point of Prometheus operator is to federate access to Prometheus configuration so teams can manage configuration that the built-in Kubernetes service discovery doesn't let you control from an application side. Things like scrape interval, recording rules and alerts, etc. ServiceMonitors, PrometheusRule CRDs basically let app owners ship these aspects of monitoring with their applications, instead of having to have a hand-off between the service owners and the SRE teams managing the monitoring infrastructure.
I'm pretty sure this is how Nvidia's game ready drivers work. They come with a bunch of pre-made profiles for popular video games, so the optimal settings are configured based on what applications are being executed, which is also why you have to let it scan for your games, so it knows what executables to watch for, so it can properly select the right profile to use.
This doesn't make much sense. You're probably running your software on Linux servers, so having native containers in MacOS doesn't really do much (Also...there is sandboxing in MacOS/Darwin already). And bringing Linux to the MBP, if you want containers..is going to require a Linux kernel, so at the end you're still going to be running Linux VMs, no matter what. This is exactly what WSL2 is doing.
To add to this, the hypervisor can do more to integrate with the guest so that this issue is mitigated somewhat. For example, with KVM and a Linux guest there's a lot of optimizations to share memory pages between the two.
For reference: https://access.redhat.com/documentation/en-us/red_hat_enterp....
This just a classical false dichotomy. Because we spend resources on one thing doesn't mean we can't spend resources on another, and it doesn't mean resources for one thing are being taken away from another. It's not a zero sum game.
It's probably related to how we read and write. Top down, left to right. Rows are the entries, columns are attributes. Your list will potentially grow forever, whereas the attributes are typically fixed. Your width is typically fixed, but you can continue writing top down and continue on a new sheet/etc, as you add more rows. It just makes sense with how we typically organize information on pen/paper.
That's my thought as well. They could also potentially retroactively generate the source tarballs using the old method for every possible repository/tag on Github, store it, and serve that, and then only generate it on-demand for new tags, but I doubt they'll do that. They might though, given this is what led to the problem in the first place (ie; the on-demand generation vs generating on push+storing).
I imagine GitHub would be equally upset if every project every started uploading their source tarballs themselves, as presumably the point of their source tarball feature was not needing to store the source tarball for every repository ever, but generating it on demand.
Downloading a source tarball is significantly cheaper on both sides than git. A source tarball is 100% served from CDNs, whereas I don't believe the same isn't quite true for git (even over https).
In basically every example you gave, you still have to stop until people move though. The result is the same, despite everything else. The only one that's a bit iffy is if you're being carjacked, is a bit of an exception.
Legitimacy isn't really the problem, it's the circumstance of a human being in front of your car that prevents you from moving forward, and beyond getting out of your car and talking to them, or just waiting, you don't have much of a choice in what options you have.
I agree with the intent of your point, but what's the alternative? You can't just keep driving if someone is standing in the middle of the road.
This is awesome. Have you seen http://tea.xyz? Made by the creator of brew. I think it has a lot of interesting ideas, especially since it also has some of the same features as asdf/venv/rbenv/etc: managing multiple versions.
Figured I'd mention it, because I haven't tried tea yet, but I'm an avid asdf and brew user and I've been looking at asdf alternatives.
The main advantage is the content addressable part. Existing overlay filesystems only handle the overlay aspect, and then tools like docker/containerd attempt to reuse layers efficiently, but it's not perfect. The same files from two different layers may have the same content, but it's still stored twice because the layers are the "unit" of storage roughly speaking. By making a single filesystem which handles both content addressability and the overlay aspect, you can avoid duplicating files that are the same, but in different layers.
The reflog does exist on the server too, but it's not really accessible without access to the git repo on the server, so not much use in eg, GitHub. That being said, GitHub also exposes some of these details, for example: in PRs when you force push on your branch.
So in the general sense, there's no reason we can't have exactly what's being discussed, but it just doesn't exist yet.
I think it is your place, because it's your time being taken by people asking questions. It's an often a thankless job people do because they want to help. If you think you might be doing more harm than good by "just answering the question" you're not helping anymore, which then somewhat defeats the purpose many people are doing it. But really, the simpler reason is that, if your helping out others, your giving them your time, so they should respect it, so answering some questions while getting help is part of that respect.
Sometimes all you need is an atomic counter though (or lock). Like, for the commonly used Prometheus metrics format, you usually just have global, atomic counters, because it's arguably the most efficient/easiest way to do it. Higher level primitives are nice, but even lower level APIs might be "the right choice" for even high-level problems.
Using rebase and reflog really taught me a lot about git, because it "rewrites" history and exposes you to some nuance. Like: basically nothing in git is ever gone if it was at one point committed to the repository, that includes branches you delete and never pushed, it also includes commits that are removed with git reset --hard. Once I learned about how to find references, refer to them, and manipulate them, everything else made a lot more sense.
That's not true, you can configure journald to be in-memory only in which case there's no binary log, no file. If your using systems, you can't really git rid of journald, but you can get rid of the binary logs.
And you don't need journald to read the log files either, you can use `journalctl --file /path/to/file.journal` to read them directly via `journalctl`.