The article describes middle games as "'middle game' should only take 1 to 9 months to create and can be profitable (or at least not a money sink) because it is expected to earn in the range of $10,000 to $40,000."
Am I understanding that right?
A reasonably competent developer could make at least twice that in salary, with far less risk. So that's not really profitable, once you remember opportunity cost (and especially if you risk-adjust it).
The ones that take a few days can be a weekend project. The longer projects you'd be hoping become huge, and very profitable.
I don't know if it'd really be hard (you could list them, or have various limits on users or total revenue among all related companies). You could broadly include all subsidiaries, contractors working for Amazon, companies effectively under their control, etc. (Ultimately it'll be interpreted by a judge, not an algorithm, that probably makes it harder to get around.) There is nothing illegal about offering a license to everyone except Amazon, Microsoft, and Google.
But none of those licenses would be open source licenses. That's the problem with doing it — you can't do that in an open source license.
The no discrimination clauses are a requirement of the open source definition, not the law. (The law of course does have some non-discrimination requirements, not sure how many of those apply to copyright licenses. But none of the normal ones would prohibit "everyone but Amazon may use this".)
Some unarchivers (especially ones which aren't Unix natives, like say rar) seem to love to do it. They're just buggy, of course.
Beyond that, before the mid-2000s, it was common to use non-UTF-8 locales on Linux. So I'm sure I still have ISO-8859-1/—15 encoded file names somewhere, especially in archived data. They're not always trivial to rename either, because there might be references to them by name. (Or, in odd cases, you can't convert the name to UTF-8 because you hit a filename length limit, since UTF-8 is more bytes).
I believe wanting to access data from 20 years ago is a perfectly reasonable use case.
It's not so bad if a program can't display the file name right, as long as it doesn't crash with an exception or refuse to open the file. Unix file names have been defined as arbitrary sequences of octects except / and NUL for 30+ years.
Because then you have to transport the wood to the site, transport the ash (etc.) off the site, and build something useful to do with the produced energy. Most of that would be trucks or ships if it's on a navigable waterway.
Oil and pipeline companies are building pipes to move gases because it is the cheapest way to do it.
A lot of email clients support multiple email accounts, or at least sending addresses. Not just desktop ones like Thunderbird, but web ones like Gmail too.
You can additionally set up email to be forwarded (or retrieved). So, for example, you can easily have your [email protected] account forwarded in to Gmail and Gmail set up to send from that address.
That works fine if the site sends a confirmation email, it'll get to Gmail where the user expects to read it. But the other way around will give the user errors about having the wrong email (even if tj user picks the right outgoing address, because you won't be able to verify it), and ultimately cause the user to give up or you're going to have to spend a lot of time supporting all kinds of weird email configs.
I think airplane mode is intended to comply with the rules for using the device on an airplane. That used to be no radios whatsoever (and device turned off during takeoff and landing).
The rules on aircraft changed, so the feature was updated.
Unfortunately, high beams also risk blinding oncoming traffic, potentially causing a collision.
In addition, I wonder if the blinking would be distracting, calling attention away from the problem (at least when the horn is being used as intended, not just by someone complaining about slow traffic).
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.
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.
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!)
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).
Until then, I'm not sure if there is anything lightweight. If you don't need lightweight, there is Podman.