Hacker News: igrunert

Oxide raises $200M Series C

igrunert — Tue, 10 Feb 2026 14:20:49 +0000

Article URL: https://oxide.computer/blog/our-200m-series-c

Comments URL: https://news.ycombinator.com/item?id=46960036

Points: 614

# Comments: 335

New comment by igrunert in "Sinclair C5"

igrunert — Thu, 15 Jan 2026 17:39:57 +0000

If you're in Denver, Colorado you can see one in-person at The Forney Museum of Transportation.

New comment by igrunert in "Orion 1.0"

igrunert — Tue, 25 Nov 2025 17:18:17 +0000

WebKit on Windows has progressed since ~5 years ago. The gap between the Windows port and the Linux WPE/GTK ports is shrinking over time.

Every JIT tier has been enabled for JSC on Windows[1], and libpas (the custom memory allocator) has been enabled.

The Windows port has moved from Cairo to Skia, though it's currently using the CPU renderer AFAIK. There's some work to enable the COORDINATED_GRAPHICS flag which would enable Windows to benefit from Igalia's ongoing work on improving the render pipeline for the Linux ports. I go into more detail on my latest update [2], though the intended audience is really other WebKit contributors.

Webkit's CI (EWS) is running the layout tests on Windows, and running more tests on Windows is mostly a matter of test pruning, bug fixes and funding additional hardware.

There's a few things still disabled on the Windows port, some rough edges, and not a lot of production use (Bun and Playwright are the main users I'm aware of). The Windows port really needs more people (and companies) pushing it forward. Hopefully Kagi will be contributing improvements to the Windows port upstream as they work on Orion for Windows.

[1] https://iangrunert.com/2024/10/07/every-jit-tier-enabled-jsc... [2] https://iangrunert.com/2025/11/06/webkit-windows-port-update...

New comment by igrunert in "Helium Browser"

igrunert — Wed, 08 Oct 2025 18:41:35 +0000

The layout tests on Windows are failing at the moment due to a regression introduced a few days ago (likely https://commits.webkit.org/301043@main).

The easiest way to run WebKit on Windows is via Playwright.

New comment by igrunert in "Firefox 32-bit Linux Support to End in 2026"

igrunert — Mon, 08 Sep 2025 17:46:37 +0000

A CMPXCHG16B instruction is going to be faster than a function call; and if the function is inlined there's still binary size cost.

The last processor without the CMPXCHG16B instruction was released in 2006 so far as I can tell. Windows 8.1 64-bit had a hard requirement on the CMPXCHG16B instruction, and that was released in 2013 (and is no longer supported as of 2023). At minimum Firefox should be building with -mcx16 for the Windows builds - it's a hard requirement for the underlying operating system anyway.

New comment by igrunert in "Apple's Assault on Standards"

igrunert — Wed, 03 Sep 2025 15:34:55 +0000

The "Chrome Commit Tracker" linked is a pretty interesting set of visualizations that I hadn't come across before. Makes it a lot easier to get a feel for the sizes of the various teams, and how they change over time.

https://chrome-commit-tracker.arthursonzogni.com/organizatio...

New comment by igrunert in "I tried Servo"

igrunert — Fri, 01 Aug 2025 03:13:32 +0000

WebKit runs on Windows, the Windows port just needs work to bring it up to the level of the Linux port. I got every JIT tier enabled in JavaScriptCore [1] and enabled libpas (the memory allocator). The Windows port is moving to Skia in line with the Linux port.

Really just needs more people (and companies) pushing it forward. Hopefully Kagi will be contributing improvements to the Windows port upstream.

[1] https://iangrunert.com/2024/10/07/every-jit-tier-enabled-jsc...

New comment by igrunert in "I ported pigz from Unix to Windows"

igrunert — Tue, 24 Jun 2025 00:04:23 +0000

Ah yeah, I see Firefox ran into that and added retries:

https://hacks.mozilla.org/2022/11/improving-firefox-stabilit...

Seems like a worthwhile change, though I'm not sure when I'll get around to it.

New comment by igrunert in "I ported pigz from Unix to Windows"

igrunert — Mon, 23 Jun 2025 22:40:15 +0000

I recently ported WebKit's libpas memory allocator[1] to Windows, which used pthreads on the Linux and Darwin ports. Depending on what pthreads features you're using it's not that much code to shim to Windows APIs. It's around ~200 LOC[2] for WebKit's usage, which a lot smaller than pthread-win32.

[1] https://github.com/WebKit/WebKit/pull/41945 [2] https://github.com/WebKit/WebKit/blob/main/Source/bmalloc/li...

New comment by igrunert in "Jemalloc Postmortem"

igrunert — Fri, 13 Jun 2025 12:38:06 +0000

I think the author was happy to be employed by a megacorp, along with a team to push jemalloc forward.

He and the other previous contributors are free to find new employers to continue such an arrangement, if any are willing to make that investment. Alternatively they could cobble together funding from a variety of smaller vendors. I think the author is happy to move on to other projects, after spending a long time in this problem space.

I don’t think that “don’t let one megacorp hire a team of contributors for your FOSS project” is the lesson here. I’d say it’s a lesson in working upstream - the contributions made during their Facebook / Meta investment are available for the community to build upon. They could’ve just as easily been made in a closed source fork inside Facebook, without violating the terms of the license.

Also Mozilla were unable to switch from their fork to the upstream version, and didn’t easily benefit from the Facebook / Meta investment as a result.

New comment by igrunert in "Kagi Is Bringing Orion Web Browser to Linux"

igrunert — Sun, 09 Mar 2025 01:37:30 +0000

The gap between the Windows and GTK ports is shrinking. Every JIT tier has been enabled for JSC on Windows[1], and libpas (the custom memory allocator) should get enabled soon.

The Windows port is moving from Cairo to Skia soon as well, matching the GTK port (though I think the focus is enabling the CPU renderer to start).

Webkit's CI (EWS) is running the layout tests on Windows, and running more tests on Windows is mostly a matter of funding the hardware.

There's a few things still disabled on the Windows port, some rough edges, and not a lot of production use (Bun and Playwright are the main users). It'd definitely be more work than Linux, but it's not as bad as you'd think.

[1] https://iangrunert.com/2024/10/07/every-jit-tier-enabled-jsc...

New comment by igrunert in "Welcome to Ladybird, a truly independent web browser"

igrunert — Fri, 28 Feb 2025 15:44:24 +0000

While the modern web is complicated, there's a few things working in Ladybird's favor.

Web Platform Tests (1) make it significantly easier to test your compliance with W3C standards. You don't have to reverse engineer what other engines are doing all the time.

The standards documents themselves have improved over time, and are relatively comprehensive at this point. Again, you don't have to reverse engineer what other engines are doing, the spec is relatively comprehensive.

Ladybird has chosen to not add a JIT compiler for JS and Wasm, reducing complexity on the JS engine. They're already reached (or exceeded) other JS engines on the ECMAScript Test Suite Test262 (2).

There's a big differential between the level of investment in Chromium and the other engines - in part because Chrome / Chromium are often doing R&D to build out new specifications, which is more work than implementing a completed specification. There's also a large amount of work that goes into security for all three major engines - which (for now) is less of a concern for Ladybird.

I'm confident that the Ladybird team will hit their goal of Summer 2026 for a first Alpha version on Linux and macOS. They'll cut a release with whatever they have at that point - it's already able to render a large swathe of the modern web, and continues to improve month-on-month.

(1) https://web-platform-tests.org/ (2) https://test262.fyi/

New comment by igrunert in "Welcome to Ladybird, a truly independent web browser"

igrunert — Fri, 28 Feb 2025 15:18:43 +0000

Ladybird does have another slight advantage in that it only has an interpreter for JS and wasm, instead of maintaining multiple tiers of JIT compilation for both. That choice materially reduces the surface area for exploits.

New comment by igrunert in "Servo's progress in 2024"

igrunert — Wed, 05 Feb 2025 17:19:35 +0000

For Ladybird - Andreas Kling called out that the vast majority of "easy tests" are passing and each additional test is going to be more difficult to come by going forward.

https://www.youtube.com/watch?v=-l8epGysffQ (1 minute - 4 minute)

New comment by igrunert in "Rewrite Git history via drag-and-drop"

igrunert — Tue, 03 Dec 2024 15:58:50 +0000

There are a handful of git features which work significantly better with a clean history on main. If `git blame` points at a well crafted commit, it can help bring additional context to the line in question. In addition `git log -S` can be used to find when code was introduced.

Both of these features aren't very useful when they point at a "wip" or similar commit message.

By all means push lots of little commits to your branch while you're figuring stuff out, but squash and rewrite history into logical commits (usually just one) before landing the change on main.

New comment by igrunert in "WASM Is the New CGI"

igrunert — Thu, 10 Oct 2024 14:53:42 +0000

When discussing security it's important to keep in mind the threat model.

We're mostly concerned with being able to visit a malicious site, and execute wasm from that site without that wasm being able to execute arbitrary code on the host - breaking out of the sandbox in order to execute malware. You say the only benefit is that access to the OS is isolated, but that's the big benefit.

Having said that, WebAssembly has some design decisions that make your exploits significantly more difficult in practice. The call stack is a separate stack from WebAssembly memory that's effectively invisible to the running WebAssembly program, so return oriented programming exploits should be impossible. Also WebAssembly executable bytecode is separate from WebAssembly memory, making it impossible to inject bytecode via a buffer overflow + execute it.

If you want to generate WebAssembly code at runtime, link it in as a new function, and execute it, you need participation from the host, e.g. https://wingolog.org/archives/2022/08/18/just-in-time-code-g...

Every JIT tier enabled for JavaScriptCore on Windows

igrunert — Tue, 08 Oct 2024 16:11:27 +0000

Article URL: https://iangrunert.com//2024/10/07/every-jit-tier-enabled-jsc-windows.html

Comments URL: https://news.ycombinator.com/item?id=41778939

Points: 7

# Comments: 0

New comment by igrunert in "Browsers Are Weird"

igrunert — Tue, 06 Feb 2024 06:38:02 +0000

> But (Safari is) the only option here that’s unsupported outside one manufacturer’s hardware.

You can use WebKit on Linux via GNOME Web (WebKitGTK), it's maintained by Igalia. Though that won't get you cross-device syncing, which is the main reason people want support on alternate hardware.

WebAssembly on WebKit for Windows

igrunert — Mon, 04 Dec 2023 15:58:24 +0000

Article URL: https://iangrunert.com//2023/12/01/webassembly-webkit-windows.html

Comments URL: https://news.ycombinator.com/item?id=38518855

Points: 2

# Comments: 0

New comment by igrunert in "Choose the browser that best suits your privacy needs"

igrunert — Mon, 27 Nov 2023 16:36:01 +0000

I think a big reason developers don't choose WebKit is due to the Windows port requiring significant work, and most new browsers want to support Windows.

On this thread there was a rough estimate of $1M - $2M USD to do that work. It's probably not far off the mark.

https://orionfeedback.org/d/2321-orion-for-windows-android-l...