rsanders

I'd say that medicine has been a net benefit to bettering the lives of those who have access to it. I'm biased, though - "drugs" have kept me alive and able for the last 30 years.

The gray market for peptides is pretty fascinating. I've spent the last month exploring it and interacting with some of the Chinese entrepreneurs involved, as well as the informal regulatory functions provided by self-organizing groups of buyers who pool their resources to test the products and share experiences. It's a surprisingly wholesome kind of shady.

An enterprising shopper can stock years worth of semaglutide or tirzepatide, or even the newer medicines still in trials like cagrilintide, retatrutide, mazdutide, survodutide, et cetera -- for a monthly treatment cost of less than $100. Heck, you can get max dose sema for $5/month. Which, putting aside the legal/IP and risk issues for a moment, is a good thing for the people who will likely be on these medicines for the rest of their lives.

Having a less obese population would have so many positive impacts on our quality of life, healthcare system, and economy. I hope that somehow these medicines become cheap and plentiful enough that people can take them prophylactically.

I'm pretty new to Rust so forgive me if I'm mistaken, but it seems to me that this crate doesn't require the use of tokio.

Which ones would you recommend?

Swapping in a multi-vendor world also implies standardization. It’s too early in this technology to standardize - that would stifle progress.

Swap stations would also be far more expensive to build and manage inventory for, and would carry higher liability for whatever automated mechanism moved the thousand pound pack packs around when it e.g. went out of alignment and crushed somebody’s car frame.

If CSV were being used just to exchange data with Excel, we probably wouldn't be using CSV. Many systems neither need nor know that ="01" should be treated as the string "01".

If Excel were the only intended consumer, .xlsx would be a preferable file format. At least it's mostly unambiguous.

That's a good point. But then you're not benchmarking C++ as a distinct language. So what would sufficiently distinguish a C++ program from a C program? Let's assume it's not just minor incompatibilities introduced to prevent compilation by a C compiler.

There must have used some definition that is not explicit in the paper, but you can see in this code sample that the author used various C++ standard data types (std::string, std::array), iterators, classes, concurrency (std::thread). I'm no judge of C++ style, but perhaps it's "C++ as a C++ developer circa 1997 would have written it".

https://github.com/greensoftwarelab/Energy-Languages/blob/ma...

Ha! I picked up the original project (dosemu1) from an abandoned skeleton created by Matthias Lautner. I was a larval programmer and Linux was very much in its infancy. I really wanted to run Civilization on my one computer without keeping the DOS partition around -- staying on 24/7 Linux was a point of pride back then. While I got quite a few programs running well under dosemu, I never had much time to play Civilization after picking up the project.

Thankfully, when I got out of my depth and then joined a fledgling new ISP (MindSpring) as the first engineer, the worthy James MacLean took over and turned it into a solid system. Not sure why I'm not listed in the THANKS, but perhaps it's revenge for the poor code quality I left behind. :-)

It was one of the most enjoyable projects of my career, despite or perhaps because of how little I knew and how much I had to learn.

- root @ hrothgar

Can you expand on this: "AWS healthchecks each kubernetes node, but not your pods themselves".

Are you talking about a keepalive connection to an unhealthy pod which is reused for multiple requests? So the failure modes are, if I understand you correctly, a) the ALB keeps sending requests through an established keep-alive HTTP connection which terminates in an unhealthy pod, but which it sees as healthy because the node is healthy and can route traffic to another, healthy pod, and b) the health of an established HTTP keepalive connection is perceived to be that of the node rather than the destination pod, so nodes which become unhealthy can cause the ALB to unnecessarily terminate a keepalive connection.

We had to switch to using target-type=instance because of issues with pods not being deregistered. I'd prefer to use target-type IP but it seemed like preventing 500s on rollouts required a bit of testing and tuning with a very specific approach. e.g. introducing a longish delay on pod termination with a lifecycle hook and using the pod readiness gate support recently added to alb-ingress-controller.

Fewer features and fewer lines of code, and those LOC are written in Go, which is the language in which CockroachDB is written and which, presumably, for which their team and tooling are best optimized. It's a reasonable thesis.

It looks possible on EKS now. https://aws.amazon.com/about-aws/whats-new/2020/08/amazon-ek...

I wrote a little fork+spinloop program w/100 subprocesses and deployed it with a low (100m) CPU request and no limit. It's certainly driving CPU usage to nearly all 8 of the 8 cores on the machine, but the other processes sharing the node are doing fine.

Prometheus scrapes of the kubelet have slowed down a bit, but are still under 400ms.

Prometheus scrape latency for the node kubelet has increased, but not it's still sub-500ms.

Note that this cluster (which is on EKS) does have system reserved resources.

    [root@ip-10-1-100-143 /]# cat /sys/fs/cgroup/cpu/system.slice/cpu.shares
    1024
    [root@ip-10-1-100-143 /]# cat /sys/fs/cgroup/cpu/kubepods/cpu.shares
    8099
    [root@ip-10-1-100-143 /]# cat /sys/fs/cgroup/cpu/user.slice/cpu.shares
    1024

That may be more likely with limits, but it doesn’t require a limit. I’ve had lots of fun with that in Elasticsearch pods with no limit. And then you get to enjoy a nice cascading failure.

I should have said that it seems like the wrong fix to the problem. But I have since learned that limits can cause excessive throttling. And of course you may want your pods to be burstable, but that would just be a question of setting appropriate limits.

Live and learn!

Can you explain how having a CPU limit set (at any level) has a negative effect on latency? That's an important factor to understand.

The arguments for allowing containers to burst makes plenty of sense to me. I do it on most of my services!

thockin's reddit post for reference: https://www.reddit.com/r/kubernetes/comments/all1vg/on_kuber...

Another interesting bit of context describing some of the non-intuitive impacts of CPU limits: https://github.com/kubernetes/kubernetes/issues/51135

Edit: added links

A container with a request but without a limit should be scheduled as Burstable, and it should only receive allocations in excess of its request when all other containers have had their demand <= request satisfied.

A container without either request or limit is twice-damned, and will be scheduled as BestEffort. The entire cgroup slice for all BestEffort pods is given a cpu.shares of 2 milliCPUs, and if the kernel scheduler is functioning well, no pod in there is going to disrupt the anything but other BestEffort pods with any amount of processor demand. Throw in a 64 thread busyloop and no Burstable or Guaranteed pods should notice much.

Of course that's the ideal. There is an observable difference between a process that relinquishes its scheduler slice and one that must be pre-empted. But I wouldn't call that a major disruption. Each pod will still be given its full requested share of CPU.

If that's not the case, I'd love to know!

Excluding kernel bugs, CPU limits just provide an upper bound on burst capacity. That controls oversubscription of CPU on a node. As with any other kind of oversubscription of a resource based on variable demand, there is a tradeoff. Allowing one pod to burst over its request is both unreliable and potentially impacting other neighboring pods. Whether that improves your cluster efficiency or introduces intolerably high variability in service latency and throughput depends on your mix of workloads and how the scheduler distributes your various pods.

Buffer's solution of having different flavors of node, onto which mutually compatible workloads are scheduled in isolation from incompatible ones, is a very reasonable thing to do, even if this particular case is a bit of a head-scratcher.

Removing CPU limits seems like a bad idea now that there's a kernel fix. But putting that aside...

I don't understand why pods without CPU limits would cause unresponsive kubelets. For a long time now Kubernetes has allocated a slice for system services. While pods without CPU limits are allowed to burst, they are still limited to the amount of CPU allocated to kubernetes pods.

Run "systemd-cgls" on a node and you'll see two toplevel slices: kubepods and system. The kubelet process lives within the system slice.

If you run "kubectl describe <node>" you can see the resources set aside for system processes on the node. Processes in the system slice should always have (cpu_capacity - cpu_allocatable) available to share, no matter what happens in the kubepods slice.

    Capacity:
        cpu:                         8
        ephemeral-storage:           83873772Ki
        memory:                      62907108Ki
    Allocatable:
        cpu:                         7910m
        ephemeral-storage:           76224326324
        memory:                      61890276Ki
        pods:                        58

Granted, it's not a large proportion of CPU.

This advice is confusing. CPU is a "compressible" resource -- pods don't get killed for (trying to) exceed it. Pods don't get evicted from nodes based on CPU starvation, so autoscaling your node count won't help if you end up with a set of pods on a node that need more CPU than the node can provide. They'll just starve each other.

If your service allows horizontal scalability, you can use autoscaling of pods with Horizontal Pod Autoscaler (ideally also with a cluster autoscaler) to increase pod count for a given service when some percentage of the requested CPU is exceeded, whether or not you set a CPU limit. Setting the cpu_request appropriately for your pods is critical to ensure that node CPU is not oversubscribed by the Kubernetes pod scheduler.

Pods where mem & CPU requests = limits are given the highest class of service ("guaranteed"). For your most critical and latency sensitive services, this is the best approach when also coupled with HPA. Assuming a 4.19 kernel or later, I suppose.

https://medium.com/better-programming/the-kubernetes-quality...

Thanks! I didn't realize they were such distinct personalities.

I thought Red Hat announced last year they were abandoning Btrfs and enhancing XFS with similar features.

The support for multi-arch docker images is getting there, but there's not much of an ecosystem. Between Raspberry Pi, ARM instances on AWS, and ARM-based Macs, it ought to get to critical mass before too long.

Retrying transactions is something every app ought to handle, but it's rare enough that most codebases I've seen just punt on it.

My last company used Terraform to manage Kubernetes. The main issue is that the TF Kubernetes provider supports a limited subset of K8S object types, and of fields within those K8S objects. For example: TF didn't even support Deployment objects until sometime in mid/late 2019 (I may be wrong on timing, but it was long after they were the primary method for general scheduling of long-running containers).

We ended up using TF's Helm provider, sometimes with hacks like a helm chart which deploys an arbitrary YAML file (the so-called "raw" chart). At that point, Terraform is blind to what's actually happening inside K8S. You can still benefit from the ability of TF to pass data from your other infra automation into the Helm charts, of course, but it's really Helm actually managing the configuration of your K8S cluster. And that's the app we all love to hate.

The situation may have been improved, but my conclusion was that it would always be a somewhat incomplete interface.

I believe that if you have a Parquet file meeting certain criteria, it's directly parallelizable as multiple Spark partitions without any shuffling. The splits would occur at Parquet row group boundaries, I believe.

See https://stackoverflow.com/questions/27194333/how-to-split-pa..., https://parquet.apache.org/documentation/latest/, etc.

Whether it's better to have multiple Parquet files or a single parallelizable Parquet file is dependent on your environment and application. At my company, we've tended to have a single row group per file (and one HDFS block per file), in part due to historical reasons.

The situation isn't terribly different for private health insurance. You're still spending out of a shared pool of dollars, and you don't have complete freedom in how you choose to do so.

My company has about half of our services inside Kubernetes, and multiple K8s clusters, so this is a dream come true. We'd already been eyeing Connect as a much simpler service mesh we could use both inside and outside K8S.

It does seem that Hashicorp has been slow to embrace K8S, perhaps in part due to pushing their Nomad scheduler. I'm glad that is changing. Let each product succeed on its own merits and serve the market best without trying to advantage the others.

The JVM tax on footprint isn't terrible when there is one instance per host providing the service mesh for all processes on that host. In a containerized deployment model, however, each process may have a "sidecar" process providing its entry point into the service mesh. Whether that's a problem depends, but it certainly gives people pause.

We have a separate build cluster due to concerns about security and stability -- neither mounting the docker socket into a container nor docker-in-docker are comfortable solutions for our cluster managers. Having the ability to run container builds safely will be a huge benefit for my company.

We've looked into something like Bazel for its container builder, but that's a significant change that has to be made in every single project, most of which have perfectly fine build systems now.

And with all the FaaS systems which are continually building containers to host functions, this will be a godsend.

Who are you suggesting will be giving all these babies index funds, and with what investment?