This works fine normally, but resizing the terminal would quickly trigger the crash - easy to avoid but still annoying!
I was already preparing myself to file a bug report with the easy repro, but this sounds suspiciously close to what the blog post is describing. Fingers crossed :)
I don't think I can do a better overview than https://ghostty.org/docs/about . It's not world-changing but simply a very polished, well-executed terminal.
GPU rendering virtually eliminates typing latency. Most terminals that have it don't support native content like tabs, but Ghostty gets minimal latency without having to compromise on essentials since it uses native toolkits under the hood.
The modern TTY has lots of protocol extensions that allow your CLI tools to do things like display high-resolution images. There's tons of good-quality color themes out-of-the-box (with a built-in browser for preview).
Configuration is highly customizable but the defaults are good enough that you barely need it.
I moved because Ghostty feels just like the native terminal but allows me to set the color scheme. I have it set to match the vscode Monokai theme.
No, macos Terminal will not let you use whatever colors you like. It will helpfully adjust the colors you select to increase contrast. And it can't be disabled. It bugged me for years.
Even more specifically, the full menu chain is System Settings -> Notifications -> Application Settings, which then includes a search bar where you can enter "Donation" or "Request for Donation". (Mentioning it since entering that term in the main search bar doesn't bring up any results)
It's similarly bogus here. Early Asahi development tried to upstream as much as possible but ultimately still maintained a gigantic pile of downsteam patches, which wasn't a sustainable model.
Most of current development is focused on reducing that pile to zero to get things into a tractable state again. So things continue to be active, but the progress has become much less visible.
M2 to M3 was a complete architectural change that will require a lot of reverse engineering. As far as I know no one is working on this. The M1/M2 work was a labor of love of largely one dev that has since moved on.
The project is still active and working to upstream the work of these devs. But as far as I know, no NEW reverse engineering is being done. Ergo, it’s a dead end.
People are already getting worked up about being prompted to opt into a new feature on update (even if that prompt is hidden behind an icon that doesn't do anything until the user clicks it), so it's not inconceivable that the kill switch just disables those opt-in prompts for AI-related features.
Just in case anyone's tempted to buy one of these now: Support is alright after heroic (and continuing) efforts to improve platform support, but it's flaky. M1/M2 devices offer better performance and the state of Asahi drivers is much better, particularly around audio.
Sadly compile times of LLVM-based recompilers make it impractical for competitive x86 emulation. We're not just talking a few single-frame stutters here and there, but considerable startup delays and pauses in-game.
LLVM's optimization passes also are less useful than you might think, since the vast majority of them is motivated by source->binary translation (like clang). They don't have much effect when recompiling an already optimized binary to another architecture.
I feel your pain on this one despite being fairly comfortable with nix by now. This is 100% an issue either the documentation or the nix CLI should do a better job at.
The wiki rightfully points towards "roots", i.e. references produced by nix-build or similar. Additionally, there are other places that will keep references and hence block garbage collection though:
1. Your nix profile (`nix profile list` / `nix profile remove`) and its old generations (`nix profile (wipe-)history`)
2. Your NixOS configuration (configuration.nix) and its old generations (`nixos-rebuild list-generations`)
It doesn't help that there's no discoverable way to tell why a particular nix store path is not being garbage collected either.
SUID by itself is not a security liability. Typically, programs using SUID quickly drop their additional privileges during startup to avoid the scenario you're describing. So the vulnerability in firejail would have to be early during startup before any of that.
Still, it can happen of course, particularly with memory-unsafe languages. Conversely without root privileges you have to sacrifice strength of your sandbox, widening the vulnerability window in the app you were trying to constrain to begin with.
Meanwhile bubblewrap relies on user namespaces, which come with their own set of security problems. They are disabled by default in many distributions for that reason.
I was already preparing myself to file a bug report with the easy repro, but this sounds suspiciously close to what the blog post is describing. Fingers crossed :)
(EDIT: HN filters unicode, booo :( )
reply