HackerTrans
TopNewTrendsCommentsPastAskShowJobs

usrbinbash

4,633 karmajoined il y a 5 ans

comments

usrbinbash
·avant-hier·discuss
> 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?
usrbinbash
·il y a 23 jours·discuss
> 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.
usrbinbash
·il y a 2 mois·discuss
Why
usrbinbash
·il y a 3 mois·discuss
> 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
This, in a much more complex form, runs in my framework. The agent gets told that this tool exists. It gets told that it can do privileged work for it. It gets told how `context` needs to be shaped. (when I say "it gets told", I mean the tool describes itself to the agent, I don't have to write this manually ofc.)

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.
usrbinbash
·il y a 3 mois·discuss
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.
usrbinbash
·il y a 3 mois·discuss
> 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.
usrbinbash
·il y a 3 mois·discuss
> I don’t understand how people can remember all these custom scripting languages.

We can't.

Why do you think the `man` command exists?
usrbinbash
·il y a 4 mois·discuss
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
usrbinbash
·il y a 4 mois·discuss
> 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.
usrbinbash
·il y a 4 mois·discuss
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.
usrbinbash
·il y a 4 mois·discuss
> 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
usrbinbash
·il y a 4 mois·discuss
> 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.
usrbinbash
·il y a 4 mois·discuss
None of this counters the argument I made above :-)
usrbinbash
·il y a 4 mois·discuss
> 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.
usrbinbash
·il y a 4 mois·discuss
> 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/
usrbinbash
·il y a 4 mois·discuss
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.
usrbinbash
·il y a 5 mois·discuss
> 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.
usrbinbash
·il y a 5 mois·discuss
> 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 ;-)
usrbinbash
·il y a 5 mois·discuss
> 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.
usrbinbash
·il y a 5 mois·discuss
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.