It looks like Framework only offers entry-level Radeon GPUs.

If you want to do GPU compute in a laptop and money is no object, something from Lenovo’s Legion series of gaming laptops is probably a good choice. You can get one with an RTX 4090 in it, and the series (or many models of it, at least) appears to have reasonably good Linux support. (Disclaimer: I’ve never used one.)

i think /c/[email protected] was removed due to redundancy with /c/[email protected] more than /c/[email protected].

that’s not to say it couldn’t be a place for non-news-related political discussions, but in practice it mostly got posts which would fit in worldnews.

it could be restored if one or more users with a good history wants to take responsibility for moderating it.

If you’re interested in using something other than Microsoft Windows, getgnulinux.org is a good place to read about your options and how to switch.

What a confused image.

1. TiVo complied with the GPLv2 and distributed source code for their modifications to Linux. What they did not do was distribute the cryptographic keys which would allow TiVo customers to run modified versions it on their TiVo devices. This is what motivated the so-called anti-tivoization clause in GPLv3 (the “Installation Information” part of Section 6. Conveying Non-Source Forms.).
2. Linux remains GPLv2, so, everyone today still has the right to do the same thing TiVo did (shipping it in a product with a locked bootloader).
3. Distributing Linux (or any GPLv2 software) with a threat of violence against recipients who exercise some of the rights granted by the license, as is depicted in this post, would be a violation section 6 of GPLv2 (“You may not impose any further restrictions on the recipients’ exercise of the rights granted herein.”).

If you use systemd’s DHCP client, since version 235 you can set Anonymize=true in your network config to stop sending unique identifiers as per RFC 7844 Anonymity Profiles for DHCP Clients. (Don’t forget to also set MACAddressPolicy=random.)

They only do that if you are a threat.

Lmao. Even CBP does not claim that. On the contrary, they say (and courts have so far agreed) that they can perform these types of border searches without any probable cause, and even without reasonable suspicion (a weaker legal standard than probable cause).

In practice they routinely do it to people who are friends with someone (or recently interacted with someone on social media) who they think could be a threat, as well as to people who have a name similar to someone else they’re interested in for whatever reason, or if the CBP officer just feels like it - often because of what the person looks like.

It’s nice for you that you feel confident that you won’t be subjected to this kind of thing, but you shouldn’t assume OP and other people don’t need to be prepared for it.

If they ask for a device’s password and you decline to give it to them, they will “detain” the device. See this comment for some links on the subject.

I’m pretty sure that immigration in the US can just confiscate your devices if you are not a citizen .

CBP can and does “detain” travelers’ devices at (or near) the border, without a warrant or any stated cause, even if they are US citizens.

Here is part of the notice they give people when they do:

Or just removing my biometrics?

Ultimately you shouldn’t cross the US border carrying devices or encrypted data which you aren’t prepared to unlock for DHS/CBP, unless you’re willing to lose the hardware and/or be denied entry if/when you refuse to comply.

If they decide to, you’ll be handed this: “You are receiving this document because CBP intends to conduct a border search of your electronic device(s). This may include copying and retaining data contained in the device(s). […] Failure to assist CBP in accessing the electronic device and its contents for examination may result in the detention of the device in order to complete the inspection.”

Device searches were happening a few hundred times each month circa 2009 (the most recent data i could find in a quick search) but, given other CBP trends, presumably they’ve become more frequent since then.

In 2016 they began asking some visa applicants for social media usernames, and then expanded it to most applicants in 2019, and the new administration has continued that policy. I haven’t found any numbers about how often they actually deny people entry for failing to disclose a social media account.

In 2017 they proposed adding the authority to also demand social media passwords but at least that doesn’t appear to have been implemented.

It seems to me that switching SIMs provides little privacy benefit, because carriers, data brokers, and the adversaries of privacy-desiring people whom they share data with are obviously able to correlate IMEIs (phones) with IMSIs (SIMs).

What kind of specific privacy threats do you think are mitigated by using different SIMs in the same phone (especially the common practice of using an “anonymous” SIM in a phone where you’ve previously used a SIM linked to your name)?

Redhat, however, found this solution too simple and instead devised their own scheme for assigning network interface names. It fails at solving the problem it was created to solve

I somehow first read “Redhat” as “Reddit” in this sentence, and so was briefly thinking that perhaps this bad idea originated there 😂

(probably the most downvoted post i’ve made yet on lemmy 😂)

If you’re ready to break free of Android, I would recommend https://postmarketos.org/ though it only works well on a small (but growing!) number of devices.

imho if you want to (or must) run Android and have (or don’t mind getting) a Pixel, Graphene is an OK choice, but CalyxOS is good too and runs on a few more devices.

It’s literally a covert project funded by google to both sell pixels and harvest data of “privooocy” minded users. It seems to be working well.

Is it actually funded by Google? Citation needed.

I would assume Graphene users make up a statistically insignificant number of Pixel buyers, and most of the users of it I’ve met opt to use it without any Google services.

E: old thinkpad gang input: take the time to reapply thermal grease to the cpu at some point. It makes a huge difference.

What’s a “gang input”?

😂 it’s an input to this discussion from a member of the group of people (“gang”) who have experience with old thinkpads. and yes, if your old thinkpad (or other laptop) is overheating and crashing, reapplying the thermal paste is a good next step after cleaning the fans.

Indeed, the only thing WhatsApp-specific in this story is that WhatsApp engineers are the ones pointing out this attack vector and saying someone should maybe do something about it. A lot of the replies here don’t seem to understand that this vulnerability applies equally to almost all messaging apps - hardly any of them even pad their messages to a fixed size, much less send cover traffic and/or delay messages. 😦

xzbot from Anthony Weems enables to patch the corrupted liblzma to change the private key used to compare it to the signed ssh certificate, so adding this to your instructions might enable me to demonstrate sshing into the VM :)

Fun :)

Btw, instead of installing individual vulnerable debs as those kali instructions I linked to earlier suggest, you could also point debootstrap at the snapshot service so that you get a complete system with everything as it would’ve been in late March and then run that in a VM… or in a container. You can find various instructions for creating containers and VMs using debootstrap (eg, this one which tells you how to run a container with systemd-nspawn; but you could also do it with podman or docker or lxc). When the instructions tell you to run debootstrap, you just want to specify a snapshot URL like https://snapshot.debian.org/archive/debian/20240325T212344Z/ in place of the usual Debian repository url (typically https://deb.debian.org/debian/).

A daily ISO of Debian testing or Ubuntu 24.04 (noble) beta from prior to the first week of April would be easiest, but those aren’t archived anywhere that I know of. It didn’t make it in to any stable releases of any Debian-based distros.

But even when you have a vulnerable system running sshd in a vulnerable configuration, you can’t fully demo the backdoor because it requires the attacker to authenticate with their private key (which has not been revealed).

But, if you just want to run it and observe the sshd slowness that caused the backdoor to be discovered, here are instructions for installing the vulnerable liblzma deb from snapshot.debian.org.

Sounds like it requires that your DHCP server is hostile, which is actually a very small (though nonzero, yes) number of the attack scenarios that VPNs are designed for

In most situations, any host on the LAN can become a DHCP server.

“there are no ways to prevent such attacks except when the user’s VPN runs on Linux or Android” is a very funny way of saying “in practice applies only to Windows and iOS”.

No. There are certainly ways of mitigating it, but afaict no Linux distros have done so yet.