It makes absolutely no sense to base this decision on the number of users. We have some applications that don't even have 10 users but still use k8s.

Try to understand the point that was made in the original comment: Kubernetes is a way to actually make infrastructure simpler to understand for a team which maintains lots of different applications, as it can scale from a deployment with just one pod to hundreds of nodes and a silly microservices architecture.

The point is not that every application might need this scalability, no the point is that for a team needing to maintain lots of different applications, some internal, some for customers, some in private datacenters, some in the cloud, Kubernetes can be the single common denominator.

Hell, I'm a hardcode NixOS fan but for most services, I still prefer to run them in k8s just as it is more portable. Today I might be okay having some service sitting on some box, running via systemd. But tomorrow I might want to run this service highly available on some cluster. Using k8s that is simple, so why not do it from the start by just treating k8s as a slighly more powerful docker-compose.

During a duration of time it is okay so say an amount of energy (MWh) was produced, right?

You abuse the term leaky abstraction here. That isn’t a leaky abstraction as a merge commit is literally a commit, isn’t it?

But a 3rd party app will always be less integrated, have less permissions than functionality included by the manufacturer.

And for all this AI integration wide access is pretty much required as you'd want it to access your photos, notes, all kind of apps, etc.

This way manufacturers would have too much leverage over companies developing that kind of AI, as they could always develop better features than them with their own AI agent.

I think Apple Watch is a pretty good example of that already. Third party watches will never be as good as Apple Watch just because Apple won't let them.

  Testcontainers is awesome and all the hate it gets here is undeserved.

  Custom shell scripts definitely can't compete.

  For example one feature those don't have is "Ryuk": A container that testcontainers starts which monitors the lifetime of the parent application and stops all containers when the parent process exits.

  It allows the application to define dependencies for development, testing, CI itself without needing to run some command to bring up docker compose beforehand manually.
  
  One cool usecase for us is also having a ephemeral database container that is started in a Gradle build to generate jOOQ code from tables defined in a Liquibase schema.

What you describe would be 1 Minute of work and maybe 10 clicks with a very low probability of shooting yourself in the foot in Tower.

I ask because in my team we also a long time made the destinction between unit/integration based on a stupid technicality in the framework we are using.

We stopped doing that and now we mostly write integration tests (which in reality we did for a long time).

Of course this all arguing over definitions and kind of stupid but I do agree with the definition of the parent commenter.

This is just a very weird comparison. Seems like the author doesn’t understand why people run K8s.

Of course they also “managed” several k8s clusters using… wait for it… AWS.

I’d say, when you are all in AWS, then fine don’t use k8s. But you also don’t need Nomad then in most cases.

And if you do need nomad on AWS then that’s fine as well, but it’s not comparable to k8s in general.

This is just plain old static site generation?

By "docs as code" I expected something like programmatically verifying that the code examples compile, maybe even spinning up VMs and testing that the example commands lead to the expected output.

Is this less an OS and more like a toolchain to build container images?

I wish macOS had something like WSL built-in.

I think in the case of Nix it is especially important to have a good grasp of the fundamentals so that you can verify your (possibly wrong) assumptions when troubleshooting a build failure, evaluation failure or when using the higher level constructs of nixpkgs.

What's even crazier is that they are so confident in their spam filter that they simply reject mails classified as spam. But that hasn't been a problem since the few years I have been using them as well.

We use them because then what’s running in prodcution is 100% the same as is running locally when testing the application.

You can hardly get there using Ansible.

That's only partly true. And yeah they're callbacks but not like e.g. we know from JS.

As far as I know CPS basically means that the Kotlin compiler turns a function like that:

    suspend fun myFunction(param: String) {
      val asyncVal = someSuspendingFunction()
      val asyncVal2 = anotherSuspendingFunctio(asyncVal)
      return someCalculation(asyncVal2)
    }

     // The different parts of the function get put into different ifs
     // The state that is normally in the JVM stack frame is holded in a custom class which is a subclass of https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.coroutines/-continuation/
     // Some integer tracks where in the function we are
     fun myFunction(param: String, continuation: Something?) { 
        continuation = continuation ?: MyFunctionContinuation(param)
        if (continuation.state == 0) {
          contination.state = 1
          someSuspendingFunction(continuation)
          return SUSPEND
        }
        if (continuation.state == 1) {
           // The result mechanism is in the Contiuation interface/abstract class. It can be used to later receive the async result
           // of callig annother suspending function
           continuation.asyncVal = contiuation.getResult()
           anotherSuspendingFunction(continuation.asyncVal, continuation)
           return SUSPEND
        }
        if (continuation.state == 2) {
           continuation.asyncVal2 = contiuation.getResult()
           return FINISHED(someCalculation(continuation.asyncVal2))
        }
     }

     class MyFunctionContinuation: Continuation {
        
        // Function arguments
        val param: String
        
        // Every suspending function needs this. It tracks where in the function we currently are
        val state: Int = 0
       
        // Local variables inside the function. Those would normally live in the JVM function stack 
        // But the  Coroutine runtime needs to be able to "rehydrate" the JVM function stack once a non-blocking call finishes
        var asyncVal: 
        var asyncVal2: 

     }

I read this sometime in some book about coroutines. But you can see that there is some overhead. The basic idea is to replicate the function call stack in a custom datastructure. This way we can be deep inside a normal JVM callstack and also have a separate Kotlin Coroutine callstack.

Once the coroutine wants to suspend it can simply return from the JVM callstack but the Kotlin callstack is preserved. Later when we want to continue we can call the same function again, with the Kotlin callstack now containing the result of the async operation.

If the JVM can do this natively we wouldn't need this second Kotlin coroutine callstack because the native JVM callstack would support this.