4,664 karma · joined December 4, 2021
And yet, almost every single time such practices are implemented, nothing about actual safety changes...but a whole lot about surveillance does.
"People willing to trade their freedom for temporary security will lose both.
-- Benajmin Franklin, paraphrased
There's a much simpler advice:
"Don't."
People SHOULD be allowed to put their entire lives on phones if they want to.
People SHOULD NOT have to worry about governments using that against them.
Gentle reminder that Saturn 5 worked pretty much eprfectly on its maiden flight.
They care about what boosts investor confidence.
So even if implementing a policy lowers operative income, if the growth in stock value offsets this, aka. number-go-up == true, the policy is implemented.
Technlogy? That would likely result in a US market crash the likes of which has never been seen before. Look at what percentage of the stock market is the magnificent 7. Now imagine what would happen to that if US tech giants were no longer allowed to sell their products/services in the EU. The market is fragile as it is with the AI bubble going on.
Trade? That cuts both ways, and the US economy and cost-of-living crisis doesn't give them lots of wriggle room.
Products? China will be all to happy to step into whatever market is thus competition-free, not to mention the impact this would have on US businesses.
Eased travel and trade, but not full membership voting rights, etc. So basically, an extensive trade and economics agreement, with options to intensify relationships later on.
Good thing for both sides!
And in recent years, how is the centralized world of websearch doing?
https://www.techspot.com/news/101560-study-confirms-search-r...
> 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.
Even if whoever owns and runs the infra would like that to be the case, the law of wherever they are can put restrictions on this as well.
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.
So why does that intelligence seem to have a hard time even showing its own usefulness?
...yeah, that's a tough one...
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?
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".
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?
It doesn't have to be good at permissions. That's what DevOps platforms that integrate git are for.
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.
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.
Wrong. It needs to "understand" both these things. The only difference is where and how the strings explaining them are generated.
We can't.
Why do you think the `man` command exists?
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.
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.
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.
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
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.
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.