Elon is a moron and microsoft CEO just says that because that's his hope, because that's only way they don't lose their market share.

AI can replace lawyers

but purely because lawyers lowered their standards to just "paste whatever AI hallucinated and send it to court"

all of them have significant SaaS offering.

But the claim that's related to anthropic posting some markdown files is idiotic at best, malicious at worst

> Reminds me of this question - why did the USSR collapse? You can describe dozens of influences which acted all at the same time, but there isn't a one paragraph summary answer.

Decisions made in greed caught up with people in power

What % of it is vibe-coded in copilot ?

I read this type of (sour) comment more and more on this forum. To me it reads very cynical and I wonder what the author is trying to say with this. Are you perhaps negatively impacted by automatic coding?

Do you want to enable Copilot ?

    | Yes |    | Remind me later |

we are ALL negatively impacted by generative excrement

I have to use Windows at my day job

and my god, I'd prefer Windows 3.1

Nope, not at all.

I read your comment as ignorant to AI's capabilities and their negative outcomes with relying on vibe coding.

The implication is that MS is forcing AI adoption on users at a point of absurd recklessness, and that they should not be trusted - especially not blindly trusted.

Perhaps the reason you're seeing comments similar to my original comment more frequently is because actual software engineers whom know the capabilities of AI and how much of a bad decision it is to assume it's as good as a competent engineer. Many engineers have had years of experience working with management, whom while have legit concerns about the capabilities of software as they are ultimately responsible for it and the financials, see them turning to vibe coding and relying on it. Non technical folks think software is kinda easy to do, and because LLMs can generate code that it just proves their assumptions.

also you're getting at least some of crowd safety in it. If you're using Debian Testing or a rolling distro your package was probably tested by a bunch of people already.

If you're using stable/LTS branch, there were far more eyes on it too

And packages are signed, can't just hijack web domain to inject code

> It's about as safe as trusting all the add-ons in your IDE, and all the packages your node app pulls from random package repos.

Absolutely incorrect. You can do far easier due dilligence for IDE plugins

Can you elaborate? How do you like to evaluate your IDE plugins?

If you're copying curl|sh from webpages you're already not paying attention and domain doesn't matter

It is literally the method given to install a number of products. The first mechanism given as a fix, of sorts, is to install something via brew.

Brew is installed by copying a command line-

https://brew.sh

I mean, I guess you could retype it, but there is no intention for anyone to do that.

I think Homebrew still makes a mess with permissions on multiuser systems (at least on macOS), so it's probably not a good example of best practices.

I'm not holding it as a best practice, and I don't see how that was interpreted from my comment. I think installation through a copy/pasted script is terrible business.

But it was held as something exceptional, when here in reality a number of extremely widely used products, frameworks and tools provide installation through a curled shell script command.

Another example is CUDA on Linux. Installed via some copy/pasted scripts from a webpage.

I have must misunderstood or misinterpreted your comment a bit then.

I fully agree, this seems to be becoming more and more common unfortunately.

While true, then I'd just skip installing these products and find another way. And if this is the only way and the product is important (say, brew), make an exception.

biggest flaw of jenkins is that by default it runs on builder env, as it was made pre-container era. But I do like integration with viewing tests and benchmarks directly in the project, stuff that most CI/CD systems lack

it's 2026. People still build fucking makefile generators

Because, in 2026, most build tools still aren't really all that good when it comes to integrating all the steps needed to build applications with non-trivial build requirements.

And, many of them lack some of the basic features that 'make' has had for half a century.