Seeing as you have not done that yet, it would appear that voting would be, well, more than you have done :) How do you justify your complacency and subjugation to the system you pretend to loathe?

Lmao I kept thinking you forgot to put quotes and was waiting for the inevitable "...this is what too many idiots think, even though it is obvious bullshit", and yet it just...never came. Amazing. This might be the single most stupid comment I've ever read, and I've been on the internet for a while.

Is this about the straight werewolves author?

You will simply not be able to install anything, unless the FOSS dev is cool with providing their ID to Google, and agrees to its ToS, and Google likes the app and signs it.

Which many devs (myself included) will definitely NOT be.

Eternity is a loooooong time

TBH, it sounds like you have nothing to worry about then! Open ports aren't really an issue in-and-on itself, they are problematic because the software listening on them might be vulnerable, and the (standard-) ports can provide knowledge about the nature pf the application, making it easier to target specific software with an exploit.

Since a bot has no way of finding out what services you are running, they could only attack caddy - which I'd put down as a negligible danger.

My ISP blocks incoming data to common ports unless you get a business account.

Oof, sorry, that sucks. I think you could still go the route I described though: For your domain example.com and example service myservice, listen on port :12345 and drop everything that isn't requesting myservice.example.com:12345. Then forward the matching requests to your service's actual port, e.g. 23456, which is closed to the internet.

Edit: and just to clarify, for service otherservice, you do not need to open a second port; stick with the one, but in addition to myservice.example.com:12345, also accept requests for otherservice.example.com:12345, but proxy that to the (again, closed-to-the-internet) port :34567.

The advantage here is that bots cannot guess from your ports what software you are running, and since caddy (or any of the mature reverse proxies) can be expected to be reasonably secure, I would not worry about bots being able to exploit the reverse proxy's port. Bots also no longer have a direct line of communication to your services. In short, the routine of "let's scan ports; ah, port x is open indicating use of service y; try automated exploit z" gets prevented.

I am scratching my head here: why open up ports at all? It it just to avoid having to pay for a domain? The usual way to go about this is to only proxy 443 traffic to the intended host/vm/port based on the (sub) domain, and just drop everything else, including requests on 443 that do not match your subdomains.

Granted, there are some services actually requiring open ports, but the majority don't (and you mention a webserver, where we're definitely back to: why open anything beyond 443?).

They are still being being painted by hand. On a graphics tablet, for example.

• if your skill is so great that you would never cause the kinds of bugs the rust compiler is designed to prevent, then it will never keep you from compiling, and therefore your complaint is unnecessary and you can happily use rust
• if you do encounter these error messages, then you are apparently not skilled enough to not use rust, and should use rust

In summary: use rust.

OK, this is only tangentially related but it has been on my mind lately and I need to rant:

I am T1 diabetic. Over the last decade, a LOT has happened to improve my life, especially in regards to no longer needing to check glucose levels with blood, as glucose sensors you wear on your arm have become ubiquitous.

It started with a dedicated device that you needed to hold up to the sensor to get a reading (much nicer than pricking your finger) to that sensor being able to notify the dedicated device of high/low glucose values (yay! Sleep through the night, knowing you'll be woken up if something is wrong) to the sensor now constantly streaming glucose values to your phone.

Which is fantastic.

In theory.

In practice, there are two companies making these sensors (OK, there's a couple more, but they suck way more and are much less commonly used).

And both of their closed-source apps suuuuuuuuck. They do the bare minimum and nothing more. (Actually, it's worse than that. Ask me if you want to know. It's its own rant.)

Then there's xdrip+, a FANTASTIC app made by diabetics for diabetics. Instead of just showing you "this is your glucose" and sounding an alarm, once, when it's required, you can (just off the top of my head): Set an arbitrary amount of alarms with their own behaviors, which can be configured to vary by time of day; show the glucose everywhere (notification, lock screen, home screen,...); mute alarms for a custom time; do not sound an alarm if you're trending in the correct direction fast enough; do not sound the alarm multiple times if your are jittering around the threshold; notify other people automatically in case of emergency; and roughly 1000 things more. The app is well maintained, and of course open source.

Can you guess what the problem is?

That's right, manufacturers disapprove of using this app. For the worse one of the two sensors mentioned, the community reverse engineered the communication and it is now working perfectly with the app. For the better sensor, they can't and won't due to fear of legal repercussions.

It's my health. And I need to decide between worse hardware and useless software.

There's no technical reason for this. I dream of the EU passing a law that requires manufacturers of wearable medical devices to publish the comm protocols and to legitimize use of third party software.

Rant over.

This is hilarious, but also: how could anyone develop such a tool and not at least test it out on their own images? Someone with a public persona no less! Boggles my mind.