I can only comment about battery life. It's proportinal to how much tailscale is really being used: If you use tailscale with an "exit node", i.e. all traffic is routed through it and it's working continously, it drains battery. If it's only used for services on your tailnet, e.g. Immich, the impact will be very small.
I have a static route configured on my home's gateway that enables any device on my network to access Tailscale. I have Tailscale turned on my iPhone pretty much all the time anyway, but even if I didn't I'd still be able to access services I have hosted that are only accessible on my tailnet.
But the way I do access Immich externally is not with Tailscale directly on my phone but involves exposing a caddy instance, running on a $1 VPS, to the internet.
If requests include a specific very long header (which I randomly made up), it then forwards those requests to my real Immich instance, which runs on my NAS. Headers can be configured within the mobile app. It has worked really well for me so far.
Here's some data. Well, technically anecdata, I suppose.
My phone has been powered on but inactive all night; I charged it to 80% before going to bed, then unplugged it and left it where I can reach it from my bed, as is my habit. (I'm in an Asian timezone, in case you hadn't guessed, so it's morning for me while it's evening in America right now). Its battery is now at 73%. The Android battery report says 6% battery usage from Kindle (makes sense, I started reading a book when I woke up), 0.7% from Signal (haven't sent any messages yet today but have received a few), and 0.3% from Tailscale.
So when you're not using the Tailscale network actively, you'll hardly notice the battery drain.
It’s obviously not a magical security layer that eliminates all issues related to public Internet exposure, but in my opinion it is good enough for the average home user.
I remember having problems using tailscale vpn 24/7 and pihole on my home network with the phone pointed at the 192.168 address for DNS. Pages would take 5s to resolve and start loading.
Unfortunately, Pihole was less important than Tailscale and I have to put up with mobile ads.
I'm on iPhone, i found a workaround involving having headscale set the dns using 'magicdns' or something and having that pihole join the tailnet. after that everything is mostly groovy but the individual components don't easily seem to be able to connect to a different vpn.
I leave my phone connected 24/7 and don’t notice any downsides. Only have to disable it on some networks when traveling to make awful captive portals work.
i've had tailscale almost permanently enabled for a couple of years at this point and it's never a problem (ios, nextdns with a tailscale specific profile rather than a pihole or something)
A download button would be great but the files are already stored on the device you can copy them with a usb or go on the device and upload it directly.
I bought it a few months ago and as a beginner in 3D printing it has been really nice. I haven't printed that much though but so far it's been really good.
Eleego Centauri Carbon is cheaper and is just plug and play. I have no experience with 3D printing and have been using it for a while with no problems or messing around with the printer.
I have an Elegoo Centauri Carbon which is cheaper than Bambu Lab's and it has been plug and play so far. I have no experience with 3D Printing and I've been printing on it without any problems so far.
I got the V2 and same - no fuss, especially if I stick to Elegoo filament. Multicolour worked out of the box, to the point where it's difficult to think it was a Big Thing until recently.
> Every time you open LinkedIn in a Chrome-based browser, LinkedIn’s JavaScript executes a silent scan of your installed browser extensions.
It's not clear though, either they only tested against chrome-based browsers or Firefox isn't enabling them to do so.
edit: I answered before I go fully through the article but it does say it's only Chrome based.
> The extension scan runs only in Chrome-based browsers. The isUserAgentChrome() function checks for “Chrome” in the user agent string. The isBrowser() function excludes server-side rendering environments. If either check fails, the scan does not execute.
> This means every user visiting LinkedIn with Chrome, Edge, Brave, Opera, Arc, or any other Chromium-based browser is subject to the scan.
A lot of people mistakenly refer to Chromium-based browsers as being Chrome-based.
I feel like this is obvious and you know that this is the exact mistake being made, but rather than drop an actual correction, you take the insufferable approach of pretending you don't know what's happening and forming the correction as a question.
> A lot of people mistakenly refer to Chromium-based browsers as being Chrome-based
This seems to be a case where the poison seeps through the cracks. From Google and Chrome to other Chromium-based browsers. In very correct ways, in this case, they are Chrome based.
