derobert
Until then, I'm not sure if there is anything lightweight. If you don't need lightweight, there is Podman.
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.
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".)
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.
Oil and pipeline companies are building pipes to move gases because it is the cheapest way to do it.
https://man7.org/linux/man-pages/man7/fanotify.7.html
I think fanotify does xattrs, but I haven't tested.
https://forecast.weather.gov/MapClick.php?textField1=40.02&t...
Currently 14% humidity in Boulder, CO.
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.
The rules on aircraft changed, so the feature was updated.
Well, except when they have to get out the door before 6:15am...
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 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.
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.
https://fred.stlouisfed.org/series/MTSDS133FMS
That's one convenient way to get this data series (and most other economic data, at least for the US).
> "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.
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!)
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.
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.
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).
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).
* most every fire department * many public school systems * as far as federal agencies, transportation, NASA, NSF, Medicare, to varying extents.
Building a video hosting site costs a lot less than billions. Unless you have YouTube's traffic, you don't need their capacity.
But if you have multiple apps sharing the same data, or the app is a bunch of different things from many years glued together, etc., then there is no longer "the" application side. You'd have to write validation on multiple application sides, and make sure they all agree. The data is at this point often more important than a single app.
Even with single-app data stores, if you ever have to use the SQL prompt directly (say, to do a one-off change that it doesn't make sense to write an app feature for, or time doesn't permit doing so) it's nice to have all the constraints specified in the database.
Calculating the full, e.g., carbon cost of a fuel is difficult!
Further — the data is licensed freely, and there is an API to get at it all; no scraping needed.
Honestly for this (the Equifax thing), you just keep record of when you sent it—it's only an issue if you litigate, and then I'd expect your record of when you sent it + your testimony would be sufficient. But IANAL, and you should of course talk to one if it matters.
For your HOA, hopefully you have some record of when you sent the request (e.g., you kept a copy of the ARC application with a note that you mailed it on $DATE). (Of course, the HOA should be maintaining records of when applications are received.) Depending on what it is, this is something that may be worth paying for legal advice on.
"Equifax Cybersecurity Incident: To learn more about the cybersecurity incident, including whether your personal information was potentially impacted, or to sign up for complimentary identity theft protection and credit file monitoring, click here"
and that "click here" goes to http://www.equifaxsecurity2017.com/
So it'd seem legit, if rather silly to have its own domain.
See https://blog.lastpass.com/2017/03/plans-to-retire-the-lastpa... for details.