Hacker News: durin42

New comment by durin42 in "µcad: New open source programming language that can generate 2D sketches and 3D"

durin42 — Mon, 24 Nov 2025 13:18:57 +0000

I asked sometime in 2024 and I got a pretty clear response that local/self hosting is not planned.

New comment by durin42 in "Jujutsu at Google [video]"

durin42 — Fri, 31 Oct 2025 15:14:54 +0000

> That's how I look when I'm excited

I can confirm this (we've worked together)

New comment by durin42 in "The terms of the AGPL are pretty easy to comply with"

durin42 — Mon, 27 Jul 2020 18:45:04 +0000

Or listen to Daniel Berlin, who's both an accomplished GCC hacker and a lawyer:

https://news.ycombinator.com/item?id=9956542 https://news.ycombinator.com/item?id=13979443

This isn't settled law, and DannyBee would be quick to point out that the practice of law has a major component of risk management.

New comment by durin42 in "Sunsetting Mercurial Support in Bitbucket"

durin42 — Tue, 20 Aug 2019 14:00:36 +0000

1) hg absorb

2) hg-git exists, and there's other things afoot that should be better

New comment by durin42 in "Sunsetting Mercurial Support in Bitbucket"

durin42 — Tue, 20 Aug 2019 13:17:45 +0000

Please feel encouraged to report a bug about histedit slowness with some details so we can try and reproduce and consider a fix.

New comment by durin42 in "Sunsetting Mercurial Support in Bitbucket"

durin42 — Tue, 20 Aug 2019 13:13:35 +0000

Piper still exists, but Mercurial is a viable client tool to interact with Piper's version history.

New comment by durin42 in "Adding Mercurial support to Gitlab"

durin42 — Thu, 20 Sep 2018 18:04:22 +0000

Sounds a lot like https://twitter.com/indygreg/status/1028097388261433344 - I'm pretty sure Greg was working with hg when he noticed this issue.

In any event, if you're enthusiastic about this kind of thing, we'd love to have more eyes on making hg checkouts consistently fast, even in the face of filesystems undermining those efforts. ;)

New comment by durin42 in "Adding Mercurial support to Gitlab"

durin42 — Thu, 20 Sep 2018 15:34:19 +0000

How long ago was this? And what OS? I know we're faster than unzip on some platforms, but IIRC we just found a pretty awful performance issue on...linux? I think?... that meant our parallelized approach to writing files was burning a ton of time in the kernel filesystem locks or something.

New comment by durin42 in "Lockbox – A stand-alone password manager that works with Firefox for desktop"

durin42 — Mon, 26 Mar 2018 20:31:10 +0000

You might find https://github.com/jcs/bitwarden-ruby an interesting hosting alternative, FWIW.

New comment by durin42 in "Using Rust in Mercurial"

durin42 — Mon, 04 Dec 2017 21:34:01 +0000

> rewrite a large part of hg in Rust

That's not really the right story. The motivating factor is that we'd like to write /less C/, not /less Python/. It's likely in the long-term that parts of the code that are performance sensitive will move out of Python, but we've been doing that for years, and we just keep finding new things to optimize as the scale of Mercurial repositories keeps increasing.

New comment by durin42 in "Using Rust in Mercurial"

durin42 — Mon, 04 Dec 2017 21:21:14 +0000

Last I knew it worked fine, but hg doesn't tend to run long enough for the JIT to warm up enough and be an unambiguous win. Fijal complemented us on how good our C was.

I think it does work if you do chg with a commandserver in pypy.

New comment by durin42 in "Using Rust in Mercurial"

durin42 — Mon, 04 Dec 2017 20:24:47 +0000

Go isn't really a huge win for hg, and it doesn't support being used as a shared library, so we couldn't easily use it as a replacement for C for native extensions. main() has to be in Go, and even then you've got two GCs in the mix which is not great.

New comment by durin42 in "Using Rust in Mercurial"

durin42 — Mon, 04 Dec 2017 20:12:24 +0000

There's pretty broad consensus that we'd like to do Rust and not C for future extension work, but the current plan is that a pure-Python hg will also be something we support. The "rust binary that embeds Python" approach looks like a straightforward win on Windows, where we have a native .exe that embeds Python anyway. I'm not sure if that'll make sense on non-Windows, but we'll see.

I've done some poking around with milksnake, which seems extremely promising for writing native speedups.

New comment by durin42 in "Better Compression with Zstandard"

durin42 — Tue, 07 Mar 2017 20:58:54 +0000

I wouldn't worry. It sounds very similar to what's been in Apache2 for years: http://en.swpat.org/wiki/Patent_clauses_in_software_licences...

New comment by durin42 in "Python moved to GitHub"

durin42 — Mon, 13 Feb 2017 15:06:09 +0000

All the communities I know that are centered around diff-in-email patch review are quite frustrated by the available GUI tools (most of them are only good for one patch at a time, or treat an entire stack of patches as one change). If you get somewhere with this, let me know? We might be interested in testing it on Mercurial depending on how it integrates with the email side...

New comment by durin42 in "Announcing GVFS: Git Virtual File System"

durin42 — Fri, 03 Feb 2017 15:39:09 +0000

That's actually pretty comparable to how we tend to operate the Mercurial project, FYI. We tend to prefer rebase to merge for feature work.

New comment by durin42 in "Announcing GVFS: Git Virtual File System"

durin42 — Fri, 03 Feb 2017 15:02:33 +0000

Sprints are twice a year, once in the US and once in Europe.

New comment by durin42 in "Ask HN: What was your “why didn't I start doing this sooner” moment?"

durin42 — Sat, 30 Jul 2016 03:39:12 +0000

That's pretty standard as the assumed interest rate for investing in index funds over a long period.

New comment by durin42 in "Why Google Stores Billions of Lines of Code in a Single Repository"

durin42 — Wed, 29 Jun 2016 01:26:21 +0000

It's likely that Mercurial would scale for you today, using Facebook's stack. Drop me an email if you'd like to chat sometime.

New comment by durin42 in "Why Google Stores Billions of Lines of Code in a Single Repository"

durin42 — Tue, 28 Jun 2016 20:11:43 +0000

It's not a fork - they've got some extensions for some special things, yes, but they're running mostly stock Mercurial.