Any idea on their plans to monetize? I assume they will eventually charge, since they raised a 10M series A.
The good news is that if you used OpenCore + vanilla macOS install (basically if you followed the excellent OpenCore Install Guide [1]) and don't have any weird hardware (Intel CPU + iGPU / AMD GPU) you can pretty much just perform updates as normal through Software Update. It is certainly important that you make a backup of your EFI (might as well make a backup of the entire drive you can restore to in case something goes wrong) as well as double check the OC guide to see if there's any snags to look out for when updating.
One time-consuming thing I did when I ran a Hackintosh was to have a separate drive that I used as a macOS update test bed for major versions, and then if all went well I would perform the real update on my main drive.
I would also recommend you look at /r/Hackintosh and maybe ask around there for any advice.
Good luck!
This is a great idea. I'll probably give this a try. Last time I tried to update macOS (AMD GPU OpenCore build), I had to restore from backup. Haven't tried again since.
We'll charge money for our backend service that powers collaboration in Zed. We have ambitious plans to improve the way that people work together on code. So far, on that front, we've been focused on real-time collaboration, but we have a lot of ideas for how we can improve asynchronous collaboration as well, by having discussions take place directly in the code editor.
Especially, since Zed does have a very clear distinction/dividing line of "completely functional local editor" == permissive open source vs. "all of the real-time & async collaboration features" == proprietary that is easy to explain.
Frankly, I would happily pay for great, fully supported, high-quality real-time collaboration for my teams.
Anyway, as you can see, not having any useful progress on this front instantly shuts down lots of people and there's many of us who won't even consider doing more than checking it out until this is done.
However, my first impressions of the keyboard navigation aren't great :(
More generally, this looks really awesome and also really enjoyed your team's blog post detailing the GPUI implementation (even though large parts of it went over my head)
There's an issue for it: https://github.com/zed-industries/community/issues/75
* Seems to me that a lot of the keyboard shortcuts are chords or require hitting an arrow key, sometimes even both. Example: VS Code's default mapping for vertical split is cmd+backslash, but Zed requires cmd+k -> arrow key.
* The project panel (file tree) doesn't support hjkl for navigation. The website says Vim mode is still under construction, but in my mind that applies to actual buffer editing, not general UI interactions. My impression is that today most editors, hell even a lot of websites, support hjkl or similar for navigation in cases where it doesn't conflict with anything else.
My perspective is that "keyboard-focused" implies "ergonomic shortcuts and UI navigation without leaving the home row". If I'm gonna move my hand from the home row to reach the arrow keys, I might as well just reach for the mouse and get 10x the possible interactions. Anecdotally, I tested myself just now and I'm pretty sure it takes me more time to "find my footing" when I move my fingers to the arrow keys than it does to just grab a mouse and click something.
This might be wrong expectations on my end, but my hope is that Zed can bring the powerful navigation of Doom Emacs/Spacemacs minus the bugginess and terrible performance of Emacs. Whenever the devs talked about Zed, I just imagined VSpaceCode without the jank that comes when you override 90% of an editor's default bindings. What I'm seeing from an hour of usage doesn't feel that much more powerful than VS Code in terms of keyboard navigation (kudos on the snappy performance though, it really is night and day). I'm aware this is an early beta, I just hope you folks agree and are going to push more in this direction.
They talk about things like having a plug-in type system in the future based on e.g. WASM but, as you're pointing out, their fundamental perspective is built around the simplistic notion of a control panel with fixed functionality that's primarily accessed via a bizarre set of keymaps. On this front, might as well stick with JetBrains.
Checking out Spacemacs or Doom Emacs would give a clear idea of what I'm talking about.
If unfamiliar with emacs, VSpaceCode is a VSCode extension that ports Spacemacs-style keybindings pretty successfully, although the UI is suboptimal due to limitations of VSCode extensions.
Would be great to allow toggling visibility of each of these pieces via an action to maximize screen real estate. Really annoying in VSCode that they force you to go into settings for some of the visibility toggles. Of course, didn't spend very long investigating.
Also after selecting VSCode keybindings, CMD+\ does not split the editor as it does in VSCode. Seems like a bug