Until you need them, none. They sort of become self evident and you'll know when you're in the market for them. For now, don't waste time on premature optimization.
And now you read the release notes with dread as you witness more and more functionality being dropped because they choose not to maintain it. Luckily there is FreeBSD
Yeah it’s a shame. If Sun would have made Solaris (both SPARC/x86) free sooner, they might have prevented the mass exodus of companies moving off to save money.
In retrospect, they should have gone down the Sun386I path back in the day, instead of changing gears and spending $$$ building up the SPARC architecture and ecosystem.
If you create the files on the linux side as compared to shared windows folder, the performance seems to be good for me. Before vscode wsl plugin, the only way to work was to open files from windows and use the linux cli but the plugin made it so that you can stream files from the linux, which removed the need for using any shared drive for me. Perf bonus of switching to linux only workflow was significant, you should give it a try.
My experience with NFS over the years has taught me to avoid it. Yes, it mostly works. And then every once a while you have a client that either panics or hangs. Despite the versions of Linux, BSD, Solaris, Windows changing over the decades. The server end is usually a lot more stable. But that's of little to no comfort to know that yes, other clients are fine.
However, if you can tolerate client side failure then go for it.
Best of the bad options doesn't make it a good option. It's far from reliable and one of the most common reasons I encounter for deadlocked Linux systems. Well, to be fair, it also hangs a fair share of BSDs and sometimes even a Solaris. If at all possible, I'd suggest avoiding it.
True. Luckily, most Go binaries can be upx'd ( https://upx.github.io/ ) for a fraction of their original size. Just put it into your Dockerfile as a part of the build process.
This works and helps with storage/transit. Word of warning though that many AV like to flag UPX'd executables (only important if it's not an internal tool), and it'll take even longer for it to start, and will use more memory. My understanding is it essentially does standard compression on the executable and appends the decompression part on the front of it.
