Port 22 is the default SSH port and it receives a TON of malicious traffic any time it’s open to the whole internet. 20 years ago I saw a newly installed server with a weak root password get infected by an IP address in China less than an hour after being connected to the open internet.
With all the bots out there these days it would probably take a lot less time if we ran the same experiment again.
I don’t understand why Cloudflare gets bashed so much over this… EVERY CDN out there does exactly the same thing. It’s how CDN’s work. Whether it’s Akamai, AWS, Google Cloud CDN, Fastly, Microsoft Azure CDN, or some other provider, they all do the same thing. In order to operate properly they need access to unencrypted content so that they can determine how to cache it properly and serve it from those caches instead of always going back to your origin server.
My employer uses both Akamai and AWS, and we’re well aware of this fact and what it means.
Doesn’t prevent Amazon from occasionally sticking smaller packages in our mailbox…
My only problem is our driveway is 700 feet long, uphill & through trees. I seriously doubt my WiFi reaches it…
Our house has 5 heating & 2 AC zones that I installed Ecobee thermostats on. Three rooms also have skylights that can be opened. When we open the skylights the thermostats all turn off, and when closed they turn them back on to the mode they were previously set to.
Our house is set back in the woods on a long driveway. When either me or my wife arrives home after dark all the driveway / walkway lights turn on. And when we’re both away they all turn off.
I also have a “bedtime” button on my phone that turns off all the lights, locks the doors, turns off our WiFi speakers, puts all the Ecobees into sleep mode, etc.
As far as BitTorrent itself goes, your optimal speed is also going to depend a bit on your client and the number of peers in the swarm.
Suppose you’re seeding a file to 3 peers. It’s not very efficient if your client uploads part 1 of your file to each peer, then uploads part 2 to each peer, etc. A more optimized upload would upload part 1 to peer A, part 2 to peer B, part 3 to peer C, etc. Then the peers can share each of those parts with each other. This way you are effectively only uploading the file one time before other nodes start seeding as well.
The thing is, this sort of seeding only works well in specific situations, including when there’s only one seeder, etc. And not all clients support this. Take a look at qbittorrent’s super seeding option for an example of one client that does.
Sue the mine in China that supplied the raw materials that went into the dielectric material in the capacitors in the power supply of the computer that facilitated the downloading of illegal content….
deleted by creator
I use .home for my home network…
Here’s the relevant part of one of my automations. It’s for a light sensor I have attached to my washing machine:
trigger:
- platform: state
entity_id:
- binary_sensor.washer_light_sensor_sensor_state_any
from: "on"
to: "off"
I had a similar issue with other zwave sensors. With a little help I was able to refine my triggers so that my automations only run when they go from an “off” state to an “on” state. Before that they’d trigger from a “none” or “unknown” state, which is what happens when HA or zwave2js restarts.
Pretty much the same here, but in a linode vps that hosts a few other things as well.
My employer had an EV cert for years on our primary domain. The C-suites, etc. thought it was important. Then one of our engineers who focuses on SEO demonstrated how the EV cert slowed down page loads enough that search engines like Google might take notice. Apparently EV certs trigger an additional lookup by the browser to confirm the extended validity.
Once the powers-that-be understood that the EV cert wasn’t offering any additional usefulness, and might be impacting our SEO performance (however small) they had us get rid of it and use a good old OV cert instead.