Kissaki

After working on my weird shooter game for 5 years, I realized I'm never going to be finishing this project. In this video I explain why I've decided to quit my game and what is next.

From the README:

What is KORE?

KORE is a self-hosting programming language that combines the best ideas from multiple paradigms:

Example

// Define a function with effect tracking
fn factorial(n: Int) -> Int with Pure:
    match n:
        0 => 1
        _ => n * factorial(n - 1)

// Actors for concurrency
actor Counter:
    var count: Int = 0

    on Increment(n: Int):
        count = count + n

    on GetCount -> Int:
        return count

fn main():
    let result = factorial(5)
    println("5! = " + str(result))

By streaming CSS updates/appends through an open HTTP connection

Girard's insight was that communities resolve internal conflict through scapegoating: the selection of a victim to bear collective guilt, whose expulsion or destruction restores social cohesion. The scapegoat need not be guilty of the crime attributed to it; it need only be acceptable as a target.

Some dangerous individuals, however, institutionalize such ritualistic practices into what I call Casus Belli Engineering: the use of perceived failure as pretext to replace established systems with one's preferred worldview. The broken feature is the crisis that demands resolution. The foundation becomes the scapegoat, selected not for its actual guilt but for its vulnerability and the convenience of its replacement. And in most cases, this unfolds organically, driven by genuine belief in the narrative.

The danger is not the scapegoating itself; humans will scapegoat. The danger lies in those who have learned to trigger the mechanism strategically, who can reliably convert any failure into an opportunity to destroy what exists and build what they prefer.

The linked article title is “Casus Belli Engineering: The Sacrificial Architecture”, which I didn't find particularly descriptive. I used the second headline, “The Scapegoat Mechanism”. It doesn't include the architecture or strategy aspects, but serves well as a descriptor and entry point in my eyes.

There exists a peculiar amnesia in software engineering regarding XML. Mention it in most circles and you will receive knowing smiles, dismissive waves, the sort of patronizing acknowledgment reserved for technologies deemed passé. "Oh, XML," they say, as if the very syllables carry the weight of obsolescence. "We use JSON now. Much cleaner."

GSoC 2026 Project Ideas

In our previous post “Reinventing how .NET Builds and Ships”, Matt covered our recent overhaul of .NET’s building and shipping processes. A key part of this multi-year effort, which we called Unified Build, is the introduction of the Virtual Monolithic Repository (VMR) that aggregates all the source code and infrastructure needed to build the .NET SDK. This article focuses on the monorepo itself: how it was created and the technical details of the two-way synchronization that keeps it alive.

Users are not allowed to create Issues directly in this repository - we ask that you create a Discussion first.

Unlike some other projects, Ghostty does not use the issue tracker for discussion or feature requests. Instead, we use GitHub discussions for that. Once a discussion reaches a point where a well-understood, actionable item is identified, it is moved to the issue tracker. This pattern makes it easier for maintainers or contributors to find issues to work on since every issue is ready to be worked on.

This approach is based on years of experience maintaining open source projects and observing that 80-90% of what users think are bugs are either misunderstandings, environmental problems, or configuration errors by the users themselves. For what's left, the majority are often feature requests (unimplemented features) and not bugs (malfunctioning features). Of the features requests, almost all are underspecified and require more guidance by a maintainer to be worked on.

Any Discussion which clearly identifies a problem in Ghostty and can be confirmed or reproduced will be converted to an Issue by a maintainer, so as a user finding a valid problem you don't do any extra work anyway. Thank you.

On January 1, 2026, GitHub will reduce the price of GitHub-hosted runners by up to 39% depending on the machine type used. The free usage minute quotas will remain the same.

On March 1, 2026, GitHub will introduce a new $0.002 per minute GitHub Actions cloud platform charge that will apply to self-hosted runner usage. Any usage subject to this charge will count toward the minutes included in your plan, as explained in our GitHub Actions billing documentation.

Runner usage in public repositories will remain free. There will be no changes in price structure for GitHub Enterprise Server customers.

We are increasing our investment into our self-hosted experience to ensure that we can provide autoscaling for scenarios beyond just Linux containers.

Historically, self-hosted runner customers were able to leverage much of GitHub Actions’ infrastructure and services at no cost.