If you make the horns quiet enough for the nearby pedestrians, they'll be too quiet for other drivers to hear (since they're further away and the car is blocking a lot of the sound). And the driver might have the radio on, or even if not it's got to overcome the road noise.
If you make it the painful for the driver to use the horn, they just won't (which would maybe be better overall in cities, but then just remove the horn entirely). Or the sudden loud noise will surprise the driver, or make them instinctively cover their ears (i.e., remove both hands from the wheel). Neither of those would be good for safety.
So, unfortunately, not an easy problem.
In suburban and especially rural areas, the horn needs to carry further and there a few pedestrians. But I guess you could adjust volume by GPS location.
Maybe as well as an audiable signal a radio signal can be emitted. Cars hear this radio signal and play a horn inside to the driver. Eventually when this is supported by all cars the outside horn can be made quieter (just for nearby pedestrians) as penetration through a different car that is playing loud music is no longer an issue.
Of course the depreciation period for this is enormous.
A lot of these things do exist. Desktop/server Linux systems (used to at least) save some output from the PRNG to disk on shutdown and load it back on boot.
But of course snapshots, cloning, etc. can foil that badly, causing the same seed to be used multiple times. And on initial install you're not going to have any of that (but initial install is also when you may need to generate long-lived random numbers like ssh host keys).
Embedded devices it can be a real challenge. You must not re-use the seed data, so you effectively have to erase it from NVRAM/flash before use. But then if you lose power before you can generate a new one, you won't have one next boot. And you're adding flash writes, which decreases longevity and increases the chance of power failure in the middle of a write.
Qemu/KVM has a virtual RNG so you can feed host randomness into the guests if you want. So there are hypervisor calls available.
> "The population under 16 (not working) and population over 65 (more likely to be retired) are roughly equivalent right now, which means our workforce age should hew pretty close to our overall median age."
Yeah, except:
1. Many in the 65+ group are working. So you can't cancel that out with the under-16 crowd where basically none work (and it is—with a few exceptions—illegal for them to work, especially the younger ones).
2. Many in the 16–24 range aren't working, because they're full-time students. Especially the 16–18 crowd.
So you'd expect the median worker to be older than the median person.
Agreed, looking at https://www.bls.gov/emp/tables/civilian-labor-force-particip... it seems like it's just the media age of workers. There are almost as high a % of 65+ workers as 16-19 and more 45-54 year olds than 20-24. And 10% of the 75+ year olds are working, I sincerely doubt we have 10%+ participation in the <6 year old bracket.
Overall it looks like a demographic shift of more people going to school for longer (which is well known) and fewer students working.
A quick warning: be wary of that computation because of how it's likely made, and it's worse than higher the vaccination rate gets.
The sources section says:
> Sources: California Reportable Disease Information Exchange; California Department of Public Health, California Immunization Registry; the U.S. Census Bureau, 2015-2019 American Community Survey 5-Year Estimates.
So the the numerator (number of cases) from the reportable disease database and/or department of health data (which probably includes vaccination status, or alternatively is matched against the registry). The denominator for the rate amongst the total population is the population estimate from the census bureau. The denominator for the rate amongst vaccinated comes from the immunization registry.
The rate against the unvaccinated? There is no count of them, so instead you subtract the number vaccinated from the population. The problem is that both of those are estimates, and as they get closer the error on that denominator goes through the roof. So the rate amongst the unvaccinated becomes meaningless.
As an example, take a hypothetical place with around 100 people. Might actually be anywhere from 98–102, that is ±2%. If you've got a very high vaccination rate (yeah!), say there are 96 people on the immunization registry. You could have anywhere from 2 to 6 people unvaccinated. You'd report 4, but the error is now ±50%, which is huge. And when you use that as the denominator, you get very different answers. (OTOH, of half the village was unvaccinated, 50±4% is a much smaller error!)
Yes, this is a good point. On the other hand, while S.C.C. has a high vaccination rate, it's not high enough that a small population uncertainty makes such a huge difference.
The amounts are in US dollars, so any local hyperinflation won't matter. Your local currency will be worth far fewer dollars.
I didn't see if it says how to convert, as there are often multiple exchange rates, e.g., an official one that can't actually be used, a underground/black market one, and purchasing-power parity (PPP). I don't think use outside the rich, developed nations has really been considered.
The mail command has been around for a while, and was intended mainly for human use, not scripts.
For example, just run mail alone with no arguments. It'll display the messages in your local mail box, and prompt you which ones to read, keep, delete, reply to, etc.
The mail command is an MUA, just like mutt or Thunderbird, but much older.
For extra fun, there are (or at least were) multiple implementations of the mail command. The arguments were similar enough, but an old (and replaced) system at a previous employer required Heirloom mail/snail, not BSD because it actually intentionally used escape sequences like this.
In particular, it used one to add attachments (by giving the path).
We replaced it with Perl, getting rid of the shell script entirely (the whole stack was Perl).
Shell scripts really ought to use the sendmail command to send mail, but then you have to remember those obscure options to pass and generate the mail headers yourself, so it's understandable why no one does. (And probably handle dot-doubling).
Dehumidifiers are ACs, just with the condenser indoors and exhausting heat back into the cooled air stream (so heating the room overall).
A particular dehumidifier can (of course) be more or less efficient than a particular AC system. But it's probably more efficient, given similar technology, if you want a drier, warmer room.
Hardly ever want that warmer room bit during the Southeast US humid season. So you'd wind up running the AC too, to exhaust the excess heat (including the extra heat from the dehumidifier).
I'm specifically only thinking about the case where you run an AC while not at home. By all means, run your AC if you are at home and need to manage the temperature.
If you make it the painful for the driver to use the horn, they just won't (which would maybe be better overall in cities, but then just remove the horn entirely). Or the sudden loud noise will surprise the driver, or make them instinctively cover their ears (i.e., remove both hands from the wheel). Neither of those would be good for safety.
So, unfortunately, not an easy problem.
In suburban and especially rural areas, the horn needs to carry further and there a few pedestrians. But I guess you could adjust volume by GPS location.