derobert

It looks like systemd-nspawn is gaining rootless support, see https://github.com/systemd/systemd/issues/30239

Until then, I'm not sure if there is anything lightweight. If you don't need lightweight, there is Podman.

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.

Here you probably want fanotify, not inotify. The later would require setting up a lot of inotify entries, recursing through the filesystem.

https://man7.org/linux/man-pages/man7/fanotify.7.html

I think fanotify does xattrs, but I haven't tested.

It's easy enough to confirm. You can go to weather.gov and get current conditions anywhere in the US.

https://forecast.weather.gov/MapClick.php?textField1=40.02&t...

Currently 14% humidity in Boulder, CO.

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 me@example.com 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.

For high school, the youngest of which are 14, probably closer to 15? That really doesn't seem like a requirement.

Well, except when they have to get out the door before 6:15am...

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.

Thankfully, there is no need to speculate on what the trend might be, you can just look it up.

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).

Errr, we're off to a good start!

"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.

If you look for canning / pickling salt, that should be free of both iodine and anti-caking agents.

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).

A couple spring to mind

* most every fire department * many public school systems * as far as federal agencies, transportation, NASA, NSF, Medicare, to varying extents.

For it being essentially impossible, its sure been done a lot: Netflix, MindGeek (NSFW), and Amazon definitely have at least as large video streaming (especially with Amazon now owning Twitch). There are a lot of large, though not really global, ones too (e.g., in the US there is Hulu, CBS, HBO, various sports, etc.). I'm not sure how big Facebook's video streaming (probably fairly large, considering its Facebook). Smaller YouTube-like sites exist; for example Vimeo is still around.

Building a video hosting site costs a lot less than billions. Unless you have YouTube's traffic, you don't need their capacity.

When a database is just functioning as your (relatively monolithic) application's data store, validation on the app side works well. The app is the primary—maybe only—product.

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.

Which means you burn more calories, so eat more food, which has to be grown — and farming uses fuel too (and transporting, storing, & selling that food, and cooking it, and...)

Calculating the full, e.g., carbon cost of a fuel is difficult!

Check out MusicBrainz for metadata. E.g., https://musicbrainz.org/artist/1be1367d-119f-4b08-bdfe-50b95... (Nielsen's artist page) or e.g., https://musicbrainz.org/release/d757ff3a-5502-4e86-952e-dc1e... (an album page) — note all the classical metadata.

Further — the data is licensed freely, and there is an API to get at it all; no scraping needed.

I guess you've never checked ~/.mozilla/firefox/YOUR-PROFILE/places.sqlite which includes a record, including date & referer, for every time you visit a site. See https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Places... for documentation (or http://www.forensicswiki.org/wiki/Mozilla_Firefox_3_History_... for unofficial documentation). Several hundred thousand rows here...

That's basically what you do—you send the correspondence via certified mail, and keep the certified mail receipt. That doesn't prove what you mailed, but it gives verification that you sent something. (You purchased something from Equifax on the 1st, sent them a certified letter on the 10th. You claim it was the arbitration opt-out; they had better have some evidence it wasn't, or the judge/jury is probably going to believe you.)

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.

It is linked from the banner up top of https://www.equifax.com/personal/

"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.

The 3.x is still updated, but they're replacing it soon. 4.x is a WebExtension, with a different UI.

See https://blog.lastpass.com/2017/03/plans-to-retire-the-lastpa... for details.