If model members were available, with all the usual measures, thats a fantastic place to start looking at serious inclusion. It doesnt seem thats the case, however.

Im an environmental scientist and engineer with substantial disaster management and policy experience.

One or two very large events can totally eclipse the cost to economy of reducing emissions and focussing on long term stable low emission power. Those very large events are becoming more common. A couple of years back we ran a multi jurisdictional exercise about a high end cyclone hitting the local major city. Even with 4 days warning there was insufficient time to evacuate the entire population of several million, and rehousing was an almost unsolvable nightmare. That city is not cyclone ready or hardened, but the climate models enable high category events travelling where they were previously quite unlikely.

Im Australian, so it also means droughts, water restrictions, and significant increases in bushfire number and severity after a few years of drought. Drought followed by cyclone, or bulk rain events causes catastrophic flooding. Its a shit show.

Going on what the poster above says about CPU and memory - if the network speed or bandwidth allocation is the bottleneck, then trading CPU and memory utilisation increases for lower bandwidth is likely acceptable. If, however, the device is low end and tying up memory and CPU with compression would lead to sluggish or impaired task performance but the network has adequate overhead for lower levels of compression or higher levels of data transfer then higher network utilisation would be preferable.

Different tools, different use case scenarios.

Client -- Relay Server -- Host

That's certainly less than ideal since many remote desktop session will not be using a middle-age server but rather be direct between client and host.

The model is presumably aiming for an acceptable visual representation, not trying to produce z-ordered components and a lost of any other random requirement people might come up with. The task is to show a pelican riding a bike, not produce a technical design that is layer order correct, after all.

Also:

> Near leg: from (300,245) to (356,408): thigh+shin as a single slightly bent line: M300,245 C 310,320 330,370 354,406. Stroke #F2953F width 12, linecap round. Far leg: from (320,250) to (404,452): M320,250 C 350,330 385,410 402,448. Stroke slightly darker #E0802F (behind, drawn before near leg but after bike? Pelican legs are in front of frame? Pelican is drawn after bike, so legs overlap the frame. The far leg ideally would be behind the frame, but in flat cartoon this is acceptable — or draw the far leg before the pelican body but after bike; overlaps the red frame.

More egg on Flocks face and more community backlash isnt a bad thing in my opinion.

The cameras enable good and reasonable prosecutions as much as they do oppressive political ideologies.

That prep doesn't extend to building standards for higher magnitude quakes.

Appropriate prep is still important for a possible credible threat, even if it is likely to be a rare issue, and the magnitude of that prep differs by personal posture and exposure.