Given that RP2040 needs external flash, I'm quite worried about the performance when pulling uncached code from it (on top of using M0 core - I'm used to M4 by now). I know the MCU has 16kB of cache, but my firmware for which I'm still deciding on whether to port it to RP2040 or not is about 80k. Does anyone here has some real-life data on this?
(Author here). Because the firmware size is about 70k right now for AVR, and ATmega32u4 has only 32k of flash. Black Pill STM32F4 boards are supported though, and soon 3 more STM32 boards.
I sigh every time someone says deadbeef is great alternative to foobar2000. The greatest thing about foobar2000 is media library which deadbeef doesn't even have. Actually, no other player on the planet can compete with foobar's media library. I'm not sure what kind of magic it uses, but the second I put new files in directories where my music is, foobar2000 sees it and I can access it in foobar. Sometimes, I listen to a random track and decide I want to hear everything from this artist that I have in library. I press 'a' on a selected track and I see everything from this artist. I press 'A' on a track and I get everything from this album. I press 'q', type few letters in search bar, press enter and I get new playlist with the results. I press 'o' on a track and it opens a file explorer in the location where the track is located and it also selects it. Quite useful if I want to move it somewhere else or copy it or rename or whatever. These are all my custom shortcuts but I love the fact that you can assign shortcut to virtually anything. There's also tag editor and format converter. There's also really cool feature that you can queue any file you double click in file explorer in its own playlist (I call this playlist Inbox), so that the playlist I'm currently listening is unmodified.
Closest thing I found on Linux is ncmpcpp and it's still a far cry from everything I can do in foobar2000.
At my previous job, "Formatting" task was the first thing pipeline did. It was really simple - it ran the same "make format" target you could run locally, except it was configured in a way to fail if running "git diff" afterwards resulted in any changes when running on the build server (git diff -s --exit-code). Of course, when this failed, none of the other tasks in a pipeline ran so it forced you to format your code correctly if you wanted to see build results. You could just commit the next commit with "formatting" message but the idea was to just change the history since commiting was happening on dev branches - only when everything in the pipeline passed things could be merged on stable branches.