perlgeek

NK, NK, NK.

Seriously, they have professionalized attacks on crypto infra to a degree that whenever you hear about a massive heist, you can be pretty sure it's North Korea.

I love how @cz_binance tweeted "user funds are safe!" in that thread. Wasn't that a bit too early? Are they?

Why would request compression be obscure? When you support posting big forms, requests get big too, so why not compress them?

It seems the bugocalypse (or however you write that) has landed.

It seems that somebody / something only created a single byte of randomness for each certificate.

You should start at "" or 0, not "1".

Back in perl 5.8 and older, the regex engine worked by recusing at the level of C functions, and so you could trigger stack overflows by giving it large strings.

Is this similar?

I wonder why gitlab even has its own regex compiler. Or is this a vulnerability in an underlying library or programming language?

My attempts at finding a middle ground:

* I use LLMs to resolve the more annoying merge conflicts. It's not super hard work, but I don't like it, and I don't think I learn much from doing it.

* I implement a feature by hand, write some basic tests, and tell the AI to review it and write tests for cases that I missed (or was too lazy to do, most of the time)

* For 80% of the bugs that I fix, I have a pretty good idea going in where the bug might be. In the other cases, I ask the LLM to generate a list of hypotheses what's wrong. Often (but not always) it turns out one of the hypotheses was right.

* Sometimes it's not so easy to figure out how to trigger a bug in a test case. Haven't done it yet, but I plan to ask LLMs to experiment to try to do that for me.

* I use LLMs to generate tools that I wouldn't otherwise write (not high enough priority, too lazy, ...). For example, we had a rabbitmq connector that occasionally kept getting stuck without reconnecting in rare patterns of network interruptions. It wasn't really high priority for us (rare, easy to work around by restarting the service), so I didn't want to spend days of engineering on it. I asked Claude to write me a test harness that reproduced the issue, and it did. Having a bunch of automatically runnable scenarios made the actual fix not too hard.

* Sometimes, I have some software design problems where I feel I have a pretty good solution, but something about it feels off. Talking this through with an LLM often helps to refine or change the approach.

---

This approach to AI usage doesn't make me 10x more productive, but I do think it's a net benefit both for code quality and my enjoyment of the job. I don't know if, in a few months or years from now, I'll still be competitive like this, but right now, I'm doing fine.

I think it really depends on the language and the project.

The more types of potential errors your compiler catches, the fewer unit tests you need. Haskell needs fewer (and potentially different) tests than Perl or Python.

The other thing where unit tests really shine is testing a complex algorithm. If you think of a problem with a very well-defined output (like sorting, searching, some types of computation, graph algorithms, geometry problems etc.), then it's pretty easy to come up with a stable API and thus stable tests. I'm pretty convinced that unit tests give you more bang for the buck than plain-English test plans that you need to spend tokens on to evaluate.

The difference is that the employees at tier 1 backbone providers get paid, and if one of them quits, there is an organization responsible (and incentivized) to hire and train replacements.

Yes, we should all have opinions on products that consume resources on a societal scale.

Opinions don't necessarily equate with a desire to remove them, there could also be (dis)-incentives like taxes, removal of subsidies etc.

Technically, this doesn't answer the question, which was about investment money, not about the investment firms.

It's certainly well spent if we eat the crops.

If it's fed to farm animals for meat, that reduces its efficiency by an order of magnitude. There's still plenty of discussion to be had if that is water well spent. It probably depends on a lot of factors.

Renting out compute is a viable business model. That's part of what the big and the small cloud providers do. It's just (on its own) not a "get rich quick" business model anymore.

Why would it be any different for inference? If we believe OP, it'll just become part of regular compute infra, and thus part of the renting-out-compute business model.

I think it's an open question if the current generation of inference investment will pan out, but in the long term, there'll be a balance between investment cost and margin, just as in every other industry.