? Curious Hacker Newsfront | about | examples | prompts | view on HN unofficial mirror
September in Servo: <progress>, rounded rectangles, and more (servo.org)
206 points by iamnothere 2026-11-05 | 50 comments | side by side | 0 rewritten | show 1 removed | updated 05:09 UTC
 help



Although Servo is great I believe Ladybird is already much further along and they're currently porting their codebase to Rust (it's currently in C++).

Although Servo is great I believe Ladybird is already much further along and they're currently porting their codebase to Rust (it's currently in C++).

A civil, on-topic comparison of Servo and Ladybird with a factual claim about Ladybird's Rust port.

Servo is really great: Rust seems like a no brainer choice for a modern web engine, and its clean, performance-focused design from the ground up is wonderful.

But it seems really hard for it to get anywhere just based on occasional contributions from volunteers. I was actually quite surprised that basic functionality like <progress> and the :checked attribute were not even supported prior to this release.

Servo got 527 commits, while Chromium has over 20,000 commits.

Servo is really great: Rust seems like a no brainer choice for a modern web engine, and its clean, performance-focused design from the ground up is wonderful.

But it seems really hard for it to get anywhere just based on occasional contributions from volunteers. I was actually quite surprised that basic functionality like <progress> and the :checked attribute were not even supported prior to this release.

Servo got 527 commits, while Chromium has over 20,000 commits.

Substantive observation on Servo's design and how far its contributor resources lag Chromium, with concrete commit numbers.
btown 2026-11-05 21:587/10informativeinsightful | parent | next [–]

Part of this, as others have noted, is due to: https://book.servo.org/policy/ai-usage.html

> Can I submit a PR that includes code generated by AI tools?

> No. This includes (but is not limited to) all generative AI tools like Claude, Codex, ChatGPT, Cursor, Gemini, and Windsurf.

For something like a browser, this de facto limits the set of people who can contribute to something that touches the layout engine (e.g. the ineffable but brilliant https://github.com/servo/servo/blob/main/components/layout/flow/float.rs) to just those already familiar with the code.

A much better middle ground IMO would be to quarantine first-time committers behind an AI-generated-PRs-will-not-be-reviewed policy, but to allow those who understand and respect the cycle enough to get PRs accepted, to begin using AI to give the team leverage. Without some kind of policy like that, Servo's sadly going to fall behind literally any other open-source project that people could dedicate their time towards.

Part of this, as others have noted, is due to: https://book.servo.org/policy/ai-usage.html

> Can I submit a PR that includes code generated by AI tools?

> No. This includes (but is not limited to) all generative AI tools like Claude, Codex, ChatGPT, Cursor, Gemini, and Windsurf.

For something like a browser, this de facto limits the set of people who can contribute to something that touches the layout engine (e.g. the ineffable but brilliant https://github.com/servo/servo/blob/main/components/layout/flow/float.rs) to just those already familiar with the code.

A much better middle ground IMO would be to quarantine first-time committers behind an AI-generated-PRs-will-not-be-reviewed policy, but to allow those who understand and respect the cycle enough to get PRs accepted, to begin using AI to give the team leverage. Without some kind of policy like that, Servo's sadly going to fall behind literally any other open-source project that people could dedicate their time towards.

Substantive argument citing Servo's AI policy and proposing a concrete alternative; firm opinion without any personal attack.
fabrice_d 2026-11-05 22:536/10questioninformative | root | parent | next [–]

Servo is already lacking reviewers. How would accepting AI contributions help?

Servo is already lacking reviewers. How would accepting AI contributions help?

Short, firm pushback with a concrete point about reviewer capacity; a genuine question, not a jab.

> > No. This includes (but is not limited to) all generative AI tools like Claude, Codex, ChatGPT, Cursor, Gemini, and Windsurf

Based on the tool listed here, you can probably know when this policy was first written. For instance, Windsurf is long gone and Cursor is not tier 1 anymore.

Crazy to think how much the space of AI coding agent has evolved in less than 2 years.

> > No. This includes (but is not limited to) all generative AI tools like Claude, Codex, ChatGPT, Cursor, Gemini, and Windsurf

Based on the tool listed here, you can probably know when this policy was first written. For instance, Windsurf is long gone and Cursor is not tier 1 anymore.

Crazy to think how much the space of AI coding agent has evolved in less than 2 years.

A civil, minor observation about how fast the AI tooling landscape changed, as dated by the policy's tool list.

Yeah, it's a fun time capsule. The policy was written in July 2024 [1]. There's a contentious discussion in 2025 [2] where they discussed it and reaffirmed the ban. Then in June 2026 they reiterated the ban and added CI checks to reject AI coauthors [3]

[1] https://github.com/servo/book/commit/5afb80d5b08b259ca359cfe0fd1355a3d4583c61

[2] https://github.com/servo/servo/discussions/36379

[3] https://servo.org/blog/2026/06/30/may-in-servo/

Yeah, it's a fun time capsule. The policy was written in July 2024 [1]. There's a contentious discussion in 2025 [2] where they discussed it and reaffirmed the ban. Then in June 2026 they reiterated the ban and added CI checks to reject AI coauthors [3]

[1] https://github.com/servo/book/commit/5afb80d5b08b259ca359cfe0fd1355a3d4583c61

[2] https://github.com/servo/servo/discussions/36379

[3] https://servo.org/blog/2026/06/30/may-in-servo/

Sourced timeline of Servo's AI policy that directly answers the parent's speculation.

> Rust seems like a no brainer choice for a modern web engine

Well, I mean Servo was the original catalyst and production use-case for Rust back in 2012. Both are products of the work of various folks at Mozilla around the time.

> Rust seems like a no brainer choice for a modern web engine

Well, I mean Servo was the original catalyst and production use-case for Rust back in 2012. Both are products of the work of various folks at Mozilla around the time.

Adds useful historical context that Servo and Rust grew up together at Mozilla.

And large parts of the project replaced parts of Firefox like the renderer and CSS engine nearly a decade ago.

And large parts of the project replaced parts of Firefox like the renderer and CSS engine nearly a decade ago.

Short, accurate historical addition about Servo components (WebRender, Stylo) landing in Firefox.

There are not just volunteer contributions, but also people working full time on Servo: some at Igalia, and some at Huawei at least.

There are not just volunteer contributions, but also people working full time on Servo: some at Igalia, and some at Huawei at least.

Civil factual correction adding who actually funds full-time Servo work.

Language choice has next to nothing to do with browser performance. Servo's "performance-focused" design currently suffers from a 10x gap between it and Chrome on the same platform.

Language choice has next to nothing to do with browser performance. Servo's "performance-focused" design currently suffers from a 10x gap between it and Chrome on the same platform.

Firm, substantive disagreement with a concrete performance claim and no personal swipe.

10x gap on which benchmark?

10x gap on which benchmark?

A genuine, short question asking for the evidence behind a specific performance claim.

Speedometer 3.1

Speedometer 3.1

A terse, direct answer to the parent's question naming the benchmark.

Remember that if you value Servo you can sponsor them, details at https://servo.org/sponsorship/

Remember that if you value Servo you can sponsor them, details at https://servo.org/sponsorship/

Short, useful pointer to how readers can financially support the project.

It's heartening to see a large group of people working (mostly) for free on a passion project. Makes me optimistic about the resilience of intrinsic human drive.

It's heartening to see a large group of people working (mostly) for free on a passion project. Makes me optimistic about the resilience of intrinsic human drive.

Sincere, on-topic appreciation of the project's volunteer effort; minor but in good faith.
shakna 2026-11-05 19:527/10first_handinformative | prev | next [–]

Progress got my attention.

As an on-again off-again project, I've been building an incremental game that is pretty much just hundreds of progress bars - a little bit out of the norm for the browser.

Firefox everything renders smoothly and gently.

Chrome chugs, skips paints, delays animation frames, skips some events, and batches others.

Game uses a few features that aren't in Servo yet... But maybe I can tweak it...

Progress got my attention.

As an on-again off-again project, I've been building an incremental game that is pretty much just hundreds of progress bars - a little bit out of the norm for the browser.

Firefox everything renders smoothly and gently.

Chrome chugs, skips paints, delays animation frames, skips some events, and batches others.

Game uses a few features that aren't in Servo yet... But maybe I can tweak it...

First-hand comparison of how browsers handle hundreds of progress bars, tied directly to the story.

One of the things I find really helpful about servo (as a casual user) is the breadth of pre-built releases they have. It makes it much more feasible to actually use on a day-to-day basis, especially on android

One of the things I find really helpful about servo (as a casual user) is the breadth of pre-built releases they have. It makes it much more feasible to actually use on a day-to-day basis, especially on android

A brief first-hand note on how Servo's pre-built releases, especially on Android, make daily use practical.

wow! they already have android apk? Awesome!

wow! they already have android apk? Awesome!

Short, genuine enthusiasm that responds to the parent; nothing a moderator would object to.

login form on HN does not work, but servo is working! :D

login form on HN does not work, but servo is working! :D

Brief first-hand report that the HN login form fails in Servo's Android build while the browser otherwise runs.
caminanteblanco 2026-11-05 15:525/10first_handinformative | root | parent [–]

It was working a second ago (I made the parent comment from servo) but it looks like you get logged out pretty quickly. YMMV, plus probably best not to log into anything too important yet

It was working a second ago (I made the parent comment from servo) but it looks like you get logged out pretty quickly. YMMV, plus probably best not to log into anything too important yet

First-hand report of logging in to HN from Servo, with a practical caution about session behavior.

I do not think HN is important :) But thanks for warning.

I do not think HN is important :) But thanks for warning.

Light-hearted, harmless reply with no hostility, so it stays as written.

The progress on Servo is impressive. UI polish is required in order to be more usable. Things like keyboard shortcuts to focus the address bar are required to make it feasible for more daily driving use

The progress on Servo is impressive. UI polish is required in order to be more usable. Things like keyboard shortcuts to focus the address bar are required to make it feasible for more daily driving use

Civil, on-topic observation about what Servo needs for daily use, with a concrete example.

My understanding is that the main focus is on the engine and building a good embedding API so that folks can build browsers (and apps and web drivers etc...) with it.

My understanding is that the main focus is on the engine and building a good embedding API so that folks can build browsers (and apps and web drivers etc...) with it.

Politely adds useful context about the project's focus on the engine and embedding API.

That is my understanding too. In contrast Ladybird has really improved in the UI area and the recent addition of session restore, content blocking and performance makes it a very capable daily driver browser

That is my understanding too. In contrast Ladybird has really improved in the UI area and the recent addition of session restore, content blocking and performance makes it a very capable daily driver browser

Substantive comparison of Servo's engine focus with Ladybird's recent UI and browser features.

i've been hacking on my own browser using servo as a library! its lovely to interface with.

i've been hacking on my own browser using servo as a library! its lovely to interface with.

Brief first-hand experience of embedding Servo as a library, friendly and on topic.
nerdypepper 2026-11-05 21:495/10first_handinformative | parent | prev [–]

i have been hacking on my own servo-based browser using gpui for macos: https://tangled.org/oppi.li/meridian/

i have been hacking on my own servo-based browser using gpui for macos: https://tangled.org/oppi.li/meridian/

Shares a relevant first-hand project building a Servo-based browser with GPUI on macOS.

I want servo the succeed

I want servo the succeed

Short but sincere expression of support; nothing a moderator would ask the author to drop.

Sad to see Servo ban AI contributions.

Feels like a missed opportunity where we could take a giant leap forward.

Sad to see Servo ban AI contributions.

Feels like a missed opportunity where we could take a giant leap forward.

A brief, plainly stated opinion on Servo's AI contribution policy, with no attack on anyone.

The AI policy for Servo, which prohibits AI contributed code (but allows you to use AI to inspect and learn about the codebase), was written in mid-2024, which seems like an eternity ago.

But even in June 2026 they reiterated this ban and added CI checks to automatically reject AI-coauthored patches [1].

> For developers of Servo itself, please note that per project policy, you must not use the output of large language models or other generative AI tools in your contributions. To help us enforce that, we now have CI checks that reject AI agents as coauthors (@SimonSapin, @delan, #44723).

[1] https://servo.org/blog/2026/06/30/may-in-servo/

The AI policy for Servo, which prohibits AI contributed code (but allows you to use AI to inspect and learn about the codebase), was written in mid-2024, which seems like an eternity ago.

But even in June 2026 they reiterated this ban and added CI checks to automatically reject AI-coauthored patches [1].

> For developers of Servo itself, please note that per project policy, you must not use the output of large language models or other generative AI tools in your contributions. To help us enforce that, we now have CI checks that reject AI agents as coauthors (@SimonSapin, @delan, #44723).

[1] https://servo.org/blog/2026/06/30/may-in-servo/

Civil, factual summary of Servo's AI policy with a quote and a source link.

Giant leaps aren't typically the way to steady progress

Giant leaps aren't typically the way to steady progress

Terse but genuine disagreement with the parent's framing, with no swipe at anyone.

my read is that with the right guidance, implementing the vast amount of the CSS spec for example, could be done easily with some AI assistance, the spec is incredibly well defined. just comparing the layouting and styling in blitz[0] (which does use agents), servo is lacking quite a bit, and the implementation of various features don't follow the spec exactly.

that being said, i entirely respect their decision of course, perhaps they will revisit at a later point in time!

[0]: https://github.com/dioxuslabs/blitz

my read is that with the right guidance, implementing the vast amount of the CSS spec for example, could be done easily with some AI assistance, the spec is incredibly well defined. just comparing the layouting and styling in blitz[0] (which does use agents), servo is lacking quite a bit, and the implementation of various features don't follow the spec exactly.

that being said, i entirely respect their decision of course, perhaps they will revisit at a later point in time!

[0]: https://github.com/dioxuslabs/blitz

Civil, substantive argument with a concrete comparison to Blitz and respect for the project's decision.
nicoburns 2026-11-05 17:589/10first_handinsightfulinformative | root | parent | next [–]

(I'm the maintainer of Blitz)

My experience is that it varies greatly by feature.

Something like border styles, the agent was able to do pretty effectively. Although it still took a few hours iterating on it to get the performance characteristics and edge cases right.

More complex features like hoisting position absolute nodes and other layout features still take days to weeks of iterating to get something usable that isn't so fragile it'll blow up the next time you touch something.

(I'm the maintainer of Blitz)

My experience is that it varies greatly by feature.

Something like border styles, the agent was able to do pretty effectively. Although it still took a few hours iterating on it to get the performance characteristics and edge cases right.

More complex features like hoisting position absolute nodes and other layout features still take days to weeks of iterating to get something usable that isn't so fragile it'll blow up the next time you touch something.

The Blitz maintainer gives first-hand detail on how agent usefulness varies by CSS feature complexity.
fschuett 2026-11-05 21:367/10first_handinformative | root | parent | prev | next [–]

Yes, this was how I did it in Azul[1], which is „reverse engineered from the W3C spec“. But it still took a lot of „agentic debugging“ to get the same visual layout as Chrome[2]. It wasn‘t „easily“ done however and it‘s not yet stable.

[1] https://azul.rs/ui

[2] https://azul.rs/ui/reftest

Yes, this was how I did it in Azul[1], which is „reverse engineered from the W3C spec“. But it still took a lot of „agentic debugging“ to get the same visual layout as Chrome[2]. It wasn‘t „easily“ done however and it‘s not yet stable.

[1] https://azul.rs/ui

[2] https://azul.rs/ui/reftest

First-hand experience implementing a layout engine from the W3C spec with agents, with links, adding nuance to the claim that it's easy.

CSS isn't super well defined actually, at least not compared with HTML or JavaScript.

CSS isn't super well defined actually, at least not compared with HTML or JavaScript.

Terse but genuine disagreement with the parent's claim about the CSS spec.

> For now, we’re taking a cautious approach to these tools due to their effects — both unknown and observed — on project health and maintenance burden. This field is evolving quickly, so we are open to revising this policy at a later date, given proposals for particular tools that mitigate these effects.

seems entirely reasonable reason and approach, and I see no reason to force everyone approach LLM in the same way

> For now, we’re taking a cautious approach to these tools due to their effects — both unknown and observed — on project health and maintenance burden. This field is evolving quickly, so we are open to revising this policy at a later date, given proposals for particular tools that mitigate these effects.

seems entirely reasonable reason and approach, and I see no reason to force everyone approach LLM in the same way

Quotes the project's actual policy and gives a reasoned, civil disagreement.

It’s kind of a wink wink situation. Language like this simply encourages developers to vet code written by AI thoroughly to avoid being caught with obvious slop.

But as maintainers we (I don’t work on servo, but other projects) know that obviously people use AI anyway.

It’s kind of a wink wink situation. Language like this simply encourages developers to vet code written by AI thoroughly to avoid being caught with obvious slop.

But as maintainers we (I don’t work on servo, but other projects) know that obviously people use AI anyway.

A maintainer's blunt, good-faith take on how AI bans work in practice, with no swipe at anyone.

That's good enough and would prove that one put effort into the PR. Which is exactly what that policy actually wants to achieve.

That's good enough and would prove that one put effort into the PR. Which is exactly what that policy actually wants to achieve.

Short but civil point that the policy's real goal is ensuring effort and vetting in PRs.

+1. If you submit code that was drafted by AI but vetted well by a human to not be obvious... Good :)

+1. If you submit code that was drafted by AI but vetted well by a human to not be obvious... Good :)

Despite the '+1', it adds a brief opinion that well-vetted AI-drafted code is fine, with no hostility.

If you believe AI isn't still involved in contributions to Servo, I have a bridge in Brooklyn to sell you.

If you believe AI isn't still involved in contributions to Servo, I have a bridge in Brooklyn to sell you.

Wry but real point that a ban on AI contributions likely doesn't stop AI use; the idiom isn't a personal attack.
wild_pointer 2026-11-05 22:05 | removed0/10jokelow_effort | prev | next [–]

Great progress

Great progress

A two-word pun on the <progress> element, essentially a +1 with no substantive content.

With the advances in AI, I'd expect the Servo project to go a lot faster ...

Do they allow vibe-coded contributions?

With the advances in AI, I'd expect the Servo project to go a lot faster ...

Do they allow vibe-coded contributions?

A genuine question about the project's AI contribution policy, asked in good faith.
simonw 2026-11-05 15:568/10informativeinsightful | parent | next [–]

Currently they do not: https://book.servo.org/policy/ai-usage.html

> Contributions must not include content generated by large language models or other probabilistic tools, including but not limited to Copilot or ChatGPT. This policy covers code, documentation, pull requests, issues, comments, and any other contributions to the Servo project.

> For now, we’re taking a cautious approach to these tools due to their effects — both unknown and observed — on project health and maintenance burden. This field is evolving quickly, so we are open to revising this policy at a later date, given proposals for particular tools that mitigate these effects.

The references to ChatGPT and Copilot suggest it was authored before the Codex and Claude Code revolution. I wonder if they'll revise it at some point soon.

Update: looks like that language was originally added in July 2024: https://github.com/servo/book/commit/5afb80d5b08b259ca359cfe0fd1355a3d4583c61

I found a discussion about changing it in April 2025, but they decided to keep it the same at that point: https://github.com/servo/servo/discussions/36379

Currently they do not: https://book.servo.org/policy/ai-usage.html

> Contributions must not include content generated by large language models or other probabilistic tools, including but not limited to Copilot or ChatGPT. This policy covers code, documentation, pull requests, issues, comments, and any other contributions to the Servo project.

> For now, we’re taking a cautious approach to these tools due to their effects — both unknown and observed — on project health and maintenance burden. This field is evolving quickly, so we are open to revising this policy at a later date, given proposals for particular tools that mitigate these effects.

The references to ChatGPT and Copilot suggest it was authored before the Codex and Claude Code revolution. I wonder if they'll revise it at some point soon.

Update: looks like that language was originally added in July 2024: https://github.com/servo/book/commit/5afb80d5b08b259ca359cfe0fd1355a3d4583c61

I found a discussion about changing it in April 2025, but they decided to keep it the same at that point: https://github.com/servo/servo/discussions/36379

Directly answers the question with the quoted policy, its history and links to the relevant discussion.

Ladybird seems to be embracing vibe coding, so I think there's a great opportunity to compare them. After a couple of months of vibe coding what do you people here think about Ladybird's progress?

Ladybird seems to be embracing vibe coding, so I think there's a great opportunity to compare them. After a couple of months of vibe coding what do you people here think about Ladybird's progress?

A genuine, on-topic question proposing a useful comparison between Ladybird and Servo on AI-assisted development.

You should rather check the tech debt after a few years.

You should rather check the tech debt after a few years.

Terse but real point that vibe coding's cost shows up as long-term tech debt, not early progress.

About ready to switch to Servo as my daily driver on desktop.

Have been using it as the render backend on an experimental tablet OS and its quite capable once you fix the font rendering.

Would gladly upstream contributions but I dont type anymore.

About ready to switch to Servo as my daily driver on desktop.

Have been using it as the render backend on an experimental tablet OS and its quite capable once you fix the font rendering.

Would gladly upstream contributions but I dont type anymore.

First-hand experience using Servo as a render backend, with a wry note tying back to the AI contributions question.

>> With the advances in AI, I'd expect the Servo project to go a lot faster ... >> Do they allow vibe-coded contributions?

With an official automated test suite that they aim to pass, someone could probably set Claude loose on closing out those bugs and feature gaps. Assuming AI can figure out why tests fail (it probably can) I'd give it about a day to finish. Actually maybe a week since it'd be compiling RUST. Would the resulting code be of the same quality? Probably not. Would it be good? Maybe.

>> With the advances in AI, I'd expect the Servo project to go a lot faster ... >> Do they allow vibe-coded contributions?

With an official automated test suite that they aim to pass, someone could probably set Claude loose on closing out those bugs and feature gaps. Assuming AI can figure out why tests fail (it probably can) I'd give it about a day to finish. Actually maybe a week since it'd be compiling RUST. Would the resulting code be of the same quality? Probably not. Would it be good? Maybe.

Speculative but good-faith take on using the official test suite to let AI close Servo's feature gaps, with a light joke about Rust compile times.
nicoburns 2026-11-05 17:556/10first_handinformative | root | parent [–]

IME, agents are generally capable of passing the tests autonomously. But not with code you'd actually ever want to use. Both because of the quality, and because it will have awful performance/memory/security issues.

IME, agents are generally capable of passing the tests autonomously. But not with code you'd actually ever want to use. Both because of the quality, and because it will have awful performance/memory/security issues.

Experience-based, substantive disagreement about agent-written code quality; firm but civil.

I think the sweet spot is not allowing vibe-coded contributions past a certain line count. At least, that's my policy. If you use an LLM to track down some bug that's a few lines to fix; that's fine. But if it's a new feature that needs 100s of lines; just make a feature request and if I agree, I can spin up my own clanker.

I think the sweet spot is not allowing vibe-coded contributions past a certain line count. At least, that's my policy. If you use an LLM to track down some bug that's a few lines to fix; that's fine. But if it's a new feature that needs 100s of lines; just make a feature request and if I agree, I can spin up my own clanker.

Offers a concrete maintainer-style policy for LLM contributions based on change size; the casual 'clanker' is aimed at a tool, not a person.

> Do they allow vibe-coded contributions?

are there serious projects welcoming vibe-coded PRs?

> Do they allow vibe-coded contributions?

are there serious projects welcoming vibe-coded PRs?

A short, genuine question that puts the parent's question in context.

That was my thought as well. You'd imagine a known quantity like a browser should be easy to make now. I know it sounds ridiculous to anyone who hasn't tried the new models, but idk what to tell you. Photoshop used to be impossible to clone, too. I asked Opus 5.5 to add SSGI to an open source game and it did it in an afternoon. I don't know anything about graphics programming. This is nuts.

That was my thought as well. You'd imagine a known quantity like a browser should be easy to make now. I know it sounds ridiculous to anyone who hasn't tried the new models, but idk what to tell you. Photoshop used to be impossible to clone, too. I asked Opus 5.5 to add SSGI to an open source game and it did it in an afternoon. I don't know anything about graphics programming. This is nuts.

Enthusiastic but good-faith opinion backed by a concrete personal experience with AI-assisted graphics work.

Photoshop was never impossible to clone, and people have written browser engines before. The issue was never implementation complexity, but rather the things that are actually hard: going past the 99% of required features, hunting down corner cases, and at the same time ensuring high test coverage and maintainability.

Photoshop was never impossible to clone, and people have written browser engines before. The issue was never implementation complexity, but rather the things that are actually hard: going past the 99% of required features, hunting down corner cases, and at the same time ensuring high test coverage and maintainability.

Firm, substantive disagreement arguing the hard part is the long tail and maintainability, not implementation.

[flagged]

[flagged]

Terse and emotional, but it links a relevant project policy and voices a real opinion with no personal attack.



About | Details | Examples | Prompts | This page on Hacker News | HN Guidelines | Data: HN API

Curious Hacker News is an unofficial, experimental mirror and is not affiliated with, endorsed by, or operated by Hacker News or Y Combinator. Original comments are by their authors on news.ycombinator.com; rewritten text is AI-generated and was not written by the commenter.