Dangerous dependencies in third-party software – the underestimated risk | Hacker News Reader

Dangerous dependencies in third-party software – the underestimated risk

linux-howto.org

12 pointsChristian_A12 comments

Does anyone else find this article's writing style to have some hints of AI?

Well, the image at the top absolutely is, and the article is written in that AI-favourite list with title headers format. It's also far too wordy.

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.

I didn't make it that far into the article before giving up, due to the immense verboseness, but the \n's are a definite giveaway; and right before the first one is also a common "AI-catchphrase": "Let's explore some of these options in greater detail."

> Based on the style, structure, and overall tone, I'd estimate there's roughly a 70–80% likelihood that this article was generated by an AI.

> 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

>Does anyone else find this article's writing style to have some hints of AI?

"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.

LLMs can make a lot of mistakes. If you get the impression that an LLM was used, it brings much more into question any detail provided in an article. If they did use one and didn't specifically state which one they used, that leaves open a wide range of error/hallucination rates across a spectrum of LLM performance.

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.

Thanks. That's exactly the unease my mind was experiencing as I tried to read it, but I couldn't quite put it into words why it felt more laborious to read than usual. It's like SEO spam, but sneakier. It's extremely verbose and rambling, but has a distinctly unhuman style.

No. Scrollbars are besides the content, AI-generated content is the content. An article absolutely deserves to be called out if the author has the gall to AI-generate it and then share it on HN (or elsewhere).

I immediately got that feeling and closed the tab.

This is something that weighs on my mind a lot. Industry norm is to use 3rd party dependencies, and it's impractical to carefully vet direct dependencies let alone transitive dependencies. The article spits out a big list of reasons to worry about this, but in the end, the possible solutions aren't all that great.

I have no answers: just questions that haunt me, from time to time.

First:

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.

Wow! and the author isn't even a boomer. Amazing.

npm and pip have demonstrated the issues discussed here repeatedly...

Reply on news.ycombinator.com