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.
The package name is visible in App info, no need to install anything - just long press the app icon, pick App info and scroll down to version
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.
Yeah, stock Google voice recognition also works offline if you download the language model beforehand.
Indeed, try switching your smartphone to airplane mode and see how far your voice commands get you.
Did that (or rather disabled mobile data and WiFi, because airplane mode would still keep the WiFi on), and then I dictated this sentence after the parentheses. So Google’s voice input works offline just fine.
Or do they mean something like a smart assistant? In that case fair, but it’s not like it will work with text input either.
It is true, however, that Google Translate doesn’t do offline voice translation even if the language you’re trying to translate from is downloaded for system-wide voice recognition.
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>I</i>'ve <u>seen</u> much <b><u>more</u> complaints</b> about <a href=“https://0.0.0.0/random_img.tiff”>people</a> constantly <marquee>demanding</marquee> their specific <h1>annoyances</h1> to be fixed without ever <i>submitting <u>a single <b>line of code</b></u></i>. <i>Maintainers</i> are pretty much <b>universally</b> welcoming to code <h2>contributions</h2> <br><br><br><br><br><br>
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).
There’s no inherent guarantee that a router has a firewall configured properly, or has it enabled.
If it’s not an enterprise router (where you sometimes start with a blank configuration), it most definitely does have a firewall blocking incoming traffic by default.
In the deployments you’re seeing, are ISPs handing out /120 blocks to each router?
/120 is not enough for IPv6 to reasonably work. It kinda requires the smallest block to be /64, otherwise half the cool stuff about IPv6 breaks. So you should get something between /48 and /64 (the recommendation for ISPs is /56 for residential users so they can subdivide their network to 256 other networks, and /48 as default commercial allocation).
Does that require the ISP to have access to alter your home router, or do customers configure the DHCP themselves (which seems unlikely to scale)?
There is DHCPv6, but it’s not really an important part of a network like DHCP for v4 networks. IIRC Android doesn’t even support it. IPv6 uses Router Advertisement (RA) to tell devices what prefix they’re in (and a few things that were originally DHCP options, like the preferred DNS servers), and the devices then pick their own address using the SLAAC mechanism (originally it was derived from the MAC address, but nowadays should be a random number). RA supports “multilayer” networks where each following router further subdivides the prefix it got.
If you want a static address (for example for a server), you can either configure it manually on the device (using tokenized addresses, i.e. “static local part with dynamic prefix”), or use a DHCPv6 server to assign the address (in which case the RA responses from your router need to indicate that there is a DHCPv6 server on the network).
Also, you talked about the fc00::/7 (or its locally managed half, fd00::/8) prefix as a proof that NAT is used with IPv6, but… There’s absolutely nothing stopping you from having both a globally routable address and a local only address at the same time. IPv6 already requires you to have at least two addresses when you connect to any network - a link local address and whatever other address you get assigned (btw IPv4 never prevented you from doing the same thing, it just wasn’t directly encouraged and wasn’t widely used, and DHCP didn’t support handing out multiple addresses unlike RA).
You can even get a security “improvement” over the claimed scenario with NAT with this - if you don’t assign a global address to a node, then not only will it be unreachable from the internet, it will also be unable to connect to the internet itself while being reachable from your network without any issues. “Air gapping” (I know, I know… but people use this term for “no internet” now) for folks afraid of firewalls!
I would hope it’s a special, heavy-duty kind at least.
I’ve seen an expensive microwave with a capacitive touch panel right above the door (and the door was the classic oven style, so attached by the bottom edge). If you ever had a phone with crappy moisture detection, you know where this is going.
You put your food in the microwave. Turn it on and let it heat the food up. Open the door, take the food out and close the door again. Congratulations, your microwave has probably just turned itself back on, because it detected the humid hot air rising from the briefly opened door as you touching the screen. And because most of the touch screen is “touchable”, there’s a pretty good chance this gust of humid air can successfully pick a cooking/heating mode and confirm it.
The microwave randomly navigating its own touch screen happened pretty much every time, passing all the menus and turning on was successful about 10% of the time.
In short, I wouldn’t expect a microwave interface to have any thought put into it.
Even Linux is slowly moving to an immutable system like Android. It is simply the best approach for an OS that non-technically-inclined people use - it’s much harder to screw up beyond repair by accident - and clearly the future of operating systems (well, future for Linux at least, mobile platforms and maybe macOS are already there).
My two cents: the only time I had an issue with Btrfs, it refused to mount without using a FS repair tool (and was fine afterwards, and I knew which files needed to be checked for possible corruption). When I had an issue with ext4, I didn’t know about it until I tried to access an old file and it was 0 bytes - a completely silent corruption I found out probably months after it actually happened.
Both filesystems failed, but one at least notified me about it, while the second just “pretended” everything was fine while it ate my data.
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).