Likely an unpopular take, but I switched to the "Natural text editing" preset in iTerm2 to get editing shortcuts that match the traditional macOS ones. It has the advantage of just remapping to the normal control sequences inside terminal apps, so you basically get this functionality everywhere without needed to change it in multiple places/worry about readline support/etc. It isn't perfect (I have rarely needed to enter sequences manually that then are remapped), but I find I have used way more command editing since its part of my muscle memory.
You can already AirPlay from an iOS device to a Mac– doing this on a plane is a bit trickier because of the networking setup though. I think I have managed to successfully do it once by either
1. doing some sort of tethering/creating a local wifi network on my Mac
2. connecting both devices to the in flight wifi
I use AirPlay to my Mac (and external monitors) even at home since I can watch the 4K feed from apps, which isn't available for some services if you use the web browser (cough HBO cough),
Seems notable that the transpiler is free during the tech preview, but pricing will be announced later. While the generated Kotlin code is probably not 1:1 with what a human would write, at least it seems you aren't completely locked in to it if you decide to leave.
Interesting idea– definitely a lot of surface area to cover and I am curious to see how it does. I personally love native app development, but wonder how big the downsides are once you start getting into detailed UX designs/architecture patterns...
Maybe using this for UI only and using Kotlin Native would be a better middle ground, but with Compose Multiplatform for iOS in development that might be an overall safer bet for native shared codebases.
The Pros do use USB3? Or are you talking about the regular 15? I still agree with you, but unfortunately the vast majority of regular iPhone users aren’t transferring large files over a cable and won’t care.
The regular 15. And 3.0 also supports much faster charging.
Maybe most won't care, but I still think it's disgusting and pathetic for a company this size with products this expensive to cheap out by using USB 2.0.
They indicated in the pitch for the Pro that they added logic to the new CPU to drive USB 3 at 10gbps. The non-Pro is using last year's CPU, so while yes I guess that means they did "cheap out", I imagine the cost to include 3.0 on the non-Pro is pretty high and most people don't care.
This. Consider the market. Samsung also doesn't add its newly-engineered, top-of-the-line solutions to its lower-end new models.
Almost all the people on this forum are in the target market for the Pro. The standard iPhone is not built for us, nor will most of its users have a problem with 480Mbps-over-wire transfer speeds.
USB 2.0 vs 3.0 has nothing to do with power delivery.
The only meaningful difference between 2.0 and 3.0 for the iPhone use-case is transfer speeds, and the simple reality is that the overwhelming majority of iPhone owners only use a cable to charge their phone, not to transfer data on/off it.
USB 3.0 isn't really necessary to support higher charging speeds that is mostly through Power Delivery which I believe both the regular 15 and pro support since they both advertise 20W fast charging.
Could there have been other tradeoffs? Power consumption, silicon footprint, et cetera. Most people never use USB to transfer data to and from their phones. It would be slightly ridiculous to support 3.0 if it meant tradeoffs in anything practical just so they can say they support a new protocol.
Well for now it's likely just the IP blocks (the non-pros uses the A16 which was certainly designed without since none of the 14s was shipped with support).
When the non-pros get the A17 we'll see if they disable the USB3 controller and it's market seg. I'd assume so but...
On the other hand, the 6th gen Mini uses an A15, and has USB 3 speeds support (only 5Gb but still).
So apple might have had USB3 speeds support in the A15 specifically for the mini, or they might have included USB3 support for a while in all SoC and enable it selectively for segmentation purposes.
That would gel with the comparison between the iPad Air 5th gen and the iPad Pro 5th gen: they both use the desktop-class M1, but the Pro supports full TB3 and USB4, while the Air only supports 10GB.
Dunno, I don't own Apple products and was quite disillusioned with my one workplace MBP. I'm unfamiliar with their newest chips and feature support. Do they maybe have an off-chip USB controller on the tablet?
Honestly, I'd expect any Armv8.3+ or Armv9 to have USB PD/USB-C, Thunderbolt, etc. on the chip itself. USB PD is even halfway-or-more supported on some budget Cortex-M targets. Apple, though, is a special case; the chipmaker and developer are the same, so they have the freedom to say "no USB-C on mobile chips" and include only the features they want.
My post was pure speculation and a little giving them the benefit of the doubt.
> They could've easily done that on the iPhone 15, so it's market segmentation.
Adding additional chips/additional controllers is not "easily" done. The iPads have more space to spare on their boards, and have larger batteries that can absorb the additional power requirements for running those additional chips much easier.
USB 2.0 data rates have absolutely nothing to do with charging speed. You don't even need to support data (at least, USB data) at all to support fast charging speeds. You just need to support PD, which is on separate, required pins that both phones support.
Minecraft computers have been done for a while now, but seeing a full RISC-V computer running programs is really impressive, and frankly just seems really cool. The programs are written in Rust, and then compiled to run in game. Plus, the author needed to write their own mod to make the Terraria wiring efficient enough to support the computer: https://github.com/misprit7/WireHead
I lost it when he dropped the containerized CI pipeline! Shows he was thinking about the whole process, not just the (literally) fiddly bits. Incredibly broad set of skills the author demonstrated.
I cannot believe he did the wiring "by hand". Loved the bug example he highlighted, which I hope is something he can reference later in life, "What's the most difficult bug you ever fixed?"
Does watch unlock now work natively with pam_tid? I know as of at least a few months ago it would only work if you could use touch ID, i.e. when the laptop was open. If it was docked, it would fall back to password auth.
I wrote a patcher that changed this behavior, it patched pam_tid directly on your system and just updates the API Apple calls to allow unlocking with watch-only when touch ID is unavailable:
This needs to be applied after every system update. Apart of that, it works really well (I have very dry skin so touch ID works for me 50% on a good day)
Guilherme’s stuff is great. pam-watchid is a reimplementation of Apple’s pam_touchid, but uses the other authentication flag which I patch in to the original binary.
This was my first time doing any sort of binary reverse engineering, I would love any feedback if there were methods I could improve on! I skipped some of my exploratory issues earlier on when using Ghidra and the free version of Hopper, but still think the README outlines the important parts!
https://pliszko.com/blog/post/2021-10-31-natural-text-editin...