There is certainly a requirement that prevents payout on the contract for those supers if performance numbers aren’t met. Further, those performance numbers are from real apps, so the system WILL be useful. Not getting paid is not an option, so performance/usability will come.
how does that contractual obligation translate to technical implementation? Do those supercomputers get an optimized version of ROCm to fulfill said obligation?
Absolutely. You usually end up with software stack where NOTHING can be updated, most of the stuff is forked with custom patches and the learnings there aren't reusable elsewhere because the code is full of "// replace this with hardcoded constant 59843 because it prevents crash on HPC machine".
It's a good marketing metric, but probably contraproductive the AMDs longterm success in the field. They're spending engineering time building something they'll unlikely to be able to translate into other fields.
Vendor iterates until client gets an usable environment, even if that means 50 forks of different libraries with custom patches that in the end work only on that one system.
Contents of the display are often added after the fact in marketing materials. The person adding the wallpaper probably just didn’t notice the photo was flipped.
I have been leery of VSCode for this reason. The bare product isn’t very special, so you have to download extensions to get the functionality you need. However, there is nothing keeping the extension from communicating. Suddenly, you get malicious extensions that leak data.
It’s not just malicious extension authors. Compromised developers of good extensions are just as much, if not bigger, of a risk.
> It’s not just malicious extension authors. Compromised developers of good extensions are just as much, if not bigger, of a risk.
If this is your reason to avoid VSCode, then you should probably start avoiding basically all other code, too. It is after all written by developers, who can and has been compromised. All over the supply chain. Over and over again. And so on.
replace VSCode with any other code editor and it will still work.
Vim, Emacs, Sublime are all examples of bare products that aren't very special unless you add extensions that could potentially leak data and run arbitrary commands.
the fact that only a couple extensions have been found leaking some data involving only a few thousands installs, it's honestly a very good record if you ask me.
I mostly use it for writing C, python, latex, and bash. I know I’m losing a bit of efficiency by not carrying a config, but I consider configless emacs a bit more capable for my workflows than configless vim.
The cynical part of me thinks that the bad web app is intentional. They can get much more data from you if you use the app, so they want that to be the best experience. All others should be bad enough that you will only use it if there is no other way to give them your money.
RPi2 is pokey enough that you really feel the limitations of the platform when you put Linux on it. Sure, you can run the kernel, but you are going to want to stop short of, say, any web browser that can function well on today’s web. Even a RPi4 isn’t a good daily driver for web browsing.
Part of the magic of these bare metal language environments is that you run against your own limits before you reach the limits of the hardware, especially in a hobby coding context. Linux makes it much easier to outstrip the CPU and RAM available in RPis.
