This is the most disappointing aspect of the slide in quality for me.
I working in software and "build features" for a living, and over the years I've come to prioritize reliability, performance, and an intuitive experience over all else. No matter how good the feature set is, if it crashes, is painfully slow, or I can't figure out how to use it, then I don't want it.
Apple used to have that focus, but seems to have lost it of late.
Apple definitely had that focus under Jobs but people now are all too happy to tell you you're holding it wrong and I think Apple internalized this mentality.
But I find iOS 26 absolutely disrespectful. It wants you to use it in ways that previous iOS versions pushed you away from. It's an anti pattern to previous versions. I'm sorry, if you teach users one pattern don't update to have them do the opposite. Nothing is could be less intuitive
> Being these things are at their core probability machines, ... How? Why?
Is Siri a probability machine? I didn't think it was an LLM at all right now? I thought it was some horrendous tree of switch statements, hence the difficulty of improving it.
Apple search is comically bad, though. Type in some common feature or app, and it will yield the most obscure header file inside the build deps directory of some Xcode project you forgot existed.
I was hesitant buying my Tesla this year (first one) as I really liked having CarPlay in my prior car (Jeep). But after having it a while, it's really a non-issue. The Tesla Apple Music app is pretty good. Their maps and navigation is pretty good (and integrated with FSD). And I can easily just use the bluetooth connection for a couple other minor things I occasionally use.
I’ll start off by saying that the model Y is one of the best mid-level cars I’ve driven so the issues I mention below are worth the tradeoffs to me.
In my experience, Tesla navigation can be pretty bad when navigating my large urban city. During peak traffic times it often tries to send me down roads that are notoriously known for traffic backing up. Most times when I end up following those suggested routes, my ETA essentially becomes meaningless.
I’ve found Google, Waze, and Apple maps to be a lot better in this respect.
I do miss having CarPlay. That’s not to say I think the music integration you mentioned is bad, but I find the overall UI in my model Y to be a bit confusing - and the lower icons seem to sometimes randomly change from what I have them set as.
Same. I love the tesla model y, but it's not perfect. The screen UI is pretty good for the most part, enough that I don't think about carplay too often.
But I do tend to stream audio from my phone more than from the tesla UI, and so I do miss carplay when I think about it.
> Their maps and navigation is pretty good (and integrated with FSD)
I got a loaner with fsd and tried it out.
There was this one trip I took to a store and for some reason, the nav route detoured off the road to the next street over, then joined back with the route.
I think this is a thing nav systems do and people just ignore it and go the right way.
It's a full featured and beautifully designed experience, and when it works it's amazing. However it regularly freezes of hangs for me, and I've lost count of the number of times I've had to 'force quit' Xcode or it's just outright crashed. Also, for anything non-trivial it often refuses to profile and I have to try to write a minimal repro to get it to capture anything.
I am writing compute shaders though, where one command buffer can run for seconds repeatedly processing over a 1GB buffer, and it seems the tools are heavily geared towards graphics work where the workload per frame is much lighter. (Will all the AI focus, hopefully they'll start addressing this use-case more).
> However it regularly freezes of hangs for me, and I've lost count of the number of times I've had to 'force quit' Xcode or it's just outright crashed.
This has been my experience too. It isn't often enough to diminish its value for me since I have basically no comparable options on other platforms, but it definitely has some sharp (crashy!) edges.
I didn't even notice who I was replying to at first - so let me start by saying thank you for Ghostty. I spend a great deal of my day in it, and it's a beautifully put together piece of software. I appreciate the work you do and admire your attitude to software and life in general. Enjoy your windfall, ignore the haters, and my best wishes to you and your family with the upcoming addition.
The project I'm mostly working on uses the wgpu crate, https://github.com/gfx-rs/wgpu, which may be of interest if writing cross-platform GPU code. (Though obviously if using Rust, not Zig). With it my project easily runs on Windows (via DX12), Linux (via Vulkan), macOS (via Metal), and directly on the web via Wasm/WebGPU. It is a "lowest common denominator", but good enough for most use-cases.
That said, ever with simple shaders I had to implement some workarounds for Xcode issues (e.g. https://github.com/gfx-rs/wgpu/issues/8111). But still vastly preferable to other debugging approaches and has been indispensable in tracking down a few bugs.
That aside, even if something like this was “legally enforceable”, it adds enough friction, risk, and uncertainty to downstream consumers compared to a “vanilla” open source license that I expect most folks would choose an alternative to the “bespoke” license project where they could. Fine if you don’t care about getting usage, but that defeats much of the value that open source brings.
> Also, code that compiles with older CUDA toolkit versions may not compile with newer CUDA toolkit versions. Newer hardware may require a CUDA toolkit version that is newer than what the project maintainer intended.
This is the part I find confusing, especially as NVIDIA doesn't make it easy to find and download the old toolkits. Is this effectively saying that just choosing the right --arch and --code flags isn't enough to support older versions? But that as it statically links in the runtime library (by default) that newer toolkits may produce code that just won't run on older drivers? In other words, is it true that to support old hardware you need to download and use old CUDA Toolkits, regardless of nvcc flags? (And to support newer hardware you may need to compile with newer toolkits).
That’s one of the primary reasons we built the tooling for Q# to run in the browser (by writing in Rust and compiling to wasm). The “try with copilot” experience [1] and the “katas” for learning [2] all have a full language service and runtime in the browser.
Horses for courses. Better camera (for those special moments while the kids are young) and better battery life are two big ones for me, so I'll likely upgrade. (Kind of digging the orange color too).
It's not the dullest refresh, and they always sell plenty. I'm sure this will be no exception.
I working in software and "build features" for a living, and over the years I've come to prioritize reliability, performance, and an intuitive experience over all else. No matter how good the feature set is, if it crashes, is painfully slow, or I can't figure out how to use it, then I don't want it.
Apple used to have that focus, but seems to have lost it of late.
reply