> I began my research by looking for some kind of hard plastic case.
I used to ship micro-sd cards in plastic cases through the mail, here in the UK. At first I used standard DL (letter) envelopes, since they are cheap and the case inside the envelope didn't push it over any depth size limits.
However, when I got two angry support emails for having sent them "empty envelopes", I had to ask them for photos, which both showed a small sd-card-case sized hole along one short edge, with some tell-tale marks. What was happening was the leading edge of the envelope was going through some kind of thinly-spaced rollers, pushing the case to the rear end of the envelope, and then the rollers had such a grip on the envelope that they squeezed the sd card out through the corner of the envelope like a squeezing a pip out of a lemon.
So I had to move to padded envelopes, which were then a more consistent depth over the whole length of the envelope, and so they worked fine in the mail machines. But that upgrade ate into my margins since I was only working on a small scale.
It's little details like these cause vague statements like "It is normally recommended to use bubble wrap to protect SD cards in transit" - lessons learned the hard way!
Why not put them in a plastic bag or Electrostatic bag and then tape them to cardboard? That seems like it would solve most of the problems cheaply without adding a lot of thickness to the envelope?
Hostmonster (a Bluehost brand) have been the worst, since they were so blatant about it. I'd only had legitimate correspondence to that address, until the week I cancelled my account, and since then the spam has been relentless. So as part of my account cancellation, they clearly sold my email address on.
The most amusing was the UK Parliament petitions site, since you would have thought they were a bit more careful with the email addresses given to them.
But the strangest is the persistent use of specific email addresses that I've never used anywhere - about half a dozen common forenames, and one forename-plus-three-numbers. I've no idea where they originally came from - perhaps someone padding out their email lists for sale with semi-randomly generated ones? - but that set of addresses has been used and reused for over a decade. At least it makes it easy for me to train spam filters, since even novel emails are easy for the filters to spot when multiple copies arrive together.
I had a lot of spam sent to the email I used to register with French consulate. It's registered as part of the electoral lists so all candidates can get access to that email and they don't have the best security (including one candidate who would cc 200 people from the list on each of his emails)
Carbon capture is necessary in the long term, for particular emissions that are hard to avoid (like specific industrial processes and parts of agriculture). But while we're still pumping out emissions that can be easily and cheaply displaced today, like coal and gas fired grid electricity, then the money being spent on carbon capture is being spent terribly ineffectively. And globally, we don't have the time or money to waste.
For example, most electricity grids are still partially carbon-intensive, despite renewable sources being cheap and available and in use. Simply buying some more solar panels and hooking them to a carbon-intensive grid will displace coal or gas emissions by the following lunchtime, far more cost-effectively than any form of carbon capture.
I understand the principle on working on research projects that have a long lead time. But Stripe should treat carbon capture as such, and could have a more cost-efficient climate strategy: put most of this money today into the most cost-efficient solutions available today, rather than putting its entire budget into the least cost-efficient solution.
> But while we're still pumping out emissions that can be easily and cheaply displaced today, like coal and gas fired grid electricity
Coal and gas fired electricity can be easily and cheaply displaced today? Then why isn't it? I was under the impression that we needed coal + gas still because it wasn't easy or cheap to meet the energy level needs of today with alternatives.
We could have displaced them almost entirely in the 60s and 70s with nuclear, and we can do so today with renewables and nuclear. We haven't yet because it turns out oil and gas are pretty profitable, and climate change became a recognized issue just as the US was moving toward a more laissez-faire style of governance.
We can't currently displace oil usage for certain fuels, but we can start creating it from renewable sources using the carbon-free energy sources to power the process. Basically convert nuclear energy (via uranium or the Sun) into chemical energy.
The price of wind and solar is coming down so fast that what didn't work in 2015 is perfectly feasible in 2020. My town's sustainability plan was developed in 2014, passed in 2020 and it's already obsolete. Many organizations are planning today based on data that is already out of date.
Well, it can easily be displaced at low market penetration for wind/solar. At high levels, like well over 50%, storage cost starts to be a serious issue.
When it comes to long-term technologies, they just don't become ready when you need them. We need to start investing in them today so they're ready when we need them to operate at scale.
One thing to consider is that "carbon capture" can be a good stopgap approach to long-term energy storage. For example, use the extra sunlight in the summer to run carbon capture, and then on shorter winter days burn fossil fuels.
Carbon capture methods already exist, they're just not sexy, profit-generating, or tech-based.
Example: Raise fast-growing forestry (e.g. pine), harvest it, then bury in deep pits. Repeat. The buried carbon will release just ~3% back to the atmosphere in a decade. The sequestration potential of this technique alone is significant, of the kind of scale we need to tackle the issue. All of the fields of knowledge we need to execute on it (forestry, landfill, mining) are well-developed today.
Pretending it's a problem with no existing solutions is a ploy to secure investments and diverts attention from action that could be taken today. But, of course, there's no money in that.
You're right, but it's a lot harder to account for emission reduction, and offsets based on those are often illusory. For example, you might award carbon offsets for replacing a coal plant with solar, when that would have happened anyway just because the economics worked out better. If you're actually removing carbon from the atmosphere, that's not an issue.
As a matter of government policy, we definitely need to focus on reducing emissions, and a simple way to do that is with a carbon fee. But for voluntary contributions right now, it's not so clearcut.
> you might award carbon offsets for replacing a coal plant with solar, when that would have happened anyway just because the economics worked out better
It depends on which organisation verifies your offset, but the big three (Gold Standard, Verra VCS, and United Nations), all require _additionality_. That is where you have to prove that the offset financing is making the project happen, rather than market forces.
It’s not a flawless process, but in many cases offsetting is helping to accelerate the transition away from carbon intensive emitters.
I can really recommend using HSLuv for this kind of thing. I used to use regular RGB values (like #f2cdaa), but it's hard to make features on the map "a bit less blue" without accidentally changing other properties. For example, changing #f2cdaa to #f2cd88 makes it less blue, but also darker.
So a few years ago I switched to using HSL in our stylesheets (and using the HSL tab in the Inkscape colour picker) which makes it easier to reason about the colour changes. But there's still some problems with HSL, as the article describes. For example when choosing road colours, I often want to keep the saturation and lightness the same, but when I make minor roads yellow the change in hue really changes the perceived brightness in HSL.
So HSLuv is great for what I do, since I know that if I get the brightness and saturation of the roads the way I want, I can mess around with the hue without any side effects. Or if I like the colour of the forests but want them slightly less saturated, again no side effects when I make changes.
The big drawback is that there aren't many colour pickers available in HSLuv, mainly just the one on https://www.hsluv.org/ . I haven't found e.g. HSLuv colour picker plugins for Inkscape or the GIMP yet.
I dislike strongly the look and feel of most Thunderforest maps. It may look "modern" but when you want to actually read a map, having light green symbols on a slightly lighter green background is ridiculous.
It's worth specifying that if they've lumped them in with the UK, since the Channel Islands and the Isle of Man aren't actually part of the UK. Heck, they aren't even part of the EU either.
I've been doing this for a few years, along with a reasonable minimum font size. I find it really tough to go back to a smorgasbord of fonts and sizes, with some of them often unreadable. Controlling the fonts via Firefox is awesome.
The biggest downside to this is where sites (e.g. github) try using private-range unicode codepoints for graphical icons, not realizing that users often have other fonts set. I really discourage site authors for hacks and stick to using graphics for icons.
The problem with your first command is the "cut" - works great for a while. Then you deal with other_vhosts_combined.log, and there's a leading hostname and port, so you want -f2 instead. After that, you start working with the user-agent field, and after remembering that the date and request fields have internal spaces, settle for something like -f13, which works until someone puts a space in their faked-up referer, and you can't use cut any more.
I love plain-text logs, but that apache logformat is a bad example of "neatly delimited records", given the unstable mixture of spaces between and within fields (some of which are quoted, some not, and one even quoted with square brackets!).
I used to ship micro-sd cards in plastic cases through the mail, here in the UK. At first I used standard DL (letter) envelopes, since they are cheap and the case inside the envelope didn't push it over any depth size limits.
However, when I got two angry support emails for having sent them "empty envelopes", I had to ask them for photos, which both showed a small sd-card-case sized hole along one short edge, with some tell-tale marks. What was happening was the leading edge of the envelope was going through some kind of thinly-spaced rollers, pushing the case to the rear end of the envelope, and then the rollers had such a grip on the envelope that they squeezed the sd card out through the corner of the envelope like a squeezing a pip out of a lemon.
So I had to move to padded envelopes, which were then a more consistent depth over the whole length of the envelope, and so they worked fine in the mail machines. But that upgrade ate into my margins since I was only working on a small scale.
It's little details like these cause vague statements like "It is normally recommended to use bubble wrap to protect SD cards in transit" - lessons learned the hard way!