taberiand

There is no reason you couldn't design the system to hand off to a simple protocol through an MCP call, it's entirely up to what works in the specific situation. There is nothing in the design that mandates a path through the LLM for every request or transaction.

Final end state where it eats itself? Who buys all that soup when the workers have no jobs and no money? How much soup can one human CEO drink? (And why isn't the CEO also replaced by the AI?)

This is like telling a depressed person to just be happy

My understanding is a huge issue with blood donation is expiry, and therefore the need for consistent year-round donation - when a disaster occurs there's often a spike in donations but the surplus gets thrown away. A mechanism that can make use of expired blood that works for all blood types and extends the shelf life seems extremely valuable.

Would this be solved by providing the client with a (frequently rotated) public key to encrypt the password field specifically before submitting to the server, so that the only place it can be decrypted and stored is the authentication service at the very end of its journey through the network?

Ok, so what tools are less work to create a reproducible build than using docker carefully?

Presumably if your goal is a reproducible build you just wouldn't do any unconstrained downloading in the process of designing the dockerfile and building the image. Making a choice to use a tool poorly for you requirements isn't a problem with the tool.

Well sure, making a 100% reproducible build is hard - but Docker makes it easier, not harder. If 100% reproducible is the goal, what's easier than docker?

My guess is any civilisation advanced enough to populate their galaxy knows that it's inherently pointless. Unchecked growth is the impetus of lesser lifeforms

I don't think there's much trouble at all fixing the toy example by extending the message type to allow communication of the additional conditions, and I think my changes are better than the alternative of using a mutex. Have I overlooked something?

Assuming the number of players are set up front, and players can only play or leave, not join. If the expectation is that players can come and go freely and the game ends some time after all players have left, I believe this pattern can still be used with minor adjustment

(please overlook the pseudo code adjustments, I'm writing on my phone - I believe this translates reasonably into compilable Go code):

  type Message struct {
    exit bool
    score    int
    reply chan bool
  }

  type Game struct {
    bestScore int
    players int // > 0
    messages    chan Message
  }

  func (g *Game) run() {
    for message := range g.messages {
      if message.exit {
        g.players = g.players - 1;

        if g.players == 0 {
          return
        }
        continue
      }
  
      if g.bestScore < 100 && g.bestScore < message.score {
        g.bestScore = message.score
      }

      acceptingScores := g.bestScore < 100

      message.reply <- acceptingScores
    }
  }

  func (g *Game) HandlePlayer(p Player) error {
    for {
      score, err := p.NextScore()
      if err != nil {
        g.messages <- { exit: true
      }
      return err
    }
    g.messages <- { score, reply }
    if not <- reply {
       g.messages <- { exit: true }
       return nil
      }
    }
  }

And all throughout this engineering is saying "this is stupid, the app shouldn't know or care about those systems directly, it should offload the messages to some other service to handle" and yet management says "no time for silly things like basic software engineering, we need to move fast [and break things]"

Is there an MCP for pokemon red?

I think MCPs compensate for the unreliability issue by providing a minimal and well defined interface to a controlled set of actions. That way, the llm doesn't have to be as reliable thinking what it needs to do and in acting, just in choosing what to do from a short list.

I had to switch to reader mode. You're not missing much

Right, but they are also weaponising the lack of limitations - advertising is out of control and damaging society. Damned if you do, damned if you don't?

I'm talking about highway driving. At traffic lights the behaviour I see is people stacking up in one lane when there's a zipper merge across the intersection - I don't get this either, but it's good for me because there's plenty of room to skip past that line and merge in while the stack dawdles across the road, the inchworm-style traffic movement leaving plenty of space between each car

There's a certain satisfaction in anticipating these stop and go waves while driving, and timing it so that you catch the tail just as it starts moving again - the goal being to use the brake as little as possible and ideally only need to adjust acceleration. I don't really get why people feel the need to repeatedly accelerate up and then slam on the brakes, when leaving reasonable gaps makes everything go smoother.

Oh you're right, I misread. That's much worse for those 4 people but still not too bad (so far)

I suppose it depends if it's worse than reported currently, but it seems to me that with only 600 accounts losing an average of ~$800 each (and I'm going to go out on a limb and assume the users had poor password security), the fast detection and the immediate action to lock it down, there was a good and effective response by the companies attacked

Won't it throw the same "FileNotFound" exception in that case? The issue being bothering to check if it exists in the first place I suppose.

I have been saying this about llms for a while - if you know what you want, how to ask for it, and what the correct output will look like, LLMs are fantastic (at least Claude Sonnet is). And I mean that seriously, they are a highly effective tool for productive development for senior developers.

I use it to produce whole classes, large sql queries, terraform scripts, etc etc. I then look over that output, iterate on it, adjust it to my needs. It's never exactly right at first, but that's fine - neither is code I write from scratch. It's still a massive time saver.

Sounds like Tim's in a position where he knows he's appreciated by his team and enjoys his work, and is more than skilled enough to jump ship the second upper management decides to upend that. He has no reason to play the silly metrics games

I don't quite understand people's problem with LinkedIn - for me it has only one real page, my profile, and two other areas: recruiter chat and people I might know personally to link to. I got a job via recruiter chat on it once, and I drop in every few months or years to add a dot point to the resume. There's nothing else on that site?

Ok but Celsius works wherever you are (adjusting for pressure)

Fahrenheit doesn't match the 1-100 scale, though - Celsius does. 0 water freezes, 100 water boils.

On the moon, the sunlight bouncing around is still enough to outshine the stars

You don't usually see stars during the day

I agree; in my experience, pretty much everything is ETL. We take data from one thing, change it a bit, and put it somewhere else. Sometimes, as a treat, we take data from two things, put them together, and then put that somewhere else.

Frontend, backend, databases, services, reports, whatever - ETL.

In that context, the types and transformations between types are the most important feature. (Everything is actually Category Theory)

Oh sure, the flip side of doing what was asked is doing what is known - choosing a solution based on familiarity rather than applicability. Also a common trait in juniors in my experience

Right, that is their main limitation currently - unable to consider the full system context when operating on a specific feature. But you must work with excellent juniors (or I work with very poor ones) because getting them to think about changes in the context of the bigger picture is a challenge.