I am interested in that battery research though, because charge-cycle wise, only lithium iron phosphate subsection of EV battery chemistry would last even near that long. Lithium ion only lasts 500 cycles before degrading to 70% and LiPo is only 1000. My ID4 could do 420 km on a charge, assuming a LiPo composition, that is 420k kilometers, which is a quarter of what you say

Battery cells degrade very different depending on how they are used. The cycles you mention are the typical values for charging up to 100% and then emptying them completely. This isn’t how EVs are usually driven. Cells that are only charged to about 80% most of the time live longer. And with large arrays of cells as in an EV battery, the charging electronics also don’t just charge and discharge all cells evenly but can optimize for lifetime. Many EVs also don’t charge all cells to full when the car says it’s at 100% to increase the lifetime (that’s why you sometimes see a “net capacity” mentioned, it’s the amount of energy the battery management actually allows compared to what the cells could do).

There are also studies that show that typical usage patterns with small charges all the time (from recuperating) and having long rest times (when the car is parked somewhere) results in a much longer lifetime than simulations with constant use had given, e.g. here: https://news.stanford.edu/stories/2024/12/existing-ev-batteries-may-last-up-to-40-longer-than-expected

Battery chemistry is of course also something there is new developments in, for example CATL is starting production of sodium ion batteries, but AFAIK these are more about cost per capacity than lifetime.

I used fzf before atuin, and it works pretty similar, but atuin has a few additional features, as it tracks more information than the normal shell history. For example, you can also search only for commands that you executed in the current directory (great for stuff that is project specific). Or, if you use the history syncing feature, you can toggle search for commands you executed on either any or only the current machine.

In zsh, you can configure the completion to also show descriptions.

You also need a powered adapter for HDMI 2.1 in this case. The passive adapters work, because the DP output on the computer usually supports switching to HDMI output. But for that to work, the driver must support it, so it has the same problem as the HDMI port (which supports 2.1 on a hardware level, but not with AMDs open source drivers)

If you want 120Hz, only active adapters will work, which cost around 40$. If you don’t, the included HDMI 2.0 will be enough

If you don’t need 120Hz, you don’t need HDMI 2.1. You can get 4k @ 60Hz with the HDMI 2.0 that the Steam Machine has, so you can use just any TV.

Passive DP-to-HDMI adapters only work if the device on the Displayport end supports Dual-Mode, i.e. using the Displayport to send an HDMI signal. They often do, but it would require the same driver support for HDMI 2.1. So this would require an active adapter.

Thank you, from a quick glance it seems to be able to do everything I need. I will try it for my next load test.

The only thing I still use Postman for at work is when running API performance benchmarks, as I wasn’t yet motivated enough to write a curl wrapper to do such tests and plot the results. Especially when doing things like ramp up etc. it becomes more than a simple for-loop.

Can someone recommend an existing command line tool for that?