You might be able to manually enable IPv6 in Optus’ APN.
My Telstra eSIM didn’t automatically enable IPv6, when my physical SIM did, but enabling it in the telstra.wap
APN fixed it.
You might be able to manually enable IPv6 in Optus’ APN.
My Telstra eSIM didn’t automatically enable IPv6, when my physical SIM did, but enabling it in the telstra.wap
APN fixed it.
For the AMD version, if you’re going for an almost all Type A layout or something, it’s handy to note that the Type A expansion card have idle power issues in the back ports.
I’ve seen an S3 option in Smokeless_UMAF, so maybe you can enable real suspend, but I haven’t tried on my Framework 13 AMD.
It seems like it’s fixed now, but if possible use one of the mirrors, so everyone’s not hitting that one server all that hard, it’s usually faster too.
Or even better, use the torrent.
Most thermal paste isn’t electrically conductive, so that blob inbetween the capacitors shouldn’t be an issue, but it would be good to know what thermal paste it is to be sure.
This format’s from 2017 I’m pretty sure.
Yes, but it doesn’t look like KPROBES_ON_FTRACE
is supported on arm64. I did find this patch though which implements it: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20191218140622.57bbaca5@xhacker.debian/
If you don’t know how to apply a patch, you can either paste the link into b4
, or download the mbox and apply it with git am
.
Ahh okay, that description kinda sounds like floppy drive power, but it probably is a proprietary thing.
Could also be slimline sata.
Probably a long shot, but if you live in Australia (or maybe also New Zealand), Jaycar often sells the Ender 3 V3 SE for AU$250, which seemed like a really good price compared to other places I found.
I couldn’t find a hard answer to whether this supports EPYC only, or Ryzen too; so I put together this script to read the CPUID to detect for INVLPGB
support according to the AMD64 Programmer’s Manual, and my 7800X3D does not support INVLPGB
.
(Let me know if I’ve made an error though!)
#include <stdio.h>
#include <stdint.h>
int main() {
uint32_t eax, ebx, ecx, edx;
eax = 0x80000008;
__asm__ __volatile__ (
"cpuid"
: "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx)
: "a" (eax)
);
printf("EBX: 0x%x\n", ebx);
if (ebx & (1 << 3)) {
printf("CPU supports INVLPGB\n");
} else {
printf("CPU does not support INVLPGB\n");
}
return 0;
}
That’s INVLPG
which has been there since the 486. The AMD64 Programmer’s Manual has some info on the differences between INVLPG
, INVLPGA
, and INVLPGB
though.
If you’re already getting an IPv6 prefix allocated, then you can randomise the second half of the address, most devices do this automatically with EUI-64.
Otherwise you pretty much just have to use some sort of IPv6 tunnel.
It’s part of GNU Gzip, and zcat is basically just a shell script that runs exec gzip -cd "$@"
meaning you can actually just do cat /usr/bin/zcat
to get the source.
The options that start with HAVE_
usually depend on the arch or compiler. I don’t believe it’s possible to enable manually without modifying the source itself.
firmware drivers
This sounds like you’re talking about firmware blobs that the kernel drivers load, which are usually in a package called linux-firmware
. It should be updated automatically, but I’ll check in the morning with Fedora Silverblue.
Otherwise if you’re talking about device firmware, than that’s all fwupd
, rpm-ostree
has nothing to do with that.
Idk about the UK, but in Australia if you’re only sending a small amount of data, some carriers offer IoT plans starting at ~$1/month. So maybe some carriers do the same in the UK?
If you’re wondering what this is:
- Add a power quirk for Framework systems
It’s to do with the fact that Framework laptops report themselves as discharging when they’re actually fully charged, and BIOS updates aren’t allowed when discharging.
But to answer your question, I’ve been using it with my Framework 13 AMD, and haven’t had any issues. Fwupd is officially supported by Framework themselves, and is mentioned on the BIOS upgrade guides.
I’ve got one of the official Home Assistant SkyConnect dongles, and I just stick to the IKEA ZigBee stuff, most other ZigBee devices should work too though.
IPv6 headers are usually bigger anyway1, so the only advantage is more efficient routing (so infinitesimally better latency), but in my experience most routers only support IPv4 hw offload and not IPv6, so it’s only more efficient in theory.
I just like IPv6 because I get a whole /56 prefix to play with, and devices often randomise their host portion through the privacy extensions, meaning they use a new address each day or so.
1 IPv4 is usually ~20 bytes, but it can be up to 60 bytes if you stack a lot of options, IPv6 is only 40 bytes AFAIK.