Well don't build your network around unassigned TLDs.
Also NAT does literally nothing other than being a massive PITA, so... yeah, I don't think there's much I can agree with in your rant.
Like, oh no, fully functional point to point connectivity across the internet, how terrible
Edit: .home.arpa is actually designated as local TLD, and is what I use for a crappy old tablet that doesn't support mDNS
As far as I know, bootloader locks are done by the manufaturer not by the provider.
Verizon requires the phones they sell to NOT have the ability to unlock the bootloader. That's why there are separate factory images for Verizon Pixels.
What do you mean "now"? Google Photos has had a photo editing feature for a very long time now
That indeed is a Bluetooth feature that supposedly makes audio quality better by only lowering the volume using the actual speaker driver instead of doing it digitally and potentially throwing away some quiet sounds. In theory, doing it this way is always better and should be preferred. In practice, many devices handle it terribly.
If you want to turn the feature off, you can enable developer options on your phone (settings -> About phone -> tap Build number a bunch of times) and turn off absolute volume. That will give you back software volume control with fine-grained adjustments.
The CPU is still Google's Tensor, and the modem on current Pixels is already a blackbox that custom ROMs interact with using binary blobs ripped from the official ROM. There isn't much that could get worse with this change.
Google Drive app -> New (in the bottom right corner) -> Scan. It's not supposed to be a part of the camera app, that's just a useful shortcut.
Don't be ridiculous - this is a lab environment, they can faithfully recreate the suffering as long as the ethics committee doesn't get notified.
That sounds like Xiaomi. The best price to performance ratio of any OEM, but at the cost of terrible software and this... experience... when you want to get rid of it.
Worth noting that not all OEMs are like this.
That's a reasonable per-core size, and it doesn't make much sense to add all the cores up if your goal is to fit your data within L2 (like in the article)
Please don't pretend as if OpenSource Devs don't constantly complain about pesky PRsπ
I've seen much more complaints about people constantly demanding their specific annoyances to be fixed without ever submitting a single line of code. Maintainers are pretty much universally welcoming to code contributions
I soooo hope this does something funky with someone's Lemmy client
That's more of a storage thing, RAM does a lot smaller transfers - for example a DDR5 memory has two independent 32bit (4 byte) channels with a minimum of 16 transfers in a single "operation", so it does 64 bytes at once (or more). And CPUs don't waste memory bandwidth than transferring more than absolutely necessary, as memory is often the bottleneck even without writing full pages.
The page size is relevant for memory protection (where the CPU will stop the program execution and give control back to the operating system if said program tries to do something it's not allowed to do with the memory) and virtual memory (which is part of the same thing, but they are two theoretically independent concepts). The operating system needs to make a table describing what memory the program has what kind of access to, and with bigger pages the table can be much smaller (at the cost of wasting space if the program needs only a little bit of memory of a given kind).
NAT is not a security mechanism. If you set up a NAT with an otherwise permissive firewall, your router will happily forward any incoming packets destined for RFC 1918 addresses inside, no questions asked. I use this for a "lab" network that I sometimes want accessible from the bigger LAN - the lab router doesn't have any rules for dropping incoming packets (only blocks some outgoing traffic), and all I have to do on the main router to get this working is to set a static route to the internal lab network through the lab router's "external" IP.
accept established, related; drop incoming. That's all you need to get the same security as a NAT with a proper firewall. Outgoing connections will get marked and have return traffic allowed, everything incoming without related outgoing traffic gets dropped. Want to "port forward"? Add a rule that allows incoming traffic to a specific IP/port/protocol triplet. Done. Don't know how to make sure a client stays reachable on a specific address? Give it that specific IP address in addition to the one it autogenerates. This was always possible with IPv4, too, it's just that the tiny address space made it impractical to use.
How do you get the equivalent of NAT punchthrough (which is unreliable with many NAT implementations) when you want to do a VoIP call without having to bounce all the data through a central server? Simple, you can just tell both clients the other one's IP and port, have them spam each other for a tiny while with messages and eventually a message gets through both firewalls. It is very similar to NAT punchthrough, except you don't have to guess how the NATs work and it'll reliably connect.
Not sure why you'd regularly need to type out the whole thing. Also not sure why you picked .local when .lan is also incorrectly used for this purpose and is shorter (and isn't yet assigned to any conflicting technology)
The point of mDNS is that devices auto discover each other on a network without a central authority. The word multicast in multicast DNS is the key. And the reason I use it is because... it just works. There's no need to configure it, it works like this by default on pretty much every OS. Set the hostname and you're done, .local now works. You can even bridge it across networks with a mDNS repeater available on many routers.
Given the ambiguity of certificates everywhere, malicious devices on the local network posing as a different server are not an issue (and it's not like they couldn't hijack the IP address in any flat network anyway).