Porting complex applications (especially those written in C) from x86 to ARM can be pretty non-trivial.
I can't speak to the GIMP code in particular, but I've done several x86->ARM source ports of other complex software, and each time there are things which work on x86 and don't work on ARM, resulting in nasty crashes, or worse.
GIMP already supported ARM though, this is about "Apple Silicon". Since the post itself doesn't mention specific challenges, I guess it serves more to inform macOS users of the availability than foster discussion or provide any insight.
We live in an age where combining music, software, and signal processing can let you do some amazing things. I can imagine a high-fidelity simulation of this instrument's timbre before it's ever built, by using the mechanical CAD model to produce an acoustic model, and then modeling the response of the wood to an incident acoustic wave.
The whole world of software ports basically boils down to "anything is possible, given enough memory, pixels, and time". The actual process of porting anything is sometimes incredibly tedious (e.g. "scour the entire source code for unaligned memory accesses, and manually rewrite all of them"), but also gives a chance to do some very clever things (like, "use the piezo speaker to beep out the address of a fault, because nothing else works on the device after a crash").
What made me do it was 1) the satisfaction I got from seeing my work produce something which, at first glance, shouldn't exist (Quake... on an MP3 player?), all while 2) learning deeply about software close to the bare metal, which is fairly hard to do early in one's career. There's of course also the factor of having lots of free time - I did my port when I was still a student with not very many responsibilities, so I could afford to spend entire evenings and weekends poring through mountains of C code. Nowadays, not so much...
Huge respect! I think that porting Quake like you did is much more impressive feat than my port to the Watch!
Totally agreed with the reasons for doing ports, huge satisfaction and learning experience; which applies to all of the programming OFC, but here, you also learn from the original codebase (which is in case of Quake phenomenal).
I loved Rockbox on my iPod nano, Then Apple recalled the device due to a battery issue and gave me a 6th gen nano whose signed bootloader meant no more Rockbox.
So if I have to sync songs now on Linux, I need to spin a VM; Sigh.
The whole world of software ports basically boils down to "anything is possible, given enough memory, pixels, and time". The actual process of porting anything is sometimes incredibly tedious (e.g. "scour the entire source code for unaligned memory accesses, and manually rewrite all of them"), but also gives a chance to do some very clever things (like, "use the piezo speaker to beep out the address of a fault, because nothing else works on the device after a crash").
What made me do it was 1) the satisfaction I got from seeing my work produce something which, at first glance, shouldn't exist (Quake... on an MP3 player?), all while 2) learning deeply about software close to the bare metal, which is fairly hard to do early in one's career. There's of course also the factor of having lots of free time - I did my port when I was still a student with not very many responsibilities, so I could afford to spend entire evenings and weekends poring through mountains of C code. Nowadays, not so much...
There is no way this could work. The EDA tool (e.g. KiCAD) is only the first step of the fabrication process - you generate Gerbers from your KiCAD board layout, which are a highly standardized format that can be viewed in a variety of independent pieces of software. There are also multiple stages of design validation - both in the design phase, and then in the physical phase of actually inspecting your fabricated boards. The chances of any "malicious" circuitry slipping in are next to nil.
College students are just as smart as graduates and they tend to have much more time on their hands.
So yeah, this is cool work, kudos and everything, but the fact that a college student is doing it is the least surprising part of it if you really think about it.
The idea is that wrapping a function around a circle at the right frequency (i.e. length per spiral) will cause peaks and troughs to align. It just happens here that the "right" frequency is 1/year.
Completely off topic: do you have a Rockbox-compatible, dumb, tiny, cheap music player to recommend for running? I burned through three or four Sansa Clips and Sansa Clip Pluses over the years, but those lines are now discontinued (and I refuse to participate in the scalping refurbished market), and my last one just died.
The AGPTek Rocker is one of our last targets still in production and can be acquired for around $50. I haven't used one myself, but from what I hear it's fairly decent but not perfect.
I can't speak to the GIMP code in particular, but I've done several x86->ARM source ports of other complex software, and each time there are things which work on x86 and don't work on ARM, resulting in nasty crashes, or worse.
See here for one of those (not AArch64, but ARM nonetheless): https://news.ycombinator.com/item?id=22176285