I certainly wouldn’t say it was incompetent and there is a good set of data points. Given the nature of what the study is attempting to correlate, not explaining what limitations were taken into account is a a significant limitation, IMHO. It is called out that there are limitations, but that it is essentially just a short footnote. (The full paper does a better job of calling out other studies and some contradictions.)
This referenced study found the opposite and had a no (or weaker correlation) to cancer associated with SSBs: Khairan P, et al. Sugary drink consumption and the subsequent risk of gastric cancer: Khairan P, et al. Sugary drink consumption and the subsequent risk of gastric cancer: The Japan Public Health Center-based Prospective Study. Eur J Clin Nutr 2023;77:218-25.
Without doing a comparative analysis of the studies, which would be interesting, I have open questions about what the key differences were. My first guess (without calling either study “wrong”) is that maybe risk factors were calculated differently?
On the darker side, there is motivation for keying-in on a specific correlation and that cannot be ignored either. (Past grants, groups requesting the study, etc.) The original paper also sets itself up to be a marketing call-out for artificially sweetened beverages, unfortunately. (I am not saying that is the intent, but the wording aligns exactly with what vitamin water-type company would want to see. It made for a good Lemmy post title, at a minimum.)
At the end of the day, they stated what they were looking for and presented what seems to be a clean analysis of that data. The limitations that were presented have the potential to be significant, however.
Also, it depends on the problem you are trying to solve and if the good deal lets you buy plenty of spare drives.
I have a 3 server cluster running 9 k8s nodes with persistent storage in Longhorn. While it thrashes the drives a bit more and I lose performance, I opted to use hardware RAID so a drive rebuild would be much easier. (I think with Ceph, it’s a step or two more to kick a drive out of the storage pool before you can swap the drive safely. The fact that I can’t remember much about Ceph already and it’s only been a month or two since I setup a Ceph testing cluster should alone explain my decision.)
Basically, I get volume replication backed by easy to manage and affordable drive replacements. I even get mirrored boot drives too. The setup is fault tolerant to a degree and it gives me enough time to shuffle things around if a server starts to die completely.
All the drives are used and have already had a full life, but yey, the risk is ok because the parts are cheap. I’ll probably buy another refurbished server of the same type just for the spare parts, drives and memory. I could even just use the extra server as a cold standby. Whatevers.
The cluster isn’t critical, to be perfectly honest. It really just holds a massive tool suite of containers that I need at random times and now I at least have solid templates and ansible confogs for all of those containers anyway. Even the data isn’t super critical.
Parts are cheap and my setup allows for disposable drives in a setup where risk tolerance is sky-high.
My NAS is RAID 10 with brand-new drives and read/write cycles are conserved. I care about that data and will probably mirror that storage that to an additional pair of mirrored m.2’s to absorb most of the read a cycles while adding an additional redundancy layer. (The hdds would primarily only see write cycles and probably just function as an incremental backup location for specific folders off of the m.2’s.)
Those are the cliff notes, and only I attempted to explain how I thought about risk in my setup. Volume over quality for my cluster: I think about fast recovery and how I can parch around a problem during a catastrophic failure. Long term: Multiple layers of redundancy for important data with less concern about price but I have less capacity and speed.
Having spent years around lots of equipment, I view a flashy red light on an HDD as a suggestion to do something about it in a couple of days if the server is just a worker node. (I have been desensitized to most hardware faults, TBH.)