Maybe not via kubectl directly, but it is rather trivial to build this, by simply combining all log streams from pods of a deployment (or whatever else).
I've seen this take on LLMs many times, and I don't share the certainty that LLMs hinder the growth of engineers using them.
Sure, if you want to use an LLM to produce code that works you need to have enough knowledge and experience to be able to review and, if necessary, request changes.
However, another (IMO, even more powerful) aspect of LLMs, is their utility as a learning tool.
They excel at imparting knowledge about new concepts, because they act as a personalized teacher.
I find it doubtful that use of LLMs will result in less experienced and knowledgeable engineers in the future.
You sound like someone who has developed a good work ethic and is comfortable with struggle. Likely because you didn't grow up with a magic thinking box to ask for help at the first bit of mental friction.
You can pass multiple return values of a function as parameters to another function if they fit the signature.
for example:
func process[T any](value T, err error) {
if err != nil {
// handle error
}
// handle value
}
this can be used in cases such as control loops, to centralize error handling for multiple separate functions, instead of writing out the error handling separately for each function.
for {
process(fetchFoo(ctx))
process(fetchBar(ctx))
}
The original statement stands, if what you are suggesting in addition to it is true. If the initial one-time investment of $505m is enough to distill new SOTA models for $0.50 a piece, then the average cost for subsequent models will trend toward $0.50.
A fixed monthly subscription amount with unlimited usage will always carry this deficiency.
A solution that addresses this would be usage-based pricing.
If you listen to a single band for 1 hour a week, then you should not be paying for a Spotify subscription, but rather buy the music of that band.
This situation is obviously constructed, but if you were in it and unhappy about it, it would be your own fault for misunderstanding what you're paying Spotify for.
From Wikipedia:
> A drug is any chemical substance that when consumed causes a change in an organism's physiology, including its psychology, if applicable.
Coffee, psychedelics and alcohol are drugs just like heroin. Whether you believe they are useful to consume is a different matter.
That's exactly what I meant. In a literal sense, pretty much any substance/chemical is a drug (like sugar). Yet, since the 80s, the word "drug" means something very different.
In that sense, I wouldn't call SWEs a "drug using group."
We all know the pedantic meaning of the word "drug" - in that case, the whole humanity is a drug-taking species, since we prefer drug-altered consciousness to our natural one (e.g. by caffeine).
I recently went this route. I didn’t want to set up or use Unity so I wrote my own 2D fluid simulator based on some of the same papers using Metal compute shaders (though I’d love to try again using webgpu). Sebastian’s video is great and the implementation is good. But this was a great (and fun) opportunity to look for ways to improve on it.
For starters, the way he’s doing the spatial lookup has poor cache performance, each neighbor lookup is another scattered read. Instead of rearranging an array of indices when doing the sort, just rearrange the particle values themselves. That way you're doing sequential reads for each grid cell you look for neighbors in, instead of a series of scattered reads. The performance improvement I got was about 2x, which was pretty impressive for such a simple change.
The sorting algorithm used isn’t the fastest, counting sort had much better performance for me and was simpler for me to conceptualize. It involves doing a prefix sum though, which is easy to do sequentially on the CPU but more of a challenge if you want to try keeping it on the GPU. "Fast Fixed-Radius Nearest Neighbors: Interactive Million-Particle Fluids", by Hoetzlein et al [0].
Or, if you want to keep using bitonic sort, you can take advantage of threadgroup memory to act as a sort of workspace during bitonic merge steps that are working on small enough chunks of memory. The threadgroup memory is located on the GPU die, so it has better read/write performance.
I ended up converting his pure SPH implementation to use PBF ("Position Based Fluids", Macklin et al, [1]), which is still SPH-based but maintains constant density using a density constraint solver instead of a pressure force. It seems to squeeze more stability out of each “iteration” (for SPH that’s breaking up a single frame into multiple substeps, but with PBF you can also run more iterations of the constraint solver). It’s also a whole lot less “bouncy”. One note: I had to multiply the position updates by a stiffness factor (about 0.1 in my case) to get stability, the paper doesn’t talk about this so maybe I’m doing something wrong.
The PBF paper talks about doing vorticity confinement. It’s implemented exactly as stated in the paper but I struggled for a bit to realize I could still do this in 2D. You just have to recognize that while the first cross product produces the signed magnitude of a vector pointing out of the screen, the second cross product will produce a 2D vector in the same plane as the screen. So there’s no funny business in 2D like I had originally thought. Though, you can skip vorticity confinement, the changes aren't very significant.
There’s a better (maybe a bit more expensive) method of doing surface tension/avoiding particle clustering. It behaves a lot more like fluids in real life do and avoids the “tendril-y” behavior he mentions in the video. "Versatile surface tension and adhesion for SPH fluids" by Akinci et al [2].
One of the comments on Sebastian's video mentions that doing density kernel corrections using Shepard interpolation should improve the fluid surface. I searched and found this method in a bunch of papers, including "Consistent Shepard Interpolation for SPH-Based Fluid Animation" by Reinhardt et al, [3] (I never implemented the full solution that paper proposes, though). There's kernel corrections, and then there's kernel gradient corrections, which I never got working. With the kernel corrections alone, the surface of the fluid seems to "bunch up" less when it moves, and it was pretty simple to implement. Otherwise, the surface looks a bit like a slinky or crinkling paper with particles being pushed out from the surface boundary.
I found [0] and [1] on my own but I found [2] through a thesis, "Real-time Interactive Simulation of Diverse Particle-Based Fluids" by Niall Tessier-Lavigne [4]. I also use the 2nd order integration step formula from that paper. It has some other excellent ideas that are worth trying.
Many years ago I used a paper (that is in fact one referenced by Sebastian’s video) and some C sample code I found to write an SPH simulator in OpenCL. I had been wanting to write one again but this time get a real understanding of the underlying mathematics now that I have some more tools under my belt. I owe it to Sebastian that I finally started on my implementation and I understand SPH a lot more now.
k9s (k9scli.io) supports this directly.