Maybe I misunderstood what you meant, but Zed is not atom-based. VSCode and other editors based on it have direct Atom ascendancy, however in the case of Zed is mostly in the developer team, and thus many concepts about what an editor should be are similar or evolved from those in Atom.

Many IDEa are slow because they are 1) written in Java and/or 2) they integrate the debugging information in the editing structures in a suboptimal way and/or 3) they have a heavy user interface and/or 4) the internal data structures of the editor are badly conceived to start with.

A lot of programmers that understand debugging have limited understanding of text editing, and so on. Understanding of efficient algorithms is today less widespread than it used many years ago, even though we know a lot more of very efficient algorithms, esp. heuristic ones.

I used IDEs capable of debugging and interactive code manipulation on a Mac 30+ years ago. And they were relatively snappy. There is no reason they should not be extremely snappy today, except library and UI bloat, which often happens today in almost every piece of SW.

Integrating gdb-like functionality in an editor like Zed should not be too difficult. In fact, an interface over gdb should be easy to code, but they have limited time and resources (mostly human).

Not yet, and I am not sure there will even be one. It is meant to be a project-oriented editor, not an IDE.

To me it speaks that it manages to be sleek, fast, have an uncluttered look, and not relying on humongous things like Electron.
Also, there i actual research on the data structures behind the scenes. I helped a bit optimize the choice of memory allocator and parameters for the lengths of the ropes. It can load very large files almost instantaneously.

It has a few rough edges and some features are incomplete, but it has enormous promise. The windows version is coming out soon.

Zed speaks vi very well. It has an actual vi mode and almost all keybindings are the same.

True. Neither can most student, though.

Was is the Orange Pi 5 or a previous Orange Pi N with N strictly smaller than 5?

I believe that almost all consumer sound products have always been crap. The main difference is that today you can get also extremely good equipment at fair prices, be it some second hand classic vintage stuff or some modern DAC (sub 1K$, based on Sabre, CS, Rohm or AKM chips) an essentially perfect amplifiers that have no audible distortion, noise and frequency variations and that can drive almost any speaker around (for instance the NCore or Purifi offers). So the situation today is actually better, even though the snake oil vendors are trying to tell you you need a 500pound turntable, a set of D'Agostino amps driving Wilson Chromosomic speakers.

You can indeed disable SIP also on an Apple Silicon Mac. I know because I did it to let SwitchResX add new resolutions to my MacBook Air's display.

Isn't this what Alexander Graf has achieved? Of course this is not official, but we can still hope.

And with the new machines you can get one machine that can run all 3 major operating systems, on "both" architectures!

Well, no. The ARM architecture (and IP) defines a ton of aspects of the architecture, in particular how the cores interact with the Caches, the interconnect, and the peripherals. Whereas several components can be adapted to work with different architectures, and some are connected through industry standard interconnects (such as PCIe), many other components need to talk to each other using a specific set of protocols. The ARM Architecture is not just a ISA, it is a complete Architecture. So, by taking out ARM cores from an ARM-based SoC and replacing it with something different would result in IP infringement. There is a ton of work going into architecting several aspects of the complete architecture - in fact more work than "just" the ISA. RISC-V is at the moment not much more than a set of ISAs.

I was quoting the person above me. What you are quoting is in quotation marks in my message...

I was quoting the poster before me. I am perfectly aware of the economy of scale of Apple. But, yeah, I used quotation marks because I was sleepy :-)

They said that they have that (when you install the app, it is automatically translated), AND that they also provided patches to various JITs to allow them to output the new native code in place of x86.

Translation and compilation are the same thing, to the point that in German they are the same word "Übersetzung". Translation just by replacing some instructions with other ones and not applying further optimisations is just a very simple for of compilation. A more usual "C" compiler translates human readable source code ito machine code. So, yes, Rosetta 2 is NOT re-compilation from the source, but you can use current binaries as a description for a state machine and then re-compile the latter to a different architecture. This is not a novelty in computer science.

Disclaimer: I am one of the Senior Principal Architects in ARM's Architecture and Technology Group. You know, the team that designs and maintains the Arm architecture. Perhaps you should be careful with your words. Apple said that Rosetta 2 automatically translates applications at install time. Whether this is in fact actually done once you drag an app onto your disk, or lazily the you first open it, or lazily and gradually, with cached translated code, is completely irrelevant, in effect.

"Or there could be continuous optimisation performed under the hood."

LOL, sure, while only doing the "re-compilation" once.

Yes, there could be a simple initial translation, and then analysis of the code sections the take up more time and are executed more often, which could be gradually replaced with more optimised versions. Microsoft does that already. As other technologies previously. Before engaging in these arguments, please inform yourself.