Yeah, OP literally said that they weren't blocked when using Vivaldi with uBlock Origin, you were the first one to mention the builtin adblock (which is detected by YouTube).
Again: to use YT, you have to disable the builtin adblock and use only uBO. That's in line with OPs statement.
That's cool, but YouTube detects Vivaldi's built in adblocker, so it's kinda irrelevant if it's affected by extension policies.
To use YT in Vivaldi, you have to properly configure uBlock Origin (avoid extra filters that interfere with YT) and disable the builtin adblock for YT. And given that Vivaldi relies on Chrome Extension Store for its extensions, there will still be some friction to getting Mv2 extensions after Google pulls the plug on them.
Generally yes. The Fn key is usually handled either by the keyboard itself or by the BIOS, and the OS just sees the resulting key presses as if the keyboard had all the buttons. Can you not find such a switch in your BIOS? Saying what vendor it is might also help someone help you.
This is a very useful way to remember it, but nowadays it's better to drop the z (which immediately makes the mnemonic more forgettable, of course). tar can autodetect compression now, so tar -xf should work on anything from plain tar archives over tar.gz to more unusual compression algorithms like tar.xz or tar.bz2.
(the z is specifically for gzip)
Interesting to hear that people consider Android, AOSP + proprietary bits.
Google owns the Android trademark, and they won't let you officially call any OS that doesn't meet their requirements Android. And their requirements include Gapps among other things. That means AOSP is not Android.
(and i’m not sure why PG is encouraging it by boosting it)
I'm pretty sure that's just how other ActivityPub platforms see posts in Lemmy/kbin communities. There's no boosting here and @privacyguides isn't an user
Does your phone happen to be made by one of the vendors ranking high on this list? If so, that's not on Google (well, you could argue that Google could take more control over Android and force vendors not to do this, but that's another discussion - now we're talking about a fix Google made for apps evading its battery optimizations).
Because I've personally had no problem with apps like AccuBattery and GadgetBridge staying awake when set to unrestricted.
Navigate to the specific app details in settings -> Battery usage -> set to Unrestricted. There, it's off. Just like it was for the past however many years since Doze was first implemented. Or just turn off adaptive battery to disable this for all apps and enjoy your awesome battery life.
This fix is for apps that are set to optimized/restricted and are avoiding being killed.
Automatically and silently through Google Play if you are on Android 12+. You most likely already have this update.
I believe a USB WiFi dongle will be a better idea than modifying live images of various distros, and others are already pointing you in the correct way for that, but I feel the need to correct one thing:
Okay, so maybe I can add some driver files to the LiveUSB or something? . . . nope. Not a good idea, because the other part of the whole fix is installing firmware, which has to be in place before the drivers will work -- but this chip is also still being used by the onboard Mac OS.
The WiFi module doesn't have any persistent memory for firmware, which is why the system needs to bring its own firmware - it is uploaded to the chip on every boot as part of driver initialization. So there is no risk of interfering with macOS here.
The installation in the guide refers to putting the firmware in a place where the driver will be able to find it. In other words, you would be installing the firmware on the Linux system, not onto the WiFi module.
Ssh listens on port 22, as soon as a connection is made the host moves the connection to another port to free up 22 for other new connections.
There's no limit on the number of concurrent connections on a single port, and SSH runs completely on the one port it is configured to use. Otherwise allowing just the port 22 in firewall wouldn't be enough to have a functional SSH connection with default settings.
You can verify that quite easily for example by spinning up three barebone Debian VMs connected to a single virtual network, configuring the firewall on the "server" VM to drop everything other than port 22 and then connecting from both client VMs - it will work just fine.
Maybe you're confusing it with the fact that only one process can listen on a given port at a time? But that's only for establishing new connections. Existing connections can be passed off to another running process or a child process just fine, and that's how SSH handles separation between connections.
Edit: oh, you're talking about the high port OP is wondering about. That's just the source port, which is chosen randomly by the client OS when making a connection. Using port 22 (or any other port below 1025) as a source port would require root privileges on the client and would also conflict with the SSH server that could be running there. Still, it has nothing to do with SSH "moving connections over"
Sorry if I misunderstood you, but this feels rather easy to answer: because you are being paid to write the code. Spotify doesn't pay anyone to write music (well maybe they technically do for some ads or something, but it's definitely not how they acquire more music to add to the library), they just pay for streaming rights on music that was somehow already independently produced. And tiny unknown musicians have no leverage to negotiate better terms than what Spotify offers.