I have no clue what’s meant by “without download”, but this app just uses web assembly to inspect the archive in the browser. The sandbox they talk about most likely refers to the browser sandboxing.

So it pretty much boils down to “risking running malicious code is fine, because this app as a whole is treated as malicious by the browser”.

Idk, ~five years doesn’t seem like a long time with regards to CPUs. I had my Ryzen 2200G from summer 2018 to this January, and I would consider my purchase of a cheap Ryzen 3600 to be a bit premature (and it was definitely an impulse purchase). And it also means that the CPU sticker became outdated pretty soon.

The author acknowledges that, the blog post seems to be aimed at demystifying the concept of namespaces by showing that a “container runtime” that only does limited filesystem namespaces (using chroot) is enough to get some widely used containers running (of course without all the nice features and possibilities of the other types of namespaces)

On the other hand, it’s also worth noting that newer RAM generations are less and less susceptible to this kind of attack. Not because of any countermeasures, they just lose the data without constant refreshing much quicker even when chilled / frozen, so the attack becomes impractical.

So from DDR4 up, you’re probably safe.

I think the idea at the time was that if /usr is unavailable, you won’t be doing much with the system anyway (other than fixing the configuration).

Nevermind, apparently the original meaning had nothing to do with a network (TIL for me), so our discussion is kinda moot. See section 0.24 in this 2.9BSD (1983) installation guide

Locally written commands that aren’t distributed are kept in /usr/src/local and their binaries are kept in /usr/local. This allows /usr/bin, /usr/ucb, and /bin to correspond to the distribution tape (and to the manuals that people can buy). People wishing to use /usr/local commands are made aware that they aren’t in the base manual.

No comment on sensibility, but technically both are equally difficult - mount the parent filesystem, then mount the child filesystem into an empty directory in the parent. Doesn’t matter which one is where, it’s all abstracted away at this level anyway.

I do not get paid every time it runs for the rest of my life, so why should you?

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.

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.

But AOSP already is “Android without proprietary Google code”, simply because “Android” means AOSP + Google Play Services + compatibility certification. It’s getting increasingly more and more barebones as Google moves functionality into Google Play Services, but it is what the vast majority of third party ROMs are based on.

How they manage to then improve compatibility differs. Truly ungoogled ROMs just don’t - either the app works with AOSP, or it’s not welcome on the system because it would require Google services. Some use MicroG, a small open-source reimplementation that is good enough to replace the real Google Play Services for most apps (but it does communicate with Google servers similarly to the real one, so all it does from degoogling perspective is limit the amount of extra data your phone sends to Google). Then there are also ROMs that support installing the official Google Play Services and related apps. LineageOS can do that (or it can use MicroG, or just not have GPS at all), for example.

And then there is GrapheneOS which has managed to turn the Play Services into a mostly regular app that doesn’t have overreaching access to the whole system and lets you configure how much data you’re willing to leak to it.

Drivers also don’t seem to be that big of a deal nowadays, Google’s effort to simplify Android updates for OEMs has done a lot to help third party ROMs as a side effect. The biggest problem now is the various security attestation mechanisms that are available through Google Play and which Google spends a lot of time and money to convince developers to use. These are very hard / currently impossible to implement in a way that doesn’t trip security checks on the affected apps - want mobile banking? Well, that’s too bad because it will simply refuse to work if Google Play says your system has been tampered with. Workarounds exist, but they’re not reliable over time.

I’m a bit confused about the emphasis you put in the quote… GrapheneOS is built on AOSP (the open-source part of Android), it’s definitely not some OS built from ground up (look no further than the various Linux phone projects to see how terrible those are as Android replacements atm).

Technically it isn’t Android, because Google owns the trademark and has some requirements for stuff that wants to call itself Android - it needs to pass a compatibility test and more importantly, include Google Play Services. But it is as much Android as any other custom ROM.

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”