ligma_centauri

Just did a cursory read of the commits related to security for this release, and my assumpion based solely on the changes, is that it's not a remote-access vulnerability, but a supply-chain-esque vulnerability where a video you downloaded from a questionable source might trigger code embedded in the metadata to be run by jellyfin.

Do you have multiple NIC? I sporadically run into issues where traffic will try to route itself via a secondary network which has limited external access and it is resolved in a similar manner, by bringing down all networks, then re-starting them in a specific order.

Realistically I should probably define some static routes, but it works automatically 99% of the time so I never bother.

If this sounds like a possible cause, check your routes while in failed, and functional states, and set static routes as needed to resolve.

My money is on Putin knowing that his war is not winnable, but not being able to save face internally by admitting as such. If he can poke the bear enough with incursions into NATO countries like the last few days though, he might be able to draw NATO into direct conflict, at which point a withdrawal/surrender can be sold as "We were attacked by the big bad NATO and had to consolidate our local defenses" rather than a defeat by what should have been an inferior force.

Eh, it's one of those perpetual rivalry things where the answer will probably never be known, and doesn't really matter except when it comes to petty squabbles between nations.

That answers my question. If the USB dongle never disconnects from the machine, then I wouldn't expect anything to show in dmesg, as the 'sleep mode' is likely occurring downstream of the USB dongle.

Are there any config utilities that came with it? Failing that, maybe wireshark the dongle and see if there is any sort of sleep/wake signal being passed back through to the host machine?

Le pavlova etait un plat de nouvelle zealand. Si Bluey connais la, c'est parce que la recette etait vole.

Add accents to your pleasing...

No I don't.

Many but not all will have a 'total TBW' metric, but that is more of a 'how many write cycles can this theoretically last' metric. What I am predominantly interested in is "how many TB can be written before sporadic write delays start occurring"

The best way to learn it, is to set yourself a goal/problem, define as best as possible how many unique issues that problem can be broken into, then start solving them one-by-one, periodically stopping to evaluate how they fit together.

Learning the best languages and structures to use will come as result of this.

^^ that person first though.

That may not be their intended purpose, but it is something we take note of when responding to an MVA. "Who else was in the vehicle" is a pretty standard question to ascertain if someone has been ejected, or is currently entrapped in the inaccessible wreckage, but if we notice a 'baby on board', we always make sure to also ask something along the lines of "where is your baby", just to be safe.

The thing that is always painfully missing from any benchmark, is an endurance test.

I want to know how many TB I can write consecutively before the disk starts to degrade in performance and stop being useful. So far the only way I have been able to achieve this is to purchase a couple of every disk and stress them until failure, logging that interval, and selecting the winners for usage.

I do not care about how fast it can write over the course of five minutes, I want to know how fast it can write over the course of five hours continuous usage.