Earlier quoted context omitted.
This is an argument for returning to living in caves and hunting mammoths for fear that our modern civilization becomes unavailable for a day or two.
I'm down
Dating was so much simpler back then, too ..
Elevated error rate across multiple models
271–280 of 293 posts
Re: Elevated error rate across multiple models
#272Earlier quoted context omitted.
Your arguments do not make even a little sense. In what world does a user have to choose between 10 package managers? Each distro has exactly one. There are also only about three, maybe four main package managers out there. A shell script being piped into bash has so many more ways to break than a package. And if yhe theory is that package managers are fickle (they aren't), then how does adding more complexity help?…
It's crazy to me that even after seeing so many major software distributors choose `curl | sh` as their entry point, people like you will still argue to the ends of the earth that there’s no problem with the package manager ecosystem. I'll stop there. I'm not interested in continuing this discussion when it's being conducted in bad faith.
The fact that people do something doesn't make it good.
I am arguing in good faith about the merits of the approaches. I am engaging with the points of argument being brought up from the opposing side of the argument (see above). I am not veering off on side-tracks, unlike you, for example.
There' a simple good faith argument (that I have been making) which you can try responding to: Running arbitrary code from the internet without checking is bad. There is some effort needed to package software, but that is not that much effort in the grand scheme.
Re: Elevated error rate across multiple models
#273Earlier quoted context omitted.
It's crazy to me that even after seeing so many major software distributors choose `curl | sh` as their entry point, people like you will still argue to the ends of the earth that there’s no problem with the package manager ecosystem. I'll stop there. I'm not interested in continuing this discussion when it's being conducted in bad faith.
Bad faith, or perhaps just ignorance. It reminds me of purist junior engineers - and I have been one - refusing to understand or tradeoff in the world beyond their own. Rather than argue with those of us who are pointing out messy realities, this commenter might be better served filing a bug against any number of the projects that offer installation this way, asking them to remove it, and see if it lands any better.…
I would appreciate it if you would respond to me directly rather than suggest vaguely that I'm inexperienced and don't understand the realities of software distribution.
I would also appreciate it if you actually talk about something concrete rather than simply claiming to be right. You shouldn't pipe stuff from the internet into your shell.
Are you claiming that's about some highfallutin "technical purity"? Is it technical purity to check inside the bag when you buy a pig in a poke? No, that's common sense. It's common sense to have some degree of knowledge about what programs you execute on your computer. As root, at that.
Re: Elevated error rate across multiple models
#274Earlier quoted context omitted.
What about better ideas like installing from source, or using a package manager? Or even flatpaks.
The ideas aren't mutually exclusive, and I've never seen an open source project support "curl | sh" without also supporting those methods. Indeed, plenty of these scripts often act as a "what OS and packager do we have" mux. Just look at the source of this one, for example. When you support an open source project at scale and/or with less savvy users, you come to see the benefit of "here, just f'ing slam this into yo…
There are many ways of implementing a curl | sh installer, some of them robust, some of them not.
However they all look the same to the end user.
That's a feature and also a potential source of problems since users cannot tell if that particular application they want to install Is implementing the installer correctly or not. The outcome is that most users just trust that application (possibly because it's popular and trusted) and that's fine but it also trains the public that this installation method is ok and that gives a positive feedback for other applications to also offer their software using that installer pattern until at least one of such packages is implemented very badly or sneakily malicious.
If only a curl had a flag where you pass the sha256 of the file and it first checks it against the buffered file before outputting it to stdout.
That would singlehandedly resolve this whole kerfuffle.
The install instructions will be a slightly longer one liner and that's fine because people copy paste it anyway
Re: Elevated error rate across multiple models
#275status.claude.com looks like a holiday christmas ornaments
Strawberry garden
Re: Elevated error rate across multiple models
#276Re: Elevated error rate across multiple models
#277I have been developing software since the late 80s, mostly CAM software for metal cutting machines, and I have been refereeing tabletop roleplaying games like Dungeons & Dragons since the late 70s. I get the power of LLMs, and I do find them useful. But I find them useful in much the same way I find a really good set of random tables useful, or a good set of rules for procedurally generating something like a star sec…
> So far, I am failing to see how the inherent probabilistic nature of the technology can be fully overcome I deeply hope we never reach the point where that’s overcome. What we’ve seen over the past few years is how AI will destroy humanness from pretty much the entire digital realm. It’s by far the most evil, anti-human technology ever created, corrupting everything it touches. The last thing we need is for it to b…
And yet the world would seem to be (?) rushing to adopt it in its unreliable form anyway.
Perhaps it would be better if it actually worked.
Re: Elevated error rate across multiple models
#278I suppose it's a good time to encourage people trying out pi[1] with any cheap model from the openrouter rankings page[1]. [1] https://pi.dev/ [2] https://openrouter.ai/rankings
I retried Pi yesterday with GLM5.2 and Deepseek
I asked a simple question about my codebase. Pi: >60s and 100k tokens, I cancelled and gave up Claude (pointed at the same deepseek model): 17s 15k tokens
I burned my $5 GLM budget in 15 minutes.
So idk what the Pi hype is about cuz this is my 3rd disappointing try
Re: Elevated error rate across multiple models
#279Earlier quoted context omitted.
> Why would I? Because then you can install it without depending on a package manager?
Depending on a package manager has its benefits. I personally try and use my operating systems package manager for all applications (in this instance, dnf on Fedora). The moment you start adding a million repos, third party package managers, Flatpaks, Snaps, random curl install scripts, etc, it becomes extremely unmaintainable. What happens if the curl application depends on openssl, maybe with a legacy or specific c…
Sure. Agreed. I do it myself. But sometimes people don't do that. Sometimes people don't care about that at all.
And it's not just sometimes - it's most people.
So. They have their option too. And it's at the top, where most people can find it.
Re: Elevated error rate across multiple models
#280Earlier quoted context omitted.
Yes, if you want to, you can do that. Understand that 99% are comfortable trusting downloads. They know that it's just as easy to sneak backdoors into source code as it is to sneak backdoors into executables. See also: XZ hack.
99% of developers are most definitely not comfortable piping a script into the shell. I would never runa script without reviewing it. I would install a package from a distros repository without reviewing the contents, however, because I can trust that a distro maintainer has reviewed it, that anyone else in the community can review it, and that that the bytes I'm downloading are the specific bytes I'm supposed to be…
As someone who has spent years in the software industry in silicon valley -
My experience does not match yours.