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.

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.

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!