I would recommend using Linux if you want control over this stuff. Microsoft does not, and never will, respect you or your privacy. Apple _hopefully_ does but we can't be sure. Linux is the main option if you care this much about it.
My only two iPhones have been the iPhone SE 2016, and the 13 mini.
I miss the SE but the 13 mini is really nice too. It's a shame because the SE is still perfectly capable of running most software I use on a phone, but that software has just gotten more inefficient over time.
I have the 22 SE and I suspect I’ll get 3 more years out of it before they EOL it. I would have bought the 16e if it wasn’t such a blatant money grab. Touch ID is going to be hard to give up
I'm kind of the opposite, I would never want to go back to Touch ID. It's so nice that you can set your notifications to be private by default, but the contents will be revealed when you glance at the phone.
I think it really matters how you store your phone as to the usefulness of Touch ID. Someone storing it in their front pocket will have it always available in an ideal position to unlock on grab, whereas someone storing it anywhere that doesn't lock it in a position like that is going to see less benefit of being able to unlock the thing as they grab it.
I just had to get a new phone old was a 2020 SE (Previous was a 6S plus) so 5 years.
The new phone is FaceId ioty is much less reliable than touch id. With touch it just fails if I have wet hands or in cold weather with gloves, faceId fails in many places.
Agreed, pulling the phone out of a pocket with my thumb on the home button and having it unlocked and ready to use by the time I look at it is is ideal.
Much better than having to pull it out, hold in in a way that it can see my face, then swipe up, then wait for the stupid animation at the top of the screen to finish and the actual unlock to occur and then finally be able to use the device.
Apple says they stopped producing minis because they didn't sell. It seems they sold relatively better than the Air, and pretty much everyone I know who still uses a device of "13" or earlier generation, is on a mini. That's about 5 people just in my social circle still on a 13 Mini, and 0 people on any other non-Mini 13th or older generation. I reckon that's the real reason they stopped making them, people who use them, are willing to stay with their phones for much longer periods. Could also be that they break less due to being smaller.
Always curious to hear from people doing Rust gamedev without bevy! What are the main crates you're using, and what sort of game object architecture are you going with?
I do hobbyist level gamedev in my spare time and found bevy to be a bit too much for the things I want to do.
Sony supports pairing Bluetooth devices via USB since PS3 and Apple supports this since wireless peripherals with Lightning port.
However the protocols to do that are all proprietary and mutually incompatible. At least the PS3 protocol has been sufficiently reverse engineered so you can plug a DualShock 3 controller into a Steam Deck and have it just work wirelessly afterwards.
And you can repair an already-paired device by either holding down the power button for a few seconds or flipping the power switch on and off a few times, depending on the model.
My biggest annoyance with Apple devices is in software, that AFAIK there's no way to prevent macOS from pairing to any Apple Bluetooth device connected via USB, even if it's already paired with another device and you only intend to use it via USB.
We have _some_ NAT traversal logic in place, but it's very basic. Tailscale does a much more thorough job on it. It would be cool to add peer relays to innernet but I imagine it's a fair amount of work.
From what I recall, tailscale has their own Wireguard implementation so they have more control over the socket and how things are routed. innernet is just a wrapper around managing wireguard peer lists, and yeah there's a central coordination server which is unfortunate. If the server goes down, you can still connect to peers so thankfully it doesn't bring down your whole network, but you won't be able to learn about new peers or peer endpoints over time until you re-establish connectivity with the coordination server.
The RP2040 has great documentation and the PIO is an amazing swiss army knife of a peripheral. I've had no trouble learning from their datasheet and docs and making plenty of PIO programs.
Why else is this discussion getting hundreds of comments?
For any random python tool out there, I had about a 60% chance it would work out of the box. uv is the first tool in the python ecosystem that has brought that number basically to 100%. Ironically, it's written in Rust because python does not lend itself well to distributing reliable, fast tools to end users.
It comes up again and again, because people don't realize that solutions already exist(ed) and they don't spend the time to figure things out.
I have managed reproducible Python services and software for multiple years now. This was solved already before uv, although uv does it faster and maybe offers a bit more comfort, although I abstract away such tooling using a simple Makefile anyway.
The reason you are having such a bad time getting random Python projects to work out of the box is, because people creating them did not spend the effort to make them reproducible, meaning, that they do not ensure the setup has same versions and checksums of every direct and transitive dependency. This can be facilitated using various tools these days. poetry, uv, and I am sure there are more. People are just clueless and think that a requirements.txt file with a few loose versions slung in is sufficient. It is not, and you end up with not working project setups like in those cases you refer to.
> For any random python tool out there, I had about a 60% chance it would work out of the box.
Had, past tense, because of the metadata situation and the lack of pre-built wheels. The ecosystem has moved on.
> uv is the first tool in the python ecosystem that has brought that number basically to 100%.
Show me a Python tool that you can install and have work out-of-box with uv, but cannot install and have work out-of-box with pip.
> Ironically, it's written in Rust because python does not lend itself well to distributing reliable, fast tools to end users.
I have repeatedly shown that the slowness of pip is overwhelmingly due to its terrible (organically developed on top of legacy cruft from an era where people simply didn't have the same requirements) architecture, not due to being written in Python. Most of the work of installation is simply not CPU-bound — why would it be? — and the main task that is (optional pre-compilation of Python source to .pyc) is one of the few things where uv is dependent on the Python runtime (which, in turn, will do the work in C).
reply