I have auto redirect to 443. But --nginx works fine. I think it overrides stuff for whatever the specific url used is.
r00ty
There's a certbot addon which uses nginx directly to renew the certificate (so you don't need to stop the web server to renew). If you install the addon you just use the same certbot commands but with --nginx instead and it will perform the actions without interfering with web server operation.
You just then make sure the cron job to renew also includes --nginx and you're done.
It makes sense that they issue short certificates, though. The sole verification is that you own the domain. If you sell/let the domain lapse and someone else takes it over, there's only a limited time you would hold a valid certificate for it.
You realize there's 8 billion people on the planet? The majority of people either didn't (or luckily for them still don't) know who this guy is.
Now I'll upset some people here, I'm sure but...
Here in the UK, you can see how decent an area is using this method.
Go to the nearest Tesco Extra. If they have the coin traps on the trolleys, probably a dodgy area. If they don't, not so dodgy area.
In both cases, you're going to find the trolleys are generally not left lying around. Read into it what you will.
I only use Tesco extra as an example because from my experience other supermarkets either have the coin traps, or don't. It seems only Tesco (correct me if I'm wrong) vary the behaviour by area.
Can you post a picture of yourself here so we all know to just leave you to die, if we ever see you in medical distress.
TIA.
I think this overall is a better idea. I'm going to say this because, I thought I'd look into rust today. So I installed it, setup vscode to work with it etc. And it's all up and running. I thought I would port over a "fairly simple" C# project I wrote recently as a bit of a test.
While I've generally had success (albeit with 30+ tabs open to solve questions I had about how to do certain things, and only making it about 20% into the task) I'm going to say that it's different enough from C, C++ and C# (all of which I can work with) that I really don't think it is fair to expect C developers that have day jobs and work on the kernel in their spare time to learn this. It's fundamentally different in my opinion.
Now, I don't condone any bad attitude and pushing away of rust developers from the project. But there's no way they're going to want to do anything to help which involves learning a new language. It's just not going to happen.
Likewise, C is not a language most new developers are learning. So, I feel like over time there won't be so much of an influx of new kernel developers and any Rust based kernel could find itself with more contributors over time and taking over as the de-facto kernel.
In terms of Redox (not looked into it yet). So long as there's a different team working on the userspace tools. I would say the main task should be getting a solid kernel with drivers for most popular hardware etc in place. The existing GNU tools will do until there's a kernel that is able to compete with the C one. But that's just my opinion.
Ah, so the kind of crypto bro, that instead of a fistbump, does a diffie-hellman key exchange instead?
Here's what I think. Both opinions are correct.
Rust is sufficiently different that you cannot expect C developers to learn rust to the level they have mastered C in order to be working at the kernel level. It's not going to happen.
I don't really know too much about rust. Maybe one day I'll actually mess around with it. But the one time I looked at a rust git repo I couldn't even find where the code to do a thing was. It's just different enough to be problematic that way.
So I think probably, the best way IS to go the way linus did. Just go ahead and write a very basic working kernel in rust. If the project is popular it will gain momentum.
Trying to slowly adapt parts of the kernel to rust and then complain when long term C developers don't want to learn a new language in order to help isn't going to make many friends on that team.
That's got to be extremely rare. Not much you can do in that case. But they will hit many problems with that approach.
Lithium batteries have a very high energy density. When that's released all at once with a short circuit or very high current draw resulting in thermal runaway, that's when these fires start. The great news is, they're self fuelling fires too!
But, most reputable manufacturers, create charging/protection circuits that protect the batteries against such situations. Making them far less likely (but still possible) to happen.
The problem you're going to get is when there's disreputable companies, operating in countries with less stringent safety laws that are operating the production, processing and shipping entirely outside of the sight of countries with safety rules. Well, then you get a product with a fake FCC/CE sticker on it, that is very dangerous indeed.
I will not buy electronics from those sites for this very reason. Batteries, chargers and power supplies are usually very shoddy from these companies.
It's not to say don't buy stuff made by country X. Because there's plenty of stuff I have bought made in, these countries but sold by companies that DO make sure there's some testing done, and they're not fake stickering everything. But, we all know the companies I'm talking about I think. Also, ebay (because private sellers buy in bulk from these places and then resell them) is something to be careful of too.
Instructions unclear, VPN'd into my own home network.