They have little experience producing code that is high enough quality it would be accepted into Linux kernel. They have even less experience maintaining it for an extended period of time.
They have little experience producing code that is high enough quality it would be accepted into Linux kernel. They have even less experience maintaining it for an extended period of time.
Unless you want to charge in negative temperatures
> However, this battery faces range limitations
Yes they are less dense but plentiful for typical passenger car (and not so much for full sized trucks or even "mid-sized" US SUVs).
> the issue of how to improve charging speed
I think CATL demonstrated 1MW charging on these already. Definitely shipping 500kW charging (tho best measure is still average km/hr).
> Solid-state batteries should be the next big thing
Sodium will (great cold weather performance and even better charge rates), but it's less (vol) dense and prices won't reach LFPs for another 10-15 years (unless you believe hype, not actual analysts).
Also LFP prices dropped enough that shipping cost from China became a significant part of the price. This will be even more of a factor should the less energy dense sodium batteries ever reach the promised $30/kWh.
- you underperform while onboarding and rapidly learning to cover whatever skill gaps you discover
- you slowly go from doing OK to being overqualified, but it doesn't get reflected in compensation or title enough and your employer has little incentive to help you reach the next stage, because you are currently overperforming compared to your pay
- you are so much past your paygrade you quit and go to a company that will pay you what you will be worth after onboarding and learning to cover skill gaps
With everything that companies provided to earn long term employee loyalty being sacrificed to stock price employee growth through multiple roles in the same company has become more of an exception.
Source: most of the companies I worked or consulted for in the past 20 years.
I find valgrind easy on Linux and ktrace(1) on OpenBSD easy to use. I do not spend much time, plus I find testing my items on Linux, OpenBSD and NetBSD tends to find most issues without a lot of work and time.
You can do a decent hardening job without too much effort, if follow some basic guidelines. You just have to be conscientious enough.
I would love to say that this was an exception during almost 20 years of my professional career, but it wasn't. It was certainly the worst, but also much closer to average experience than it should have been.
In the world of VC powered growth race to bigger and bigger chunk of market seems to be the only thing that matters. You don't optimize your software, you throw money at the problem and get more VMs from your cloud provider. You don't work on fault tolerance, you add a retry on FE. You don't carefully plan and implement security, you create a bug bounty.
It sucks and I hate it.
You also get UMR from AMD https://gitlab.freedesktop.org/tomstdenis/umr
There is also a bunch of other tools provided: https://gpuopen.com/radeon-gpu-detective/ https://gpuopen.com/news/introducing-radeon-developer-tool-s...