grogers

Maybe instead of spending money on AI to squeeze as much profit as possible you could just fix your self ordering kiosks to not suck? They are painfully slow to the point where you have to click things multiple times because it doesn't register and then when it does wake up it registers the second click on some unrelated thing that you have to undo. Plus half the time the card reader doesn't work so you have to pay at the counter anyways, which they don't staff so it takes forever to flag someone down.

I would go further than this and argue that most bugs during database migrations happen because of mismatched application behavior with the action of the migration, not because the DDL was wrong. E.g. removing something that was still being relied on by the application, or starting to backfill data to a new column before the application is fully writing it. The most insidious version of this is where one application server doesn't have it's code updated (or comes back from the dead, etc) and causes the problem.

At a previous job what I did to prevent that was to have a special DB table that would signal what capabilities the database has, and the code would read that table and compare to its own requirements. If a capability required by the database was not present in the code (e.g. code not updated for a new feature) the code would refuse to make any writes to the DB and error all incoming requests. Likewise if a capability required by the code was missing from the database (e.g. code deployed too soon and database migration not run yet) it again would refuse requests. Before setting a feature to required in the DB and preforming the migration with feature flags, we could check all known application servers were reporting compatibility with the new feature (if any were down or not reporting at the time, they will be blocked in the next step - prioritizing safety over liveness)

Is editing really any less 'thinking' than writing the original copy? I don't use LLMs to generate prose but I can compare to writing code. Let's say I use an LLM to write code to some specification. After it meets the spec I go over everything with a fine-toothed comb - tweaking things to a style I like better, rewriting pieces or interfaces that I think would be better a different way, etc. Is the final work product any different than if I wrote it from scratch without absolutely any LLM use? Personally I would say no, if I do enough editing to be perfectly satisfied with it then it's the exact same output in the end.

I was always confused about why charities did this type of matching gifts, it always seemed a bit odd just to trick people to giving right now and not whenever. Interesting that there's a structural reason for it, TIL, thank you

The budget is just another constraint that helps define the perfect solution. Sometimes quick and dirty is the perfect solution.

My read is that xAI built a lot of compute for their own use, but they didn't get any adoption so they are reselling the unused capacity to recoup at least some of the costs. So calling it a good bet is kind of misleading

It may not be slow, but this crazy complexity is probably a hint at why it can't even scroll up without jumping to the beginning of time.

Today is my last day at my current employer. After some time off, I'm considering several different options. I have enough saved that retirement is probably doable, although last time I took extended time off I got bored much quicker than I expected. I'm also considering retraining for a different field but that seems kinda daunting, and no certain bet either. I was thinking of doing some open source contributions to test the waters on whether I really want to give up software dev or not. I might do part time work just for something to do and for decent health care. Luckily working in tech has been very lucrative, so there are plenty of options on the table.

Have you tried dafny, which seems roughly comparable for your purposes? I heard some buzz about it a little while ago but I haven't been following this space closely.

If you are ten nested functions deep in sync code and want to call an async function you could always choose to block the thread to do it, which stops the async color from propagating up the stack. That's kind of a terrible way to do it, but it's sort of the analog of ignoring errors when that innermost function becomes fallible.

So I don't buy that async colors are fundamentally different.

It's interesting that you mention Facebook. They have a ton of their own data centers and yet they are now also spending tens of billions on cloud. It's not that easy to build hundreds of data centers on short notice.

They all smear the purchases and sales from index changes, but I don't think they publish on what timescale. Most funds try to minimize tracking error. There are funds that take this to a different level. When a stock is added to the big indexes, it tends to do poorly over the next year, and on the flip side when a stock is removed it tends to perform well. Dimensional funds have automatic rules to take advantage of this type of thing. There are other companies that have funds of this style, but overall they are much less widely used than the big index funds from vanguard, blackrock, state street, etc.

Well they also shadowed production traffic and fixed some bugs that were causing mismatching results. Not saying that stuff can't still slip through, but it's a good way to evaluate it against real data in a way you can't from just test cases alone

In this incarnation, the only one who "wants" red to win is the first column. Every other column will choose whatever color it wants to win, subject to the rules of the game.

It's a 2 step process:

1. Prepare - Collect a majority of rows such that each of them promises not to accept any color sent by columns to the left of the proposing column. Any colors which were already accepted are sent in reply, along with the column they were accepted in (if different colors were accepted, only the rightmost column for a given row matters). The color to be propagated by the proposer is that with the rightmost column number (or if none were accepted by that particular majority, anything may be selected)

2. Accept - for every row, set the color to the one chosen in step one for the proposing column, subject to the promises made in step 1.

In this case, it's not shown well in the diagram, but by having a majority of rows promise for column 2, column 1 would already have a broken majority. Even if column 4 wanted red, since it received some already accepted colors, it has to choose from one of them based on the rightmost column (blue in this case)

The final diagram is a bit confusing, so it's worth pointing out one additional thing. It appears that R5 could vote green in column 2 and have green be agreed by a majority, even though in column 4, we are committing to blue as the value. However, as part of allowing blue to be selected in column 3, R5 must have already promised NOT to accept green in column 2. A more complete final diagram would show X's in all the appropriate cells.