But you’re seeing a screenshot of an unmatched order that no driver has claimed yet. I’m saying that unless an actual match is accepted, that’s not really evidence that people in a place don’t tip well, just that some people don’t get their orders filled.

If you never give less than $5, then any order you’re involved in will involve at least a $5 tip. That may not be representative of the orders you’re not involved with.

I think the user decides how much to tip in advance, and the app conveys that information to potential matches. Orders with low tips tend to sit there unclaimed, because no driver wants to bother with that

I’m not sure if Uber does it that way, but Doordash does.

I remember reading about a case a few years ago where a warehouse couldn’t figure out which of its workers was just periodically taking shits in random corners of the warehouse. I think I’m starting to understand a different angle to that story, though.

It’s gonna be so fucking funny when the push to sell silicon that can run local models at 100 watts or less ends up destroying the business models of the companies that built out 100,000,000,000 watts of data centers.

Yeah, but that’s always been true of paid software licenses for a particular version: it reaches EOL and you have to decide whether to live with the possibility of unpatched known vulnerabilities or pay for an upgrade to a more recent release.

MS Office has been doing this from back in the Windows 3.0 days at least.

The only solution is to make sure they can’t read data you don’t want shared.

Isn’t that the appropriate guardrail, then? LLM chats and agents and whatever need to be contained with external permissions settings that the LLMs simply do not and can never have the power to override.

In a normal customer service setting with human agents, there are still plenty of examples of what a human agent simply doesn’t have the power to do. Often, they’ll need to escalate to a manager to do things like process refunds not just because they weren’t given social permission to do so, but because they weren’t given technical permissions to do so. LLM agents need to be contained in the same way. Any decent use of agents, human or software, requires carefully designed processes and permissions extrinsic to that agent’s own decisionmaking abilities to make sure that agents don’t do something bad for the company.

Edit 2: Nevermind. 13th October is the day Microslop has chosen to fuck me: https://support.microsoft.com/en-us/office/system-requirements/end-of-support-for-office-2021

You’ll still get a few years before the software becomes remotely disabled, though. This story about Office 2019 losing functionality follows Office 2019 losing support in 2023. If that’s the rate things go, then maybe Office 2021 will lose functionality either 2 years from now (7 years after release) or 3 years from now (3 years after losing support).

jizz oil all over it to make it waterproof

Yeah, it’s counterintuitive because it’s a lot more work for a human to draw a picture (much less a photorealistic picture) than to write a few words, but human language grammar actually has a lot of strict rules that makes that stream of letters work as “valid” output, much less “decent” output that kinda matches the prompt/description. Transpose a pair of letters or even substitute a single letter (or token) and you’ve got an output that just doesn’t work, in a way that generated images don’t have to worry about.

Yeah, the smarter way to use LLM-based agents is carefully defined tasks. Mozilla describes their vulnerability assessment processes in this blog post.

Mozilla describes the process they’ve used: building a harness that instructs a model to find a specific category of vulnerability on a specific interface, and then write up its findings. It’s a narrow enough context that the model gets specific instructions, and a simple definition of success, and it sets up many such tasks that can be fed into the existing process for verifying and triaging bugs. Note that the output for this LLM pipeline basically feeds into the same interface for accepting bug reports from the public, or from their human contributors within the project.

There’s a couple of takeaways here, too:

• This pipeline is model agnostic. Mozilla set it up before Mythos was released, and its description of other models (Opus 4.7, Codex) confirms that Mythos is better but not a true game changer. The ability to swap out other models provides some assurance that the work done to develop the pipeline will be useful when cheaper or better models come along, or when a model becomes unavailable (like when a provider decides a particular model is too expensive to run, or a provider goes under).
• The increase in automated output (and presumably automation-assisted contributions from the public) has given the humans more work to do. Automation in this context actually increases the demand for human labor.
• Other projects will need to develop their own custom pipelines, specific to their project, to get good results from LLM based agents.

There are ways to use these tools, but none of it really seems like a truly revolutionary/disruptive change to how large projects are managed.

I think AI will be profitable for the next generation of AI business models that emerge from the abandonment of the current business model of developing the frontier. But the prerequisite is that the companies give up on developing the frontier and decide that the models they have are good enough, then get hardware optimized for inference on those models, stagnating into long term commodity infrastructure, like providing phone service or electricity for profit.

So yeah, I think many of these technologies are here to stay, but the growth will stagnate this year as data center construction swallows up companies that overextended.

It’s a Nielsen box that can detect your streaming app activity, too.

And, as I understand it, Anthropic hasn’t committed as much spending to building out new data centers, and has setup their operations to be GPU agnostic, so they can keep flexibility between NVIDIA GPUs, Google TPUs, and Amazon Trainium, and play the data center pricing game. Anthropic is better positioned to survive an AI winter (and I believe it’s coming soon).

Not with AI in particular, but yes with subscription based software generally.

The economics of it don’t add up and the growth rate of the curve of improvement over time has already significativelly fallen which looking at the historical curves for other technologies is a very strong indication that it’s approaching the limits of how far it will go even though it’s nowhere close to the hype.

Yeah, I’m convinced that they’ve maintained the illusion of continued exponential improvement from 2024-2026 by sneaking in exponential increase in resources (hardware complexity, power consumption), to prop things up past what should have been a plateau.

AI has an interesting economic trait in that it’s very, very expensive to deploy, and made very fast progress from 2022 to 2024. That caused investors with money to believe that:

• Pushing the frontier was going to cost a lot of money. More than any other purported revolutionary tech.
• Extrapolation of past improvement meant that whoever was on the cutting edge may end up with a product with a huge paying market.
• So whoever wins this race would be rich, and the investment would have been worth it for them.

But since 2024, we’ve seen that the cutting edge got even more expensive much faster than expected, and much of the improvements in performance now come from inference rather than training, which represents a high ongoing cost.

Now, if we extrapolate from that trend line, we’ll see that the market will be much smaller for AI services at the cost it takes to provide that service, and the question then becomes whether the industry can make its operations cheaper, fast enough to profitably provide a service people will pay for.

I have my doubts they’ll succeed, and we might just be looking at the industry like supersonic flight: conceptually interesting, technically feasible, but just a commercial dead end because it’s too expensive.

ActivityPub is the fediverse protocol, lemmy and piefed are software implementations of that protocol.

In a similar way, email is a protocol, and Gmail and Exchange/Outlook are software implementations of that protocol. You can use Gmail to send email to Outlook users. Different people can administer their own Exchange servers on their own domains.

And some features of the software work best with other people who use the same version of the same software, although most things kinda work between different software. Like how calendar invites sometimes act weird between users of different software, but for the most part the core functions work OK.

So lemmy and piefed (and mbin and sublinks and some others) are different software trying to speak to other fediverse services through the ActivityPub protocol. It mostly works, but some of the details don’t work exactly the same between each type of software.

One real concern I have is that there are now automated tools that can read a patch, and the maintainer’s release notes with a description of a security vulnerability fixed by that patch, and then create a working exploit of the pre-patch vulnerability.

In that particular moment, you know that a vulnerability exists and that it was serious enough to be described in release notes, and you can compare two code versions, one that is secure and one that is not. From there, any AI coding agent is working towards something that definitely exists, with a bunch of description of what it might be.

So that means that the window between when a patch is released and when users actually apply that patch is going to be more important than ever. Downstream maintainers will be under a lot of time pressure to implement changes from upstream, because every new security patch will create a race to create 1-day exploits for everyone using that software.

Don’t they put plutonium reactors in space?

The ones that power spacecraft generate less than 5000W of heat at max power (while producing 300W of usable electricity).

In order to power a single server rack of 72 Blackwell GPUs, which takes about 130,000 watts, you’d need about 430 of those RTGs, and need to manage cooling requirements of 430 times as much (plus however much additional power will be required by the cooling system itself, too).

Companies are building entire workflows around AI, but they are building them under the assumption that they won’t ever be charged per token.

Or worse, where the AI models underpinning a workflow breaks or degrades in some way to reduce token usage and then starts behaving in unexpected ways, in a process/workflow that assumes a particular type of behavior.