To do things that a human could have done in theory, but did not do because it would have been too expensive.

> It seems like one needs a big machine farm and a vast corpus of training data with a lot of manual curation to get started creating a competitive LLM, plus whatever technical expertise that I don't even know about. The stuff that makes LLMs exist now and not earlier.

"big machine farm" reminds me of folding@home, which needed the same and got it.

"manual curation" is what Wikipedia did, as well as the free software community.

"technical expertise" is present in the free software world too. It is sparse since it is sparse in the world as a whole, but it exists.

"no Linus Torvalds figure" might be the main problem ATM.

I also thought of these after writing my comment. The main problems that I see with these solutions are:

- Training seems to need a lot of data available at the same time, which is difficult to handle on commodity hardware.

- Manual curation can be a mind-numbing task, it might need to be gamified somehow.

There is a chance that the curation could be higher quality than the current corporate stuff. Pretty sure that it's not an intrinsic property of LLMs to write like TED talks.

Bonus points for the kafkaesque responses you get as the end-user when you try to actually pass that information upstream where it could be fixed...

It seems hard to believe that a one-hour delay on such a counter is impossible to achieve, and one hour would reduce the risk from "catastrophic" to "serious problem" in most cases.

Also, if implementing a cap is a desired feature that justifies trade-offs to be made, then it is psosible to translate the budget cap (in terms of money) back into service-specific caps that are easier to keep consistent. Such as "autoscale this set of VMs" and "my budget cap is $1000/hour", with the VM type being priced at $10/hour, translated to "autoscale to at most 100 instances". That would need dev work (i.e. this feature being considered important) and would not respect the budget cap in a cross-service way automatically, but still it is another piece in the puzzle.

Eh, suddenly turning off all services in your account because you hit your cap is just as much a DoS type event - just of your services, not your wallet.

So? Many would prefer a DoS-type event over spending $WHATEVER_THEIR_HARD_CAP_IS. This is kinda the definition of a hard cap, so you would place it sufficiently high that DoSing your system is indeed preferable.

Also, doing this on a per-service basis doesn't seem that far-fetched to me, so you'd only kill that service and get at least some chance that the rest of your system remains usable.

It’s the trade offs.

If you have an actual enforced cap, those services will be disabled until you resolve the cap - which depending on the latency for usage updates, may be hours after you pass the cap, and hours after you resolve the issue.

Or you have ‘warnings’, and your services keep working, but you spend more $$.

Previously, people seemed to be more worried about service outages than raw $$. Now it’s the other way around.

It’s a common issue with disk quotas in on-prem systems too, and they tend to cause a lot of similar types of problems in both directions.

> If you made a local-first, P2P version of Figma what would break first?

The guy who has to keep it running day by day, next to the other 30 local-first systems.

What is there to run? There are millions of apps that don’t require maintenance, this was the default before SaaS.

Every app need maintenance if it's connected to the internet. Security updates at minimum.

> The deeply unexpected thing about that, to me, is, if they hate some parts of the process, why are they keeping them?

Why are you assuming that they are given a choice? In my experience, whenever a team is trying "agile" in some way but hate it AND are given the choice, they drop it ASAP and are 100% convinced that they are better off without it. Those that hate it and don't stop doing it, are doing so because they are forced to.

> Why are you assuming that they are given a choice?

Because self-determination was the defining component of every agile deployment I've ever been involved in or personally driven. I don't think I can really picture what something calling itself agile yet lacking this component would even look like, honestly -- hoping you will forgive me this failure of imagination.

> whenever a team is trying "agile" in some way but hate it AND are given the choice, they drop it ASAP

Isnt that in itself "agile"? And I specifically dont mean following a religous ceremony plan etc but recognizing that a part of their process isnt working and then changing it. To me thats the entire point of actual agile. You try a process, it doesnt work, you analyze, and adapt.

I think there is: It is the line between "not spending extra money to make sure it works" and "spending extra money to make sure it won't work".

There is a related problem with warranty: an inferior third-party replacement part may cause damage to higher-quality original parts. There is a line here between "making sure you don't have to deal with follow-up damage caused by inferior parts" and "preventing the use of inferior parts". This is a bit more blurry because most cases won't be clear-cut, and dealing with them will be a burden on the original manufacturer.

I think it is important that we reward the nice players as much as we punish the bad ones. A blanket "all companies bad" just means that no company has an incentive to be anything less than bad.

This may sound absurd, but it was a mental breakthrough for me to realize that all these "what-ifs" (multicore 6502 computers or whatever) are really simple to simulate in software only, with a bespoke simulator, WAY above register transfer level. There is really no need to deal with the peculiarities of FPGAs or Verilog; just write an instruction-level simulator for the ISA you choose (that's really simple for the 6502), make it run several instances for multicore architectures, and there you go for your custom computer.

I mean this as a hint for people who are similarly stuck with RTL tinkering when they actually want to tinker with system architecture.

By that logic, operating system developers struggle to understand that putting two files with the same name into the same folder(1) is very much possible in the physical world.

(1) or referencing them from the same directory, which was the earlier metaphor.

I've seen two people with the same name and birthday, in different departments of the same building. Caused regular problems with management and HR.

I've also seen two different customers with the same name and phone number - the number got recycled and went to second one while the first hadn't updated their number on file. We had to tell them apart by address.

But why are filenames equated with spacetime coordinates? That doesn't make any sense - reflect on why you leaped to that analogy. The spacetime coordinates are the disk ID and sector number. We've been using operating systems that work a certain way for so long that we think filenames are like spacetime coordinates.

The analogy is location. file : directory :: person : geocoordinates. I thought it was a straight-forward analogy, but clearly I was mistaken.

Questioning standard nomenclature is useful too, as long as it provides insight and is not just bike-shedding. "optimization" (in the context of an optimizing compiler) is generally expected not to alter the semantics of a program.