To my knowledge, it's not so widespread known that compiling with gcc works way faster using Linux and its ext4 filesystem than using the same compiler using Windows and NTFS. I've experienced speed differences of 5 ... 10 faster under Linux than Windows on the very same hardware (natively booting either Linux or Windows from the same SSD). In some forum I was told this is a major flaw of the NTFS filesystem, having a "global lock" for all accesses, slowing down anything that uses a lot of file I/O.

One can notice the difference too within WSL2 (the Microsoft attempt to draw linux developers to Windows), if one compiles on the ext4 filesystem of the virtual machine or the mounted NTFS.

In response to "Source Controlling Tools" I have one method I have used with personal work, thought not at any paying job.  I create a VM with all the correct software, including OS and settings, while the system is current.  I make sure that builds on the VM come out exactly the same as the native software.  Then I can archive the entire VM and have it available later when some part of the setup is no longer available.
Two flaws with this.  One, if any part of the setup has to access the "cloud" to run we are back where we started.  Fortunately, most tools don't have to, even if they do access it.  The second flaw is, what if we no longer can run the VM?  
But, it's a partial solution.

Just a thought, but couldn't you install the suite of tools into a VM, then save the VM for future use? When you need to maintain that product, restore the VM and you're back in business. Another thought would be to use a cloud VM, back it up of course, but with some cloud vendors you can pay by the hour of CPU use and just leave it dormant most of the time, essentially costing nothing. Then you have the tool, libraries, exact system libraries and OS version, etc. Probably way behind on security patches, so you would want to consider how/whether you attach to the net.

Of course these are still subject to the VM vendor and cloud vendors maintaining compatibility for a long time, but, when they do make breaking changes they may have a VM-level upgrade process that allows you to stay current.

I've run into this issue before and one approach that might work is to install the tools in a virtual machine, export it (i.e. as an OVF image), and archive that instead. An additional benefit to this process is the virtual machine image can be used as a reference for developers when troubleshooting issues with their development environments; if you can import the VM and build the project inside of it then it's an issue with your local environment. The only downside is it typically requires a lot more disk space than just archiving the installer(s) and depending on which OS you use inside the VM you may have to learn a lot more about licensing than you'd otherwise want to (i.e. Windows).

What about installing OS+Tool into a well defined open format of virtual machine or container (e.g. OVF, qemu, bochs, docker, flatpak).
But still a "player" is needed which can interpret this.
There is some gossip about "nested virtual machines".
I don't know whether this what you expect from it’s name, and how mature this capability is now or when the last version of player which can handle your selected virtual machine or container format no longer runs on any OS which fits on your then current computer.

For my (personal) ARM Cortex projects I keep a bunch of compilers in /usr/local/gcc-arm-none-eabi-xxx and explicitely refer them from the Makefile that builds the projects. No fancy IDE involved at all. For a very particular old project I still have some old MS-DOS compiler wrapped into scripts calling DOSEMU and embedded into a gnu Makefile.

The project uses a weird combination of 32bit host gcc, embedded target gcc and said special compiler for a DSP - all integrated into a single "make all". This started on a side-by-side setup of a Win95 and a Linux computer back in the 2000's, and still works today on a modern 64bit Debian 11 machine.

   - 'A' is the amplitude of the generated sine wave
   - 'N' is the number of values in a period... So between each successive sine value there is an angle of 360°/N.

It is an very simple IIR "inverted Goertzel" filter that will happily generate a nice sine wave of 'A' amplitude and 'N' points per period with minimal computation:

d_theta = 2*π / N
c  = 2 * cos (d_theta)
y(0) = A * sin (0) 
y(1) = A * sin (d_theta)
...
y(n)  = c * y (n-1) - y (n-2)

Of course as 'n' increases computation errors will accumulate, so if needed we will have to "regenerate" the 'y (n-1)' and 'y (n-2)' values from time to time.

As I understand it, this filter is a perfect infinitely-narrow band-pass filter excited by a pulse. But I am by no way a mathematician ;-)

May I comment on Steve King's point about sending debug data to the cloud, in the last issue? This got longer than planned, but I think it could be of general interest. I tried to stay at the general principles and not promote DevAlert too much. If needed, I can propose a shorter version.

Uploading debug data to the cloud can indeed be sensitive and opt-in is required if you don't already have permission to use the data from the device. However, many devices today are provided specifically for use with an associated cloud service, meaning there already is an application data stream to the cloud. This typically includes some form of customer data, such as sensor readings, and this is structured data intended for automatic processing. In contrast, the debug data only provides snapshots of the software behavior, where any application data that happens to be included isn't explicit or easily available for automated processing. So in this context, debug data is not necessarily more sensitive than the already provided application data. But of course, developers still need to be careful to not include sensitive customer data in debug data uploads. We have therefore designed DevAlert to be 100% transparent for the OEM and allow for detailed control over the included data.

Implementing remote debug monitoring in a secure manner isn't a walk in the park. It takes some consideration. But the alternative is basically to stick your head in the sand and remain unaware of the remaining software defects until customer complaints are piling up and the damage is already done. Moreover, each latent defect is not only a potential disruption for the end user, but also a potential vulnerability. With remote debug monitoring, such defects can be detected and fixed quickly after the very first accidental occurrence, before being exploited or causing widespread disruptions.
 
In my view, this is a choice between the hypothetical risks of using a specific monitoring framework compared to the very real risk of unknown defects and vulnerabilities remaining somewhere in a large code base, often 100’s of KLOCs with many 3rd party libraries. The next question is probably about the security of the proposed monitoring solution. Let me share the security principles we have used when designing DevAlert. I'm of course biased, but believe these are good principles for any monitoring solution of this type.

1. No direct communication between the devices and the DevAlert cloud service, but instead piggyback on the existing cloud connection already used for the application data. The integration with the DevAlert service happens in the cloud, using secure HTTPS calls with two-way certificates.
 
2. Don’t risk creating new attack surfaces in the device. The DevAlert device library doesn't introduce any new communication code or listens for inbound connections. One-way communication only and only transmits data when requested.
3. Minimize data needs in the cloud service. The DevAlert cloud service only ingests user-defined "fingerprints" of the issues, needed for aggregation and notifications. The ELF file and debug data stays in the OEM's private storage at all times.
4. Debug data is only analyzed locally on the developer's computer, using e.g. Tracealyzer and GDB.
This way, the debug data is handled in the same way as regular application data and with the same level of security. This obviously assumes a secure cloud connection, such as MQTT over TLS, but this is today provided by most IoT cloud vendors.

You had an interesting point that the remote IP address could reveal the device vendor to an attacker sniffing the Wifi. That would certainly be true if the device is contacting a company server directly, e.g. like “product.xyzcorp.com”. However, that is not the case when using a 3rd party IoT cloud provider, like AWS or Azure. The remote IP address then only reveals an anonymous endpoint at the IoT cloud provider, like "asdfghjk123456.iotcloudprovider.com". While it might be known to the attacker that a certain product is using this particular endpoint, this is not revealed by the Wifi connection alone. The risk that the remote endpoint might reveal the device type is a general risk with any connected device, even though security shouldn't rely on obscurity. However, when using our approach, that risk is not increased since the debug uploads are added to an existing connection. Moreover, remote debug monitoring could help the vendor detect and patch such vulnerabilities before being exploited.

If you have any follow-up questions or comments, feel free to reply or contact us directly using the contact form on our website, https://percepio.com.