plesiv

It could have military applications; it's hard to imagine any civilian applications.

Beautiful writing style. So light, still eloquent.

The existence of an undiscovered soundness bug doesn't make everything proven in Lean illicit. The proof would have to exploit the bug. People build houses on sound foundations even though the tectonic situation under them might not be sound.

> Because of these properties, the final backstop has to be humans...

The post has clearly stated that the work on Lean's underlying metatheory is not done, and requires more work. It's not inconceivable that computer formal verification could reach the trustworthiness of math itself.

Your probability distribution should be flatter at least.

Ridiculous CC bug I encountered, that others have encountered as well: I asked Fable to review a commit. Suddenly my Fable quota for the week was at 100%, while a moment ago it was at 55%. A few days pass (1 day before the weekly reset) the quota resets back to 55%. ?!?!?!?!

https://status.claude.com/ indicates "All Systems Operational"

The "this wasted my time" comments are missing the point...

In addition to his great sense of humor, Steve is usually ahead of the curve in terms of trends. There's a lesson in this. LLMs have become incredible constraint solvers ("SAT-solvers for code"). Well-thought-out tests, types, specs, and docs are all incredibly valuable constraints. This has big implications - for example what happens to licenses when you can cheaply rewrite the codebase and therefore unencumber it.

You can add this as a bookmark in your browser, and just click it to toggle between x.com and xcancel.com

javascript:(function(){const p=['https://x.com','https://xcancel.com'],u=location.href,i=p.findIndex(x=>u.startsWith(x));if(i!==-1)location.href=p[(i+1)%p.length]+u.slice(p[i].length)})();

We're building a similar product at https://gitlip.com

We would love to speak to any Glitch users about their particular use case. Please reach out to natalie [at] gitlip.com

Name suggestion for the wall: "Hydrobit generator"

OP here. Oops, thank you for pointing that out! We weren’t aware of it. We will investigate ASAP. In the worst case, we’ll change our name.

Great question! By default, with libgit2 each write to a repo (e.g. push) will create a new pack file. We have written a simple packing algorithm that runs after each write. It works like this:

Choose these values:

* P, pack "Planck" size, e.g. 100kB

* N, branching factor, e.g. 8

After each write:

1. iterate over each pack (pack size is S) and assign each pack a class C which is the minimum integer that satisfies P * N^C > S

2. iterate variable c from 0 to the maximum value of C that you got in step 2

* if there are N packs of class c, repack them into a new pack, new pack is going to be at most of class c+1

OP here. We're not an AI company; we're aiming to be AI-adjacent and simplify the practical application of AI models.

OP here. Thank you and good catch! :-) We have a blog post planned on that topic.

OP here. Not yet - it's about 50% complete. I plan to open-source it in the future.

OP here. We’re building a new kind of Git platform. "Infinity" is more beneficial for us as platform builders (simplifying infrastructure) but less relevant to our customers as users.

OP here. That’s expected for now, and we’re working on a solution. We didn’t explain the reason in the post because we plan to cover it in a separate write-up.

Definitely! We're focused on launching right now, but once we have more bandwidth, we'd be happy to do it.

I believe our changes are solid, but they’re tailored specifically to our use case and can’t be merged as-is. For example, our modifications to libgit2 would need at least as much additional code to make them toggleable in the build process, which requires extra effort.

OP here.

It’s unlikely any Git providers struggle with the number of repos they're hosting, but most are larger companies.

Currently, we're a bootstrapped team of 2. I think our approach changes the kind of product we can build as a small team.

The cat runs, eats and has fur. The cat is a dog.

Other methods use heuristics to guess many filetypes and in the benchmark they show worse performance (in terms of precision). Assuming benchmarks are not biased, the fact that this approach uses AI heuristics instead of hard-coded heuristics shouldn't make it strictly worse.

> In our previous startup, a data scientist accidentally destroyed a month’s work of his team by using the wrong Git command.

I'd like to hear about how this happened. No one in the team heard of reflog?

This one is funny: https://github.com/bagder/emails/blob/main/2016/2016-01-19.m...

> ... I came across this information using my Spotify which has also been hacked into and would love your help hacking out of Spotify. Also, I have yet to figure out how to unhack the hackers from my Instagram ...

Here are some benchmarks: https://bellard.org/quickjs/bench.html

I have the exactly opposite experience of yours. Cloudflare DX is by far the best among the cloud providers I've tried. Today, it's not that complicated to setup wrangler with credentials to your Cloudflare account in any mayor CI. If you have multiple services in your repo you can have multiple directories with each containing its own wrangler.toml. You can even connect these services with service bindings (beta feature still).

In my mind Cloudflare gets the big picture of DX exactly right. When deploying your service the deployment itself is not stateful, there's only one step to it: 'wrangler deploy'. Compare that to AWS Lambda: 1. build you code, 2. pack into a zip file, 3. make sure the S3 bucket exists, 4. upload the zip to the bucket, 5. deploy lambda, 6. update API gateway... And don't even get me started on Cloudfront - every change takes like 5min to apply.

Every so often I do encounter some rough edges, like service bindings binding to deployed services or workerd binary dynamically linking to some shared libraries so wrangler installed through npm doesn't work on Nixos etc. That said I respect the approach Cloudflare team is taking by focusing on the really important stuff first.

...

OP, you have garnered a lot of sympathy by the HN community which I believe in part contributed to your problem being resolved. I think it would be fair to provide more info about what the issue was in the end. It's not OK to be like "HN I had a bad experience with Company X" and then be like "k, thx @jgrahamc, bye" when your complaint gets resolved due to the attention it received.

There are so many questions this leaves unanswered:

- Was this a one-off error in Cloudflare processes? (These things happen on a big enough scale.)

- Were you violating a specific clause of Cloudflare's T&C? How clear was the clause? What did you do to fix this?

- Was the issue that Cloudflare estimated that you're not paying enough given the bandwidth you're consuming? Did you end up signing up for the Enterprise plan?

Transparency would benefit both Cloudflare (in not making people unnecessarily apprehensive about becoming/remaining a customer) and you (in demonstrating that you're handling this issue in a professional and responsible manner).