Wrong way round. Should be "Is Your Agent Reality-Ready?"
(Hint: no)
HN user
Wrong way round. Should be "Is Your Agent Reality-Ready?"
(Hint: no)
Just be aware of the risks! https://security.stackexchange.com/questions/38128/what-are-...
It's interesting that the focus is just on open source licenses. If one can strip licenses from source code using LLMs, then surely a Microsoft employee could do the same with the Windows source code!
The core issue is that hackers can steal the "identity" of internet customers at scale
That's on one end, right? There's also the other end: as a user connecting to the network, currently one is subscribing to receiving packets from literally everyone else on the internet.
It's a fundamental issue with trust and distributed systems
We currently trust entities within the network to route packets as they are asked. The network can tolerate some level of bad actors within that, but there is still trust in the existing system. What if the things we trusted the network to do were to change slightly?
Works for static content and databases, but I don't think it works for applications where there is by necessity only one destination that can't be replicated (e.g. a door lock).
Maybe that's the case, but it seems like this conclusion is based on the current architecture of the internet. Maybe there are ways of changing it that mean these issues are not a thing!
What would the Internet's architecture have to look like for DDOS'ing to be a thing of the past, and therefore Cloudflare to not be needed?
I know there are solutions like IPFS out there for doing distributed/decentralised static content distribution, but that seems like only part of the problem. There are obviously more types of operation that occur via the network -- e.g. transactions with single remote pieces of equipment etc, which by their nature cannot be decentralised.
Anyone know of research out there into changing the way that packet-routing/switching works so that 'DDOS' just isn't a thing? Of course I appreciate there are a lot of things to get right in that!
Yep, after spending a few years with gitlab pipelines, my company started migrating over to dagger roughly mid-2024.
We moved to dagger to get replicable local pipeline runs, escape the gitlab DSL, and get the enormous benefits of caching.
We have explicitly chosen to avoid using the "daggerverse", and with that the cross-language stuff. Reason being that it makes modifying our pipeline slower and harder -- the opposite of the reason we moved to dagger.
So we use the Dagger python API to define and run our CI builds. It's great!
Like the other comments on this page about dagger, the move to "integrate AI" is highly concerning. I am hopeful that they won't continue down this path, but clearly the AI hype bubble is strong and at least some of the dagger team are inside it.
I'm speculating that if the dagger team doesn't drop the AI stuff, then the dagger project will end. A fork will pop-up and we'll move to using that. Not an expert (yet!) in the buildkit API, but it seems like the stuff we're benefiting from with dagger is really just a thin wrapper around buildkit. So potentially not too challenging to create a drop-in replacement if necessary later.