usrbinbash

Funny, people used to say the same about Golang.

Turns out, sometimes shedding "functionality" is really shedding cruft that holds the core functionality back.

Is this the case for Codeberg vs. Github? I don't know, and I'm not gonna base my argument on unverfieable predictions of the future.

So we'll have to wait and see. But it sure looks to me like many of the prime arguments for github boil down to "well, it's big and has lots of stuff".

Proceeds to list but a handful of remotely meaningful repos

I'm pretty sure, shortly after the motorized vehicle was made commercialy available, there were only a "handful of remotely meaningful" people and companies who stopped using horses.

Do tell: How many horses are around on todays streets?

Something else that git isn't good at: permissions.

It doesn't have to be good at permissions. That's what DevOps platforms that integrate git are for.

Why

what stops the agent from echoing the secure storage?

The fact that it doesn't see it and cannot access it.

Here is how this works, highly simplified:

    def tool_for_privileged_stuff(context:comesfromagent):
        creds = _access_secret_storage(framework.config.storagelocation)
        response = do_privileged_stuff(context.whatagentneeds, creds)
        return response # the agent will get this, which is a string

The agent never accesses the secrets storage. The tool does. The tool then uses the secret to do whataever privileged work needs doing. The secret never leaves the tool, and is never communicated back to the agent. The agent also doesn't need, or indeed can give the tool a secret to use.

And the "privileged work" the tool CAN invoke, does not include talking to the secrets storage on behalf of the agent.

All the info, and indeed the ability to talk to the secrets storage, belongs to the framework the tool runs in. The agent cannot access it.

And in a skill, I can store the secret in the skill itself, or a secure storage the skill accesses, and the agent never gets to see the secret.

Sure, if I want my agents to use naked curl on the CLI, they need to know secrets. But that's not how I build my tools.

The core philosophy of MCP is simple: it’s an API abstraction. The LLM doesn’t need to understand the how; it just needs to know the what.

Wrong. It needs to "understand" both these things. The only difference is where and how the strings explaining them are generated.

I don’t understand how people can remember all these custom scripting languages.

We can't.

Why do you think the `man` command exists?

As the old saying goes: "This too will pass."

Consumer hardware will always be a market worth serving for companies who don't see their stock price as their product.

If the existing companies are unwilling to make a sale, I am sure new players will arise picking up their slack.

https://www.youtube.com/watch?v=SrX0jPAdSxU

iran's dickhead move...

Remind me again, which country started this whole mess?

what choice do the gulf nations, or even all the asian+european (strait users) nations have?

They can go "yeah, you know, the US has been less than reliable as an ally recently, what with absurd tariffs, saber rattling around greenland, belitteling NATO, etc., and they seem unwilling to change, so we're just gonna pay the piper, and get oil, and make arrangements with the Chinese (aka. the worlds most powerful industry), and if they US doesn't like it, that sounds like a them-problem..."

What's very likely not gonna happen, is other countries fighting the US's war for them. NATO already told trump no, other countries won't give different answers.

And anyone who wants to actually invade Iran...well, let's put it this way: Iran is 3-4 times the size of Afghanistan, with even more difficult terrain, and has a standing army of 600,000 men, with over 300,000 in reserve. They have an air force, are proficient in the manufacture of drones, have a working intelligence network. And they've had 4 decades to dig into defensive positions.

In short, it's not gonna happen.

Absolutely true, but there is a silver lining:

When people rewriting open source libs with a bot then come crying to maintainers that their rewrites have bugs, and they would like for someone to fix said bugs for free, there is absolutely no one who will feel obligated to help them out.

Just because they have been made before LLMs doesn't mean it can be done again

Erm...no? That's exactly what that means.

Earth-Ovens haven't been in widespread use for hundreds of years. People can still use them to bake bread however: https://www.youtube.com/watch?v=WAJqGVxuJPo

The submitter is supposed to be the good programmer;

And how will that be assured? Everyone can open a PR or submit a bug.

The problem is the time.

But not the time spent TYPING.

The problem is the time spent THINKING. And that's a task that LLMs, which are nothing other than statistical models trying to guess the next token, really aren't good at.

None of this counters the argument I made above :-)

Because it takes a massive amount of developer work

You know what else takes "a massive amount of developer work"?

"any LLM-generated code must be reviewed by a good programmer"

And this is the crux of the matter with using LLMs to generate code for everything but really simple greenfield projects: They don't really speed things up, because everything they produce HAS TO be verified by someone, and that someone HAS TO have the necessary skill to write such code themselves.

LLMs save time on the typing part of programming. Incidentially that part is the least time consuming.

Not sure how they can expect to make a viable full OS without massive use of LLMs, so this makes no sense.

Every single production OS, including the one you use right now, was made before LLMs even existed.

What makes sense if that of course any LLM-generated code must be reviewed by a good programmer

The time of good programmers, especially ones working for free in their spare time on OSS projects, is a limited resource.

The ability to generate slop using LLMs, is effectively unlimited.

This discrepancy can only be resolved in one way: https://itsfoss.com/news/curl-ai-slop/

The sad part is, how infinitely more functional these simple, static HTML documents are, compared to much of the shit that floods the "modern" web.

Ofc these pages cannot replace SPAs. That's not the point. The point is: Much of the web isn't SPAs. And much of what is SPAs shouldn't be SPAs. Much of the web is displaying static, or semi-static information. Hell, much of the web is still text.

But somehow, the world accepted that displaying 4KB of text somehow has to require transmitting 32MiB of data, much of it arbitrary code that has no earthly business eating my CPU cycles, as the new normal. Somehow everyone accepts that text-only informational pages need to abuse the scroll-event, or display giant hero-banners. Somehow, having a chatbot-popup on a restaurants menu-page is a must (because ofc I wanna talk to some fuckin LLM wrapper about the fries they sell!!!), but a goddamn page denoting the places address and telephone number is nowhere to be found.

https://idlewords.com/talks/website_obesity.htm

This talk was given over a decade ago, and its takeaways are as relevant today as thy were back then, and in fact maybe even more so.

That's great, but it's always just one agency, or one very local bit of government.

Transitioning every system wholesale at once, is not gonna happen.

I rather have our governents and agencies do it step by step than not at all.

It's one thing for the file you're working on to be vulnerable if you walk away leaving the editor open

Considering that walking away from an open editor means also walking away from an unlocked machine, the problem would be the exact same ;-)

If you walk away from an unlocked machine

...then I might as well ask what happens when I walk away from the encrypting edior while a file is still open. User Error can happen with any encryption or security schema. Pointing out a trueism is not an argument.

It's also portable

So is encrypting files using a specialized tool. I don't need my editor to do this. The entire point of my criticism, and indeed the entire point of this thread, is that software that should focus on a narrow task, tries to do way too much, leading to problems.

Why does my text-editor need to do "encryption at rest"? If I want data encrypted, I store it in an encrypted drive with a transparent en/decryption layer.

As funny as the "Bush hid the facts" bug may be, there is a world of difference between an embarassing mistake by a function that guesses the text encoding wrong, and a goddamn remote code execution with an 8.8 score

and we have other battles we fight.

Except no, we don't. notepad.exe was DONE SOFTWARE. It was feature complete. It didn't have to change. This is not a battle that needed fighting, this was hitting a brick wall with ones fist for no good reason, and then complaining about the resulting pain.

Absolutely false. I have built tons of tools which are feature complete and continue to work to this day without intervention

And how many of these tools are mission critical to the point that they are installed on almost every Linux box in existence, probably invoked tens of billions of times per day, both by humans and software, and the entire world would be in deep goddamn trouble if there was a serious security flaw that doesn't get fixed immediately?

Because that's what `sudo` is.

And no, such software is never "done".

For me it's nachos, homemade cheese-and-cream-and-onion-and-garlic dip, and some fine wine.

Spending 4 years evaluating something that’s changing every month means almost nothing, sorry.

No need to be sorry. Because, if we accept that premise, you just countered your own argument.

If me evaluating these things for the past 4 years "means almost nothing" because they are changing sooo rapidly...then by the same logic, any experience with them also "means almost nothing". If the timeframe to get any experience with these models befor said experience becomes irelevant is as short as 90 days, then there is barely any difference between someone with experience and someone just starting out.

Meaning, under that premise, as long as I know how to code, I can evaluate these models, no matter how little I use them.

Luckily for me though, that's not the case anyway because...

It’s about “if you last tried it more than 3 months ago,

...guessss what: I try these almost every week. It's part of my job to do so.

but to catch any low hanging fruit before you spend your valuable time reviewing.

And that would be great, if it wern't for the fact that I also have to review the reviewers review. So even for the "low hanging fruit", I need to double-check everything it does.

Which kinda eliminates the time savings.

I mean, git is just as "local-first" (a git repo is just a directory after all), and the standard git-toolchain includes a server, so...

But yeah, fossil is interesting, and it's a crying shame its not more well known, for the exact reasons you point out.

It sounds to me like you may not have used a lot of these tools yet

And this is more and more becoming the default answer I get whenever I point out obvious flaws of LLM coding tools.

Did it occur to you that I know these flaws precisely because I work a lot with, and evaluate the performance of, LLM based coding tools? Also, we're almost 4y into the alleged "AI Boom" now. It's pretty safe to assume that almost everyone in a development capacity has spent at least some effort evaluating how these tools do. At this point, stating "you're using it wrong" is like assuming that people in 2010 didn't know which way to hold a smartphone.

Sorry no sorry, but when every criticism towards a tool elecits the response that people are not using it well, then maybe, just maybe, the flaw is not with all those people, but with the tool itself.

My answer to this is to often get the LLMs to do multiple rounds of code review

So I am supposed to trust the machine, that I know I cannot trust to write the initial code correctly, to somehow do the review correctly? Possibly multiple times? Without making NEW mistakes in the review process?

Sorry no sorry, but that sounds like trying to clean a dirty floor by rubbing more dirt over it.

What changed is the volume, clearly.

The change in volume was the tipping point between bug bounties being offered and devs being able to handle bad reports, and bug bounty nixed because devs no longer willing to handle the floos.

And the root cause for the change in volume is generative AI.

So yes, this is causally related.

The problem doesn't change because of who is causing it in this case.

Wrong.

Because SCALE MATTERS. Scale is the difference between a few pebbles causing a minor inconvenience, and a landslide destroying a house.

So whatever makes the pebbles become a landslide, changed the problem. Completely.