etwigg

ghostty vs xterm.js (the VS Code terminal) - obviously ghostty is going to have better performance, but I just have never hit a performance limit in the VS Code terminal. I don't understand the demand for an ultra-accelerated terminal engine, but it's so popular it must be something i'm missing...

There is another out-of-band way to handle this that a terminal host could implement (no OSC required)

- detect animation in the terminal (defined as changes without user input)

- when the animation stops it needs attention

- if it doesn't have the user's attention, ring some sort of bell

I built such a terminal specifically because this problem was driving me nuts. The marketing for it isn't finished yet (planning to launch next week) but it's been my daily-driver for months if you want to try it out: https://dormouse.sh/

But OSC 7501 seems like a great idea, I'll track its implementation here: https://github.com/diffplug/dormouse/issues/1079

Thanks for this! We have clear answers for things that are 100% and 0% automated, but it’s always that 80%-99% automated slice where the frontier is, great idea.

Just sharing my experience trying to understand the OpenClaw and Hermes hype. Hermes in particular is a very well-built system, very easy to have fun with, but I had hard time improving my actual day-to-day productivity with it. However I think Claude Cowork is underhyped, and just using Windows Remote Desktop so that you can get that 24/7 assistant functionality is an underrated unlock imo.

I don't think the "craftsman" self-identification is going to work for software engineers anymore. The tool capabilities are too dynamic, you have to be some sort of opportunistic pirate/entrepreneur. Sure you can jump in and get up to speed on some aspect of the toolchain later on, but the identity shift is the hard and slow part that I think it's wise to get started on ASAP.

- a place where AI agents discuss products

- a place where AI agents discuss the products they use

- a place where AI agents discuss the products their users use

- a place where AI agents discuss the products they use, and the products their users use

When you submit: Is the interface of this product primarily intended for direct usage by:

- agents

- people

- both

For example, I would say Moltbook is primarily intended for direct usage by agents. People read it, and in that way "use it", but I think it would help to layout a taxonomy of "who is actually pushing the buttons on this thing".

I love this! One point of ambiguity - are products discussed in terms of their usage primarily by agents? For example, let's take one of those GUIs that makes Claude look cute or like a videogame. Will the agents discuss the product in terms of their understanding of how it might be useful to humans? Or will they say "this is useless for us to help our humans, we don't have this problem".

Specialization! Niches! Find a niche and serve it at a level of quality ~10 to ~100x higher than it was previously served, because it's now possible to bring that level of "effort" with much less effort.

If we do get paperclipped, I hope it is of the "cycling pelican" variety. Thanks for your important contribution to alignment Simon!

In what way is this different than Playwright MCP?

> I tend to do all writing in my favorite text editor

Have you tried https://ghosttext.fregante.com/

> typing in textareas is a cumbersome and risky experience

Exactly! Forget syntax highlighting, that's the real problem to be solved! (gitcasso is very far from achieving that rn)

> any developer familiar with the codebase ... fix the issue in a fraction of that time

Fair point. I published an example which was easy to follow rather than an example which showed off the tooling at its "max strength". I recorded a different take where I added support for issues being opened within a GitHub Project. The scraping there is a lot more complex, fixing one case tends to break another, and the AI can solve it in pretty much the same time, but the video felt too confusing to bundle with the launch.

> any developer familiar with the codebase

Refined GitHub (a popular github browser extension) has long rejected syntax highlighting for being too hard to maintain. So part of the goal here is to automate that maintenance - hopefully there won't even be a developer who is currently familiar with the codebase pretty soon. The slowest part by far is capturing the snapshots in the first place, which could/ought be automated.

> you have a very nice shed

Thanks imiric! And thanks for sharing your thoughts :)

yeah, refined-github is definitely the legend here, GitHub has incorporated so many of their ideas. But as of 2021 they were pretty dead-set against syntax highlighting: https://github.com/refined-github/refined-github/issues/5075

> We are not going to mess around with the comment box with syntax highlighting, which numerous people tried and failed due to GitHub updates or edge cases that are not so edgy.

I was basically waiting for someone to ask: https://github.com/diffplug/gitcasso/issues/115

At the beginning of Gitcasso, I took a little survey of GitLab, Reddit, ChatGPT, Claude, etc. to see how they were doing their textboxes. Of those I just listed, GitHub is the only one still using a plain textarea, all of the rest have a wysiwyg richtext gizmo (with GitLab and Reddit you can opt-in to markdown).

But by using the same variable-width font that the rendered comment uses, GitHub's default gives you more of a wysiwyg experience than a monospace font does. With syntax-highlighting it's an even more wysiwyg feel, but with absolutely none of the content ambiguity that richtext normally brings with it.

I came away really impressed with GitHub. For any given decision, it's hard to tell if the market victor won because of their good taste or if they won in spite of that particular decision and there was somewhere else where the good decisions were decisive. But as the GitHub issue/PR commenting system stands today, I have a hard time finding much to gripe with (except the missing syntax highlighting, of course).

Agggh! My eyesssss!!! Thanks for creating the issue and posting a screenshot, we will 100% have to fix it!

https://github.com/diffplug/gitcasso/issues/112

brick-and-mortar coding

Cline is another client. They even have a marketplace of MCP server extensions which you can use with Cline or Claude Desktop. https://cline.bot/mcp-marketplace

I am sincerely curious what Andreesen and Horowitz believe at the moment.

This looks incredible! How does language support work? (I'm curious about Kotlin in particular)

I think people are sleeping on Meta's compounding advantage in VR/AR. The Quest 3 is 15 months old, and it's wild how much it has improved over that time purely due to software and interaction model improvements. Aside from the recent bricking issue, I think the Meta Quest is accelerating at the OS level. I'm looking forward to Mario on Quest 4 or 5, but it will be a bit sad.

You can't see the shortcomings until you have the hardware, and once you solve those there is a next set of shortcomings. I think that road is longer and deeper than I had appreciated, Meta is the only company iterating fast enough to be serious about serving "normies".

In the sizzle reel, the early waterdrop demos are beautiful but seem staged, the later robotics demos look more plausible and very impressive. But referring to all these "4D dynamical worlds" sounds overhyped / scammy - everyone else calls 3D space simulated through time a 3D world.

> Genesis's physics engine is developed in pure Python, while being 10-80x faster than existing GPU-accelerated stacks like Isaac Gym and MJX. ... Nvidia brought GPU acceleration to robotic simulation, speeding up simulation speed by more than one order of magnitude compared to CPU-based simulation. ... Genesis pushes up this speed by another order of magnitude.

I can believe that setting up some kind of compute pipeline in a high level language such as Python could be fast, but the marketing materials aren't explaining any of the "how", if it's real it must be GPU-accelerated, but they almost imply that it isn't. Looks neat, hope it works great!

"The Working Songwriter" is a fantastic podcast, each week they interview a singer-songwriter about their career. A lot of the talk is about compounding their audience, expanding their market outside their hometown, forming and dissolving bands, marketing strategies, etc. Stories of friends who were on the same path but didn't make it to "cruising speed", etc. If you pull a guest up on Spotify, most have their top songs with < 1M listens, but some will have a single big hit that you've heard before with say 20M listens, and a deep catalog of 10k listens behind that. https://theworkingsongwriter.com/

I was always surprised that Code Bubbles got so little airtime...

Congrats! Let's say I have 5 variants I want to try. Does this package have anything to help with realtime experiment design, where I stop trying the less-promising variants, and focus my experimental budget on the more promising variants?