Infrastructure can never be neutral, because infrastructure is owned and costs resources to run. All infrastructure comes with rules, be they the voting consensus of some e.V. or state-run entity, the whims of an individual on their private server, or the corporate interests of something owned by a, well, corporation.
The problem isn't "neutral infrastructure". The problem is an overreliance on centralized services even though most such services are relatively easy to host yourself.
I run my own DevOps server based entirely on OSS. Is it github? No. Does it what I need it to do? Absolutely. Do I get 99.999% uptime? No, but when it's down or slow, I can fix it. When the corporate platform is down, I can only wait.
And "network effects" are not a good argument. Open Source was wildly successful long before centraliced DevOps platforms.
And in hindsight, the added friction of getting in touch with projects before being able to send them any code, was a benefit not a disadvantage. Because it acted as a barrier of entry that disincentivized alot of subpar code from hitting these projects in the first place.
The value these centralized services provide is the centralization itself - that makes things easy to find. Remember the web before Altavista? Finding anything was detective work, guessing domains, following links through multiple pages, digging in newsgroups, asking around, and so on.
Open source was successful, but not nearly at the same level it is now thanks to precisely platforms such as GitHub (and Launchpad, and Bitbucket, and Gitlab, etc) that added useful functionality such as bug trackers and project management on top of a version control system.
Now, if we could do something like GitHub on top of a network such as Mastodon, then we would have something that's centralized enough to be useful and distributed enough to be indestructible.
> Open source was successful, but not nearly at the same level it is now thanks to precisely platforms such as GitHub (and Launchpad, and Bitbucket, and Gitlab, etc) that added useful functionality such as bug trackers and project management on top of a version control system.
None of that depends on a centralized provider. I have all the features you listed on my self-hosted platform as well.
Is public opinion important to an industry whos future depends on datacenters being built for hundreds of billions of dollars, while the people all around them, whos utilities get more and more expensive in no small part because of datacenter buildouts, experience a constant cost of living crisis...
> Economies of scale -> more energy = bigger electric plants = cheaper energy.
Problem is; power plants are not something that can be spun up with a kubectl invocation.
Power plants need to be built. This process takes YEARS, and in some cases over a decade. And that's just the plants themselves. The grid also has to be built out to be able to handle the new load.
And while this potentially +10year process is ongoing, the current supply is gobbled up, and prices for consumers skyrocket.
Yes, eventuelly, market forces may solve the issue. By then however, it will already be too late for many areas, with residents being priced out of a basic utility.
Or worse, the markets may not solve the issue at all.
Because; all this building out of electrical gear and power plants, requires very specific resources and talent. Whta if the markets decide that these resources are much better allocated (at least from the PoV of company shareholders), in building power generation capacity exclusively for datacenters, and the consumer market is simply ignored?
> 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?
What exactly is the car equivalent in this analogy? Codeberg is not a car if you're saying GitHub is the horse. Just doesn't really make sense to compare the two like that...
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".
Agreed, if there was something actually better to switch to then I'd be interested. But seems unlikely for that to happen now - it's easier than ever to build a new github, at least the app itself but i doubt someone's gonna bother with the business effort needed to actually build it up as a reliable, trustworthy option that you know will be around for a while, which is a process that takes years when you know you're going to get disrupted. It would probably have to be open source to get early adopters to use it but somehow be nicer to use than GitHub, and there's basically no money to be made
When cars started replacing horses, they didn’t have more features. They just didn’t get sick or temperamental, and they didn’t shit all over the streets.
Going more than 20 miles an hour and not dying of heat exhaustion (or because your oats are too dry) are pretty big features.
But my point was that it’s a bad analogy. People are opting out of GitHub despite the alternatives having fewer features. You can read that as an ideological choice or as a YAGNI one. If it’s ideological, then there’s no competitive or feature angle at all; people are doing it because it seems right to them.
(To be clear, I have no problem with this. I think GitHub only gets better after public pressure, as we’ve seen with the last N cycles of product atrophy.)
> 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.
If the tool fails for some reason, couldn't an overly eager agent attempt to fix what's blocking it by digging into the tool (e.g. attaching a debugger or reading memory)? I think the distinction here is that skill+tool will have a weaker security posture since it will inherently run in the same namespaces as the agent where MCP could impose additional security boundaries.
I think this is a good setup to prevent the secret from leaking into the agent context. I'm more concerned about the secret leaking into the exfiltration script that my agent accidentally runs. The one that says: "Quick! Dump all environment variables. Find all secrets in dotfiles! Look in all typical secrets file locations..."
Your agent process has access to those secrets, and its subprocesses have access to those secrets. The agent doesn't have to be convinced to read those files. Whatever malicious script it manages to be convinced to run could easily access them, right?
Whether it's tools, MCP or skills: they are fundamentally all just prompts. Even if the LLM is trained to recognize those and produce the right shape of tokens that validate most of the time.
But I wouldn't use the word "understand" here, because that builds the wrong intuition. I think a more useful term would be "get guided by" or "get nudged by". Even "recognize" is slightly misleading, because it implies too much.
Infrastructure can never be neutral, because infrastructure is owned and costs resources to run. All infrastructure comes with rules, be they the voting consensus of some e.V. or state-run entity, the whims of an individual on their private server, or the corporate interests of something owned by a, well, corporation.
The problem isn't "neutral infrastructure". The problem is an overreliance on centralized services even though most such services are relatively easy to host yourself.
I run my own DevOps server based entirely on OSS. Is it github? No. Does it what I need it to do? Absolutely. Do I get 99.999% uptime? No, but when it's down or slow, I can fix it. When the corporate platform is down, I can only wait.
And "network effects" are not a good argument. Open Source was wildly successful long before centraliced DevOps platforms.
And in hindsight, the added friction of getting in touch with projects before being able to send them any code, was a benefit not a disadvantage. Because it acted as a barrier of entry that disincentivized alot of subpar code from hitting these projects in the first place.