I'm curious what you mean about the nature of the population?
Age? Ethnic makeup? Urbanisation?
The population is older, less white, more in cities, fewer kids, but I'm not sure what any of that has to do with our water consumption or ability to build for it - other than maybe older people, especially the ones that moved out of the cities to live some LOTR-inspired faux-rural lifestyle, tend to be more NIMBY?
But equally though our appliances and lifestyles aren't the same as 1960. Showers are massively more efficient than baths, but we use them daily instead of once a week. Industry has mostly disappeared, and thermal power stations are on the way out (both extremely heavy water users), but agriculture has become more intensive.
This is efficient if you actually _need_ hundreds or thousands of units.
Which was clearly the case in WW2.
And _might_ be the case if the confrontation with China is proxy wars. Hundreds or thousands of spare units (of tanks, AA, helicopters, fighter jets) would be useful in Ukraine, for example.
But it's hard to see a use-case for hundreds of B-2s, for example. By the time those things are flying in anger, twenty or thirty will do everything you're ever going to do.
> But it's hard to see a use-case for hundreds of B-2s, for example.
Sell them to allies. But ever since both Trump and Biden seriously restricted Ukraine from defending itself... let's say the US isn't among the most trusted arms suppliers these days. A lot of soft power, just gone.
CPR is mostly an emergency intervention to keep someone critically ill (from trauma or other acute medical emergency) alive long enough to get them to the ER.
If someone needs CPR at all, the chance of being able to fix the underlying cause of their cardiopulmonary arrest on a space station is infinitesimal.
I agree CPR in that situation is probably limited value. I bet you can find their procedure manual online, but on station, the victim would only be a few meters from a defibrillator and drugs to fix the problem. The ER is some 12 or 24 hours away.
Sometimes, doing something common but with different conditions may be enough to trigger unexpected insights. Maybe it won't save anyone in space but we could still get new knowledge or tech that proves valuable somewhere else. Not claiming it has the highest expected value, just that it's not automatically useless.
CPR is a violent process - the rib cage normally prevents the type of manipulation of the heart necessary for CPR to work. Broken ribs are pretty much an essential side effect for adults if done correctly. It’s typically only done on folks who are dead and unresponsive at the time, to try to keep their brain alive until they can get more sophisticated help. The so called ‘golden hour’ (which really is the golden 15 minutes/5 minutes if you look at success rates).
What sort of response time are we talking about from the ISS in a medical emergency? I would be shocked if it was less than a day.
They’re probably better off with a whole lot of drugs, an ultrasound, and a defibrillator. But hey, if they can afford the weight and already have those things, a cpr machine would help keep blood flowing while they try to figure things out.
Ground control has Doctors that can walk them through pretty much anything they might want to do.
It's worse than that. The patient is forced by the compressions to vomit. In zero-G, that means the highly acidic contents of their stomachs are now several forcefully-ejected packets of goo.
Forget the dreaded conductive pencil-lead shavings; that stuff is going to cause problems to hardware and wetware alike!
Good point, also rather extreme aspiration risk probably? I don’t know how you would clear their airway unless you also had a suction device. Gravity certainly isn’t going to help.
Even though the system rules and I/O are tightly constrained, they're still struggling to match human performance in an open-world scenario, after a gigantic R&D investment with a crystal clear path to return.
Fifteen years ago I thought that'd be a robustly solved problem by now. It's getting there, but I think I'll still need to invest in driving lessons for my teenage kids. Which is pretty annoying, honestly: expensive, dangerous for a newly qualified driver, and a massive waste of time that could be used for better things. (OK, track days and mountain passes are fun. 99% of driving is just boring, unnecessary suckage).
What's notable: AVs have vastly better sensors than humans, masses of compute, potentially 10X reaction speed. What they struggle with is nuance and complexity.
Also, AVs don't have to solve the exact same problems as a human driver. For example, parking lots: they don't need to figure out echelon parking or multi-storey lots, they can drop their passengers and drive somewhere else further away to park.
It wasn't actually just terrain. It was actually availability of draft animals, climate conditions and actually most importantly... economics.
Wheeled vehicles aren't inherently better in a natural environment unless they're more efficient economically than the alternatives: pack animals, people carrying cargo, boats, etc.
South America didn't have good draft animals and lots of Africa didn't have the proper economic incentives: Sahara had bad surfaces where camels were absolutely better than carts and sub Saharan Africa had climate, terrain, tsetse flies and whatnot that made standard pack animals economically inefficient.
Humans are smart and lazy, they will do the easiest thing that let's them achieve their goals. This sometimes leads them to local maxima. That's why many "obvious" inventions took thousands of years to create (cotton gin, for example).
IMO what's needed is less per-app sandboxing, and more per-context.
Think user accounts but for task classes.
If I'm doing development work, I want to be able to chain together a Frankenstein of apps, toolchain, API services and so on, with full access to everything else in that specific context.
But that doesn't need visibility of my email, my banking and accounting software should have visibility to/from neither, and random shareware apps, games and movies should run, like you say, with a browser tab level of permission.
Making this work in practice while keeping performance maximised is harder than it sounds, preventing leaks via buffers or timing attacks of one sort or another (if apps can take screenshots, game over).. for now I use user accounts, but this is becoming less convenient as the major desktop OS and browser vendors try to force tying user accounts to a specific online identity.
> IMO what's needed is less per-app sandboxing, and more per-context.
I think you could do this with capabilities!
The current model makes of security implicit, where an application can make any syscall it wants and its up to the OS to (somehow) figure out if the request is valid or not. Capabilities - on the other hand - restrict access of a resource to the bearer of a certain token. The OS knows that by invoking capability X, the bearer can make requests to a certain resource / account / file / whatever. (Think of it like unix file descriptors. You just call write(1, ...) and the OS knows what file you're writing to, and what your access to that file is.)
There's lots of ways to use capabilities to build the sort of frankenstein app you're talking about using caps. Eg, you could have a supervisor task (maybe the desktop or a script or something) that has a capability for everything the user cares about. It can create sub-capabilities which just have access to specific network ports / files / accounts / whatever. It launches subprocesses and hands the right capabilities to the right sub processes. The sub processes don't even need to know what the capability they were given connects to. They just need to know - for example - that reading from the capability gives it the data it expects to receive. Then you can do all the routing & configuration from the supervisor task.
Because all the sub processes only have the specific capabilities that were passed to them, the security surface area is automatically minimised.
SeL4 shows that you can do this without losing much performance. (In SeL4, the IPC overhead is tiny.) But as I said upthread, I'm sure there's also ways to design our programming languages to allow within-process isolation. So, for example, you can call the leftpad package without giving it capabilities held by other parts of the same program.
Capabilities can also make it easy to virtualise filesystems, the network, and so on. Or to do interdiction - and snoop on the messages being sent. Its easy because you can just make virtual network / filesystem / whatever capabilities and pass those to subprocesses.
Half true. You can switch to the mode of not needing to go halfway around the world (or even just across the country) so often, because efficient information flows allow you to accomplish vastly more while mostly staying relatively local.
Sure, we all like to complain about burrito taxis, dating apps and endless Zoom calls, but in terms of quality-of-life per unit of energy, it's a step change.
Age? Ethnic makeup? Urbanisation?
The population is older, less white, more in cities, fewer kids, but I'm not sure what any of that has to do with our water consumption or ability to build for it - other than maybe older people, especially the ones that moved out of the cities to live some LOTR-inspired faux-rural lifestyle, tend to be more NIMBY?
But equally though our appliances and lifestyles aren't the same as 1960. Showers are massively more efficient than baths, but we use them daily instead of once a week. Industry has mostly disappeared, and thermal power stations are on the way out (both extremely heavy water users), but agriculture has become more intensive.