Thanks for pointing that out. I tried the Codex App before but didn't see that.
I want to like the app, but I'm not sure if it actually fits well to my use case. With my current setup I need to fully quit and restart it if I want to work on a different project (to get it to use a different API key) and I cannot work in two threads belonging to different projects at the same time.
Also I generally prefer to handle sandbox the entire agent and disable its internal safeguards. Beside any doubts regarding the quality of the relevant sandbox implementations, I have just gotten my projects to work better this way.
I remember seeing this great video where they built their own power supply for their mini rack. Quite a project but ended up being a pretty cool solution to the problem.
I know our sales/business team is pitching it quite a bit (instead of our current end-to-end solution we provide), but no one has quite been able to define the boundaries of how that interacts when we don't own the full solution. Curious how others have been using it. Definitely seems designed for more of an internal or B2B use case where agents have super well defined behavior but are ultimately behind some other system entirely.
Check out this WWDC session. Obviously not going to compete with the frontier models (and I think 8GB is too small anyways), but Apple did demo MLX + OpenCode.
I'd love to see the Alacritty terminal backend swapped out with libghostty (or more likely libghostty-rs). The work Mitchell is doing with Ghostty and the approach Zed has taken seem super aligned.
And Mitchell definitely seems to want to make Alacritty an easy target for conversion, he was just talking about being open to help support Warp with it: https://x.com/mitchellh/status/2049159764261925005
Alacritty is already pretty performant (relative to a lot of the other terminal emulators), but my read is Ghostty has been going hard over performance/standards/protocols (like Kitty).
I did consider that. I remember nope-ing out of alacritty in the early days after seeing the developers response to people requesting a scrollback buffer. It amounted to something like "I use tmux, and if you don't, you use the terminal wrong." It left a bad taste in my mouth.
Ligatures are a renderer issue, so using alacritty as a lib wouldn't have this issue (it does demonstrate their hardline stance). Another example that would translate is how long it took them to support disambiguation of key combinations: https://github.com/alacritty/alacritty/issues/6378 (2019-2023). Of course, the maintainers are free to do whatever they want with the project - but such things do make alacritty-as-a-lib an exceptionally bad choice for situations where you want things to just work.
Anyone have a good replacement if a different organization is not able to take over? This has always been my favorite IPv6 test site, and really appreciate the author maintaining it for so long.
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 interesting bit is this type of UI doesn't fit very well in any of the existing terminal TUIs, I have only seen it enabled working well in GUIs.