Great if you’re you, but try getting AverageSWE a local kube setup and see how quickly they ramp up on it
In my ideal world everyone would use kubernetes, it is the hammer and everything is a nail, but we must recognize that it is difficult for a lot of people to pick up.
That being said, if you’re deploying on kube in production, use kube locally. But if you’re not, dont
Using kube in production but really, even if I wasn't, I would still use the podman play kube approach. It isn't hard (at all) and isn't kubernetes, just kubernetes yaml. I actually find docker / compose a bit harder sometimes with the daemon running in the background.
I'm not arguing for the relative superiority of jsonnet vs yaml vs anything else. I just recognise that Docker Compose is loved by most open source developers. And invariably any project you touch will have a docker compose setup by default.
I'm just making it possible to run those on kubernetes seamlessly.
Tilt is great but it doesn’t solve the problem you’re asking about. This project more directly addresses that. Fundamentally the problem is that you want to maintain the lifecycle of several services during an ephemeral ci run and tear them down when you are done. As you mentioned it gets unwieldy and annoying to try to run all of these on a single machine and doubly so when you have a lot of services/containers. Kubedock is more like what you are looking for, it translates compose calls to Kube equivalents and each service in the compose file is it’s one kube pod with its own lifecycle. It should be possible under that to do what you are saying, spawn multiple docker composes from a single run.
It is worth noting that Kubedock has some really annoying limitations, part of it is that it’s one person the other part is that some concepts don’t translate to kube very well. So make sure that whatever you will be doing fits into those constraints before you try it
Why is obesity not considered a necessitating condition? It often carries the comorbidities you just mentioned. Should not exclude people just because they haven’t had these specific health problems (yet) but will eventually have them.
While I tend to agree, insurance companies don't see it that way. They need a doctor to indicate a necessity to treat a condition, as opposed to it being the easiest way to treat it.
For example, I have to take digestive enzymes to digest my food (pancreatic insufficiency). For someone with an unusually high metabolism, they would also give them a leg up on gaining weight, even though there are other approaches to gaining that weight. However in many cases, the insurance company wouldn't cover their prescription when they will mine.
As always it’s insurance nonsense. If incentives were aligned insurance companies would be lining up out the door to give this to obese people because they (the insurance companies) would eventually be on the hook for paying for the care of the conditions you just mentioned. It is very well demonstrated in literature that obese people have a much higher occurrence of these conditions than non obese people.
But the system is not set up with aligned incentives
The problem is that if it's just about obesity, you have to prove that cheaper treatments such as diet and exercise didn't work. That's not impossible to do, but it's hard and annoying even for people who really were trying. My doctor told me that you basically have to keep a detailed journal of your weight loss efforts for months on end.
Are GLP-1s so much more effective that we should make an exception to the general principle, maximizing healthcare resources by providing the cheapest effective treatment? I kinda think so, but I have a conflict of interest, and I can understand why others might think that money is better spent elsewhere.
Actions is many things. It’s an event dispatcher, an orchestrator, an execution engine and runtime, an artifact registry and caching system, a workflow modeler, a marketplace, and a secrets manager. And I didn’t even list all of the things Actions is. It’s better at some of those things and not others.
The systems I like to design that use GHA usually only use the good parts. GitHub is a fine events dispatcher, for instance, but a very bad workflow orchestrator. So delegate that to a system that is good at that instead
“Light work” is a pretty bold statement my dude. I run max for 8+ hour coding sessions with 3-4 windows where I’m babysitting and watching the thing and I never even get session warnings. The only time I bump up against limits is on token hungry tasks like reverse engineering 3M+ LOC codebases or 5-6 agents generating unit tests in parallel. Something tells me that what you call “light work” is not remotely the same as what I consider “light work”
Postgres is widely used enough with enough engineering company blog posts that the vast majority of NotPostgres requests already have a blog post that either demonstrates that pg falls over at the scale that’s being planned for or it doesn’t.
If they don’t, the trade off for NotPostgres is such that it’s justifiable to force the engineer to run their own benchmarks before they are allowed to use NotPostgres
This is my philosophy. When the engineer comes to me and says that they want to use NotPostgres, they have to justify why, with data and benchmarks, Postgres is not good enough. And that’s how it should be
Op calling the de jure database solution (pg) in the world “tiny” is pretty laughable. It’s one of the most popular solutions for databases in general and RDBMS specifically. SQLite is also massive in terms of its adoption and use
Workflow managers are the ultimate wheel to be reinvented. Everyone needs some form of them, they're reasonably easy to implement a poorly working version of, and everyone thinks that they can do it better. In the data engineering world there are literally dozens of solutions that are essentially "airflow, packaged slightly differently"
In my ideal world everyone would use kubernetes, it is the hammer and everything is a nail, but we must recognize that it is difficult for a lot of people to pick up.
That being said, if you’re deploying on kube in production, use kube locally. But if you’re not, dont
reply