When I learned C++, back in the 1980s, the "compiler" (Cfront) was really just a translator that generated C code. That was a good thing, because it occasionally generated bad code, and being able to keep the intermediate C code around during compilation meant you could figure out what was going wrong at that level instead of having to dig into the assembly code. Code-generation bugs still happen occasionally in compilers, I'm sure, but not like it was in those days. Now, it's rare anyone has to worry about the code that ends up executing being functionally different from what was expressed in the higher level language (at least not due to code generation bugs).

But that semantic gap (the levels of abstraction between what the programmer considers as an abstract execution model and what the hardware actually executes) was increased by going from C to C++, and Cfront was the tool that enabled that expansion. Newer, even higher level languages have continued to increase that semantic gap, aiding productivity gains. But, they still generate code in a predictable, consistent way. The same code, compiled by the same compiler version, will generate the same executable code every time.

But here we are again. LLM-generated code is just the new "Cfront", taking very high level language descriptions of what we want, in the form of "prompts", and translating them into code at one (higher) level of semantic gap into another (lower) level of semantic gap. Great. Except now we're back to having to deal with "bugs" in the code generation. Worse yet, it doesn't generate the same code consistently, because the "temperature" parameter is a trade-off between output quality and consistency. Perhaps one day we'll get to where modern compilers and code generators are. Until then, we are still responsible, even liable, for the code we create, either directly or via some LLM-based model. So, we'd better be able to read and understand the code being generated at the layer most prone to bugs, until that layer gets to the same level of reliability as modern compilers are at today.

When launching a container, they boot a Linux VM that just has a single, statically-linked executable inside: vminitd. No systemd or other daemons. No libc or even ld.so, just vminitd.

That process is responsible for talking to things outside the VM, and for launching the container, etc. When the container process exits, vminitd exits and shuts down the VM. Starting the VM takes ~100ms, and the amount of memory and CPU cores it gets are taken directly from the container configuration. So, it's not terrible in terms of memory usage. It's sort of ideal for short-lived containers, since it starts up so fast and only uses as much memory as the container ends up actually allocating (not what it asked for). I'm not sure how they manage to boot Linux in a VM that fast, honestly. Maybe they have a pickled pre-booted image ready to be mapped into memory so they can tell Linux it's just woken up from being suspended? I have read some of the documentation, but I haven't dug into the code yet.

Meanwhile, it uses Rosetta2 to execute x86 code, so you can both build and run multi-platform containers.

I don't know that I'll actually use it myself, since Rancher Desktop is pretty slick, and I need Kubernetes. But, maybe someone will get k3s working on this and I can get away from having to run a big VM all the time. In any case, it's nice to see Apple recognizing how many people use their machines to build Linux containers, and it's nice to see them making it open source while they're at it. It isn't perfect, but it's at least somewhat clever.

There are a few people I think of as having "saved" the internet at various points in time. Van Jacobson and Sally Floyd, of course. But Dave Taht deserves to be in that group, in my humble opinion. Van saved us from congestion collapse in the late 1980s and early 1990s by introducing the core congestion control algorithm in TCP. Sally Floyd (Van's grad student at the time, and, sadly, no longer with us either) created Random Early Detection as much improved queue drop policy in routers that reduced latency and improved throughput.

But Dave took queue management a gigantic step beyond that, figuring out, for example, how to control the flow of outbound ACK packets in order to minimize inbound queue lengths on intermediate routers, minimizing the amount of data sitting in those queues waiting to be serialized onto each outbound link.

I only interacted with him briefly, but he was clearly brilliant, energetic, and just wanted the internet to work as well as it possibly could. Since the algorithms he was working with needed to be running in consumer routers, he spent a bunch of time reaching out directly to as many router manufacturers as he could, critiquing their implementations and offering insightful suggestions for how to improve them, and asking for no more than a lunch in return. Things like internet telephony, FaceTime, Zoom, Google Meet, etc. are all feasible because of his relentless efforts.

Not a doctor â€" engineer. ICU visiting hours are longer, but not 24 hours per day. So I'd come home for a few hours, fix a meal and eat it while reading every published medical paper I could find. I definitely learned a lot. Like, don't try to supplement with albumin. One paper studied that went it made the already poor survival rate significantly worse. I think a lot of engineers and scientists cope by diving in to learn as much as possible.

My then-wife nearly died from Group A Strep Toxic Shock Syndrome nearly twenty years ago. She'd been vomiting for a couple of days and was severely dehydrated. Her skin appeared sunburned. The outer layer would eventually completely shed in sheets about a week later. Once they got an IV drip going, fluid built up in her lungs, likely due to hypoalbuminemia, which is a key feature of STSS. This landed her in ICU on a BiPAP mask (intubation would have been the next step had the BiPAP not worked).

Two IVs plus a twin-lead PIC with five infusion pumps running multiple antibiotics plus IV immunoglobulin and, later, a big bag of lipids. Multiple organ failure, including kidneys meant her electrolytes were way off, and that triggered a latent conduction path problem in her heart. A couple episodes of tachycardia were addressed using a drug that (briefly) stopped her heart completely each time. That was unpleasant.

It took several days for them to even diagnose what it was. But, one day, a young doctor we'd never met before burst into the room and, without introducing herself, said "I know what you have!" After that, doctors from all over the area (a large metropolitan area with over 8 million residents at that time) to examine her just to see what a patient with this extremely rare condition looks like. It was touch-and-go for about a week during her 10 days in the ICU. Recovery took about a year, and left some permanent damage to her gallbladder.

0/10 - would not recommend.

Oof, I wasn't aware the fuel cell wear involved actually losing the catalysts. That does make recycling the fuel cells a lot less useful.

Fuel cell vehicles typically do include a battery. This is necessary because the peak current from the fuel cell stack isn't enough by itself to, e.g., get started going up a hill, or just from a dead stop on flat ground with a heavy load, or accelerating down the on-ramp of a freeway. This does mean they can take advantage of regenerative braking, too. But, that also means those batteries wear out, too. Interestingly, they have the same issue with battery wear that ICE hybrid vehicles do: the total number of charge/discharge cycles is higher on a per-cell basis for a hybrid than for a pure BEV. This is because the smaller battery pack is discharging more deeply when accelerating, and charging more deeply during regenerative braking. So, just like ICE hybrids, a hydrogen fuel cell vehicle will need to plan for battery replacement much sooner than a similar BEV would.

Regarding #2, my understanding is the current fueling stations all have to have compressors between a larger storage tank (that may start out at high pressure when it's filled, but will drop as it is used) and a smaller filler tank that is higher than the destination pressure. This small filler tank drains quickly while filling a vehicle, so even if the first vehicle can be filled quickly, the next one in line has to wait for the compressor to repressurize the filler tank. In short, compressor energy is required at the filling site, and results in relatively low refill throughput when measured over multiple vehicles. So, yeah, we'd need compressors at multiple stages of the system, including production, distribution, and filling.

Regarding #4, not only are the fuel cells expensive to start with, they wear out and need to be replaced for any long-lived or high-use vehicle (like a truck). If we were making a lot of fuel cells, we'd probably find a way to extract those expensive metals and recycle them (similar to battery recycling). But, they are still going to be expensive.

Regarding #5, yes, the tanks are heavy (and expensive). But, just like the fuels cells, they also wear out and need to be replaced for things like trucks.

So, vehicles that are expected to last a long time and drive a lot of miles will have to be designed to allow easy replacement of both the fuel cell stack and the high pressure tanks just to minimize the labor costs. But, those replacements are still going to be expensive.

It's not just the price of the hydrogen itself. It's also the cost of the tanks and fuel cells, which both wear out (and are both expensive). The tanks in a Mirai are rated for 15 years, which sounds ok for a sedan, but a truck would be expected to have a much longer service life than that. I suspect the pressure cycling in a truck would put more stress on the tanks as well. Building them for longer life would make them even more expensive and even heavier.

The fuel cells themselves also wear out. Toyota currently rates the Mirai fuel cell for 150,000 to 200,000 miles. A long-haul truck would do that in less than two years. Short-haul trucking wouldn't, but is better served with batteries.

So, I don't see a place for hydrogen itself in many transportation applications. As feed stock for a synthetic fuel... maybe? Not cheap, though. We'll need lots of hydrogen to make fertilizer and steel, so I don't see the price coming down all that quickly.

Temporary pacemakers are used after various types of heart surgery, especially anything that requires stopping the heart (like most cardiac arterial bypass graft procedures). Those pacemakers are external, except for a couple of wires that go through the skin and under the sternum. They are removed by pulling on them after a few days, if everything is going well. But, that makes them an avenue for infection, and if they get pulled on too early by accident, you could end up needing to go back in to place them again. So, I would expect something like this would be used in that type of scenario: place it during the surgical procedure and then close completely (ok, except for a chest tube for drainage, but eliminating the external pacemaker wires is probably still a win).

A modern web engine requires a high performance javascript engine, and that means being able to generate native code from the javascript. That means being able to set the execute bit on memory pages written to by the javascript code generator. The last time I checked, iOS doesn't allow apps to do that (for good reason). Their own web engine (and its javascript code generator) are "trusted" to do this. In order to support other web engines (and their javascript engines), Apple would need a way to trust those engines before allowing them to generate native code. I don't see what would be in it for Apple to expend the effort that would require.

The tower antennas are directional and essentially aimed down towards the ground (because all of the cells use the same set of frequencies, with adjacent cell interference handled via resource block scheduling coordination, but distant cell interference is still a problem, so aiming the antennas down reduces the interference in distant cells). Point being, these things aren't transmitting straight up, or anywhere even close to it. As long as the tower placement is planned around takeoff and approach paths, it should be possible to engineer around any potential issues.

The interesting question is what sources of latency there are, and how can they be controlled. Propagation delay (the time a signal takes to travel through a medium) really isn't much of an issue as long as the data center hosting the game client isn't terribly far away. In glass fiber, it's about 2/3 the speed of light, so roughly 200 million meters per second, or 200 kilometers per millisecond assuming my coffee has kicked in. Some coaxial cables are faster than that, and twisted pair is in the same ballpark. I don't think I'd want to try connecting to a data center on the other side of the planet, but from a pure distance perspective, a few hundred kilometers isn't going to make much difference on this issue.

So, the network delays end up mostly coming from queueing in intermediate routers and switches (plus maybe a little media access contention on some last-mile networks). Companies that have invested heavily in private networks that terminate deep inside last-mile internet service provider networks have an advantage here, since this gaming traffic can skip most of the ISP's network as well as any higher-tier networks. Google made that investment a long time ago to make things like YouTube feasible, and they target no more than a 40% utilization rate on their private networks, so there are fewer and less congested hops through this path. It doesn't look like Microsoft has that kind of reach into ISP's networks from what I've heard. I don't know if they plan to make that investment, or if they're just hoping ISP and core networks improve "enough" over the next few years to mitigate the issue sufficiently.

The other main sources of delay are in the video encoding and the transport protocol. Google created a custom video encoding chip that produces a new encoded frame in less than 1 millisecond, and they integrated that chip tightly with the transport protocol (QUIC, also created at Google) to recover from packet losses more intelligently and adapt the encoding bit rate prior to congestion losses becoming a significant problem. I honestly don't know how Microsoft implemented their versions of this part of the stack, but while it works ok, the reports I've seen on Reddit seem to indicate it doesn't work quite as well as Google's. I'm sure Microsoft will continue to plug away at improving things over time, and the business-level mismanagement of Google's technically superior (with an asterisk for the current GPU) platform shouldn't worry Microsoft much at this point.

In short, the technology does work well enough for many people. It's especially useful for playing games on the go or while traveling, since it works on phones and tablets. Is it competitive with a high end local rig? No, absolutely not. But, it's a lot more accessible, and has a place in the mix. No one should feel like they have to pick a team in gaming. I have a gaming PC I use frequently. I also use cloud gaming services.

You can definitely see at least some ST elevations on an Apple Watch ECG (lead I – fingertip of one arm to wrist of other arm). I have two stents as a result of seeing that myself a couple years ago (didn't feel good while walking briskly, took an ECG on the watch, wondered why it looked like a shark fin instead of sinus rhythm, learned what it was called in the ER). You can also clearly see bigeminy and trigeminy PVC patterns (heading in for another angiogram today, in fact, after seeing those myself a couple weeks ago; stress test shows ischemia in lateral aspect). I don't know if they have enough data to reliably detect either ST elevation or bigeminy/trigeminy PVC patterns automatically yet. But, I expect they will eventually.

Pills probably won't work. But, greek yogurt with some granola and berries is a nice breakfast. My son brews kombucha for a local company, and that is pretty tasty. It starts out as very sweet black tea fermented with a SCOBY (symbiotic combination of bacteria and yeast). So, it ends up being acidic rather than alcoholic. It's flavored with various spices and fruits, depending on the product. Done properly, the flavors should balance out the acidity nicely. You want to buy from a local company to ensure you're getting something that hasn't been filtered or pasteurized. It should be refrigerated. Also, keep an eye on the total calories - some places add more sugar after fermentation, and they often have to filter or pasteurize to avoid a fermentation restart. Look for bottles that have 30-35 total calories rather than something in the soda range. You can make it at home as well if you enjoy drinking it - you can buy a SCOBY disk, or try to nurture one on your own from an off-the-shelf bottle of Kombucha.

My reading of this is that if you use Safari as your browser, all of that traffic will be proxied through this (assuming you have the subscription and have enabled this feature). Outside of Safari, system-wide DNS lookups will be proxied through this (using DNS-over-HTTPS), as will non-TLS HTTP traffic from apps that use Apple's standard web client frameworks. The result will be that 100% of DNS and web (browser or web service) traffic from the device will be TLS encrypted at least as far as the egress proxy.