dlazar's comments

> It also opens the door to a “nightmare scenario”: That the two viruses will meet in a single person, swap their mutations, and create an even more dangerous strain of the SARS-CoV-2 virus.

How would that even work? This is an RNA virus: is there a meiosis-like mechanism for two different RNA viruses infecting the same cell to exchange genes?

I've been very happy with Binary Eye: https://f-droid.org/en/packages/de.markusfisch.android.binar...

Interesting, I hadn't realized pyrolysis (used to produce biochar) does not release CO2. Seeing "pyro" (Greek for "fire") I had assumed oxidation. Sounds like a good technique for making the wood "indigestible" for microorganisms. I wonder if it's worth doing energywise, compared with just burying it somewhere.

Also not a chemist, but here's my basic understanding.

The tree absorbs CO2 from the atmosphere and combines it with water (H2O) from the soil to produce more complex chemical compounds (such as carbohydrates). This process uses sunlight as the source of energy, and is better known as photosynthesis. The chemical compounds thus produced are used by the tree as structural material (the wood), or as stored energy (basically, reverting the photosynthesis reaction, aka "burning", releases the energy).

If the tree matter gets consumed by animals, those animals are going to use the stored energy, and ultimately re-release the stored carbon as CO2. If the tree just dies and is allowed to decompose, bacteria and other microorganisms will do the same: they'll eat the carbohydrates that the tree produced, and they'll breathe out the resulting CO2. If the tree is burned as fuel, the CO2 gets re-emitted directly.

So, to truly remove that CO2 from the atmosphere, the tree needs to be felled once it's stopped growing, and the resulting wood stored someplace where it can't be decomposed by microorganisms. Burying it is one solution to this (and this is what happened during the carboniferous era, when much of our coal and oil got created: dead trees fell in shallow swamps and were quickly buried under a layer of silt which prevented the decomposition).

Again, I'm no expert, so I'm happy to stand corrected if I've made any mistakes above.

Absorbing the photon would be a two-fer. Reflecting it is just starting the next two-fer. It's two-fers all the way down.

Only commenting on the coding style: that kind of formatting is just looking for trouble. Quick, tell me which of the functions below contains a bug?

  //return = strlen(target)
  unsigned strmcat(char *target, const char *source, unsigned length) {
    const char *origin = target;
    while(*target && length) target++, length--;
    return (target - origin) + strmcpy(target, source, length);
  }

  //return = strlen(target)
  unsigned strmcat(char *target, const char *source, unsigned length) {
    const char *origin = target;
    while(*target && length) target++; length--;
    return (target - origin) + strmcpy(target, source, length);
  }

How about this?

  //return = strlen(target)
  unsigned strmcat(char *target, const char *source, unsigned length) {
    const char *origin = target;
    while(*target && length)
      target++, length--;
    return (target - origin) + strmcpy(target, source, length);
  }

  //return = strlen(target)
  unsigned strmcat(char *target, const char *source, unsigned length) {
    const char *origin = target;
    while(*target && length)
      target++;
    length--;
    return (target - origin) + strmcpy(target, source, length);
  }

Granted, it's a tiny example, but you're going to be writing fewer bugs in the long run if you avoid being clever. So here are two rules to start with:

1. Never put more than one statement on one line.

2. Never use the comma operator outside the "for" syntax.

Please record these sessions and upload them to YouTube, so they'll help more than just one person. Thanks for volunteering.

I'm not sure what you mean by "scaling". Just because it uses a media query to serve a different style based on the screen size doesn't mean it "scales well".

In particular, this reacts quite badly to zooming, either in a desktop browser (chrome/linux): http://imgur.com/r1z9W or in a mobile browser (android): http://imgur.com/7aP39 .

In the desktop case, the font size doesn't change even if I zoom in the entire page. This isn't the default behavior, so the author must have gone to some lengths to break this functionality. I'm sure s/he had reasons for doing that, but I'm not sure what they were.

In the mobile case, zooming is constrained to a very limited range, and even when allowed, the text doesn't reflow, so it's hard to read lines because of all of the horizontal scrolling required. This behavior is quite common for fixed width, "grid" layouts.

In general, I'm all for frameworks that solve common layout problems, but this particular framework seems to have gotten the basics wrong. I would recommend against using it as it stands.

1) Please, NEVER EVER assume you know how the fonts will look on the users device. The iPhone is not the only "mobile platform" out there, and it doesn't even have the majority. Different phones will have different fonts, different default font sizes, different screen sizes, etc. As such "user-scalable=no" will guarantee people all over the world will hate you, including iPhone users who have a different opinion than yourself on what the "right font size" is. Just saying: "I'm using bigger fonts than on the web" will probably push you in the other extreme, with fonts too large and users unable to scale them down.

In conclusion: ALWAYS use "user-scalable=yes". Like this you'll give the user the option of correcting your assumptions if they turn out to be wrong.

Thanks for the article otherwise.