Also the "Alternatives and Tools for Dependency Control" straight up broke and the newlines are literal \n's so whoever posted it didn't proof read it but still took the time to bold the many headers.
> Reasons include: Highly Structured & Uniform Sections, Blend of Technical Detail and Colloquial Humor, and Repetitive Themes & Transitions.
According to 03-mini-high there is a high likelihood this was generated by AI /s
"I think this is AI" is the least interesting, lowest-signal comment one can make here on HN, beating out perennial contenders "I hate this scroll bar", "this site hijacks my back button", and "why does this site require JavaScript?"
If you can actually make an AI detector that works, do that and print money for yourself. Otherwise accept that all "AI detectors" have massive false positive rates, your intuition included.
If visitors like what they see on the page, they will up vote it. If they don't, they won't. That's how HN works.
Another aspect is that, if someone took a much simpler, more readable and concise version of the content in the article and fluffed it up with an LLM it can come across as rude or time wasting like articles that are artificially extended to maximize ad impressions.
Skimming over it, I do get that impression too. It's poorly organized and lacks the respectful touch of some common human aesthetic, overusing phrasings like "X world" 16 times and even uses "labyrinthine" 5 times.
In an article about an important topic like dependency risks, you want to make sure there is some deeper competency informing the article so you get the most actionable advice with the least amount of time waste or at least something which rouses high quality discussion about the topic at hand.
Whatever the case, generated or not... it's a bad article. There is room to sarcastically imitate LLM output for comical value, but this article wouldn't be the place for it if that was the case.
I have no answers: just questions that haunt me, from time to time.
xz vulnerability -- Thus happened because a patch was added by some Linux distros to add functionality for other packages. If openssh was not patched and kept as the OpenBSD people intended, the vulnerability would not have happend. The article seems to indicate it was caused due to other reasons. IIRC, this only affected systemd distros. *BSDs and Slackware did not have this vulnerability.
Yes, Linux and to a far lesser extent *BSD are living in dependency hell. Windows are worse off.
But UN*X systems were initially designed to be simple, but many people want to make these systems into M/S Windows Clones. Until UN*X Type Systems get back to their roots, I see no resolution.
FWIW, the way BSDs are designed, you can avoid a lot of this because they separate third party applications, these are installed outside the base system. People in the BSDs mostly know there are risks to using 3rd party applications, but unlike Linux, BSD users make that decision themselves. Linux distros tend to make these third party applications part of their base system, this forcing risks on the user. The user may not even understand these items have risks that exceed Linux itself.
npm and pip have demonstrated the issues discussed here repeatedly...
