easeout

I briefly emulated it with UTM (QEMU) on macOS; the host was an M1 series chip. This story is the first indication that I might run Haiku on that machine's bare metal someday.

It's a delight to use, if a little esoteric at first. After the experiment phase, the software ecosystem comes up fairly limited. But I recommend visiting.

Here are some more impressions: https://kconner.com/2025/03/09/haiku-os-study-path.html

Then why make an app instead of a website?

Because they're the main prompt injection vector, I think you'd want to distinguish tool results from user messages. By the time you go that far, you need colors for those two, plus system messages, plus thinking/responses. I have to think it's been tried and it just cost too much capability but it may be the best opportunity to improve at some point.

Gotta meet your audience where they are. As a Mobile Safari user, the foremost way I feel my use of the web is crippled is that pages assume a bigger screen or are just poorly arranged.

This of all web pages ought to be easy to read on an iPhone screen, but the way it's constructed prevents it. You can't zoom the whole page out to see the entire table width because the table is in a scrolling frame and wider than its box. You can only scroll the nested frame sideways to see how row labels relate to iPhone cells. If you give up and use landscape, it still scrolls vertically in its frame. You have to aim for the margin or else you'll scroll just an inch and be halted because you caught the table.

Because it's critical that the web be as free as it is:

• It's natural that some pages turn out like this

• So it's natural the web is a little bit shitty all over

• So it's natural the demand for richer web features is low

Just having watched the video, the session setup, close, and launch seem tied to the idea of a single window per app. Is that right? What kinds of workflows is this explicitly meant vs. not meant to support?

The way a user switches window sets with backtick and app windows within them with tab is inverted from the usual major and minor shortcuts. Normally you switch apps with tab and windows within them with backtick, or in the case of stage manager, you switch window sets with tab and windows within them with backtick. As a default I think the keys make less sense than they could.

> …requires an account holder to indicate the birth date, age, or both, of the user of that device…

The way I read that, you just have to ask for an indication of age. Like when I'm not logged in to Steam and I want to look at a game with blood, it asks for a birth year and I pretend to be 109. That's not exactly "age verification." Am I missing something?

Anybody measure employees pressured by KPIs for a baseline?

> A problem repeatedly occurred on "https://factory.strongdm.ai/".

Why make a desktop windowing system app, for a user group who runs a bunch of simultaneous terminal sessions with tear-off tabs or tmux panels, and then force everything into one window that can only display a single session at a time?

The Open button and then codex resume --last is good, but it's a waste and The Wrong Abstraction not to make instantiable conversation windows from the get-go.

The main problem I have with the language is compile times. Rust is good at many things, but not that.

Xcode is optional, though its primacy has meant less adoption of Swift's first party LSP and VS Code extension.

I wrote this a long time ago, but I think the metaphor was about generative AI applications vs. traditional software applications, not about AI coding agents vs. writing code yourself.

Hi, that's my website and my wisecrack article. It was a while ago, but I think the metaphor was that a train is traditional deterministic-ish software, whose behavior is quite regular and predictable, compared to something generative which is much less predictable.

Heh, if repression did not exist, it would be necessary to invent it?

Yeah that was pretty weird. Minimizing harm means both leaving people alone and not denying yourself random pleasant feelings.

Native performance doesn't earn that much user goodwill without native layout and behavior. You can't make a single design for many platforms and please everyone who chose each platform for what it is. Unless perhaps you are Snap and having a _unique_ UI is part of the appeal for your young-leaning audience.

Baby don't hurt me

People who have them love them. I think there's truth to the idea that iPhone Air is a stepping stone to a foldable with thin halves.

Shell commands and files on disk are the classic narrow waist, and this type of tool, exemplified by Claude Code, locates a coding agent down in that ecosystem.

Why shouldn't you be able to use the abilities of this tool as a batch command, connected with all your other basic tools, in addition to interactive sessions?

Cursor's chat being locked in an IDE sidebar has felt like driving with a trailer attached. For some tasks the editor is secondary or unnecessary, and as a papered-over VS Code fork, Cursor has a lot of warts that you just had to accept. Now you can just use your favorite editor.

Companies make apps but want to be platforms, so they try to put everything in one app and help you forget about everything else. VS Code and Figma, for example, make their own extension ecosystems rather than connecting outward, because it makes them platforms-as-apps and harder to leave. But a desktop task workflow spans many apps and windows. You compose it yourself to your needs. We are computer users more than app users.

To me as a computer user, a tool that's compact and has compatible outward extension points feels good.

Two operators? Where I live it's zero

This is in keeping with the overall problem Figma presents to organizations. If you create a place to design software in isolation while eagerly forgetting about real world software concerns, and you bump the seat license cost until only a few can have them, you're going to make early mistakes due to deliberately limited perspective, for which you'll pay later when they're more expensive to correct. Dev mode isn't there to bring in more perspective. It's there to keep the silos separate, for "handoff" rather than really working on it together.

Separately: It doesn't matter whether you downloaded the local app, it's thoroughly a SaaS product, and working offline is the exception to its rule.

It goes to show that the common system of employment, in which we spend our time toward the purposes and meanings of others, tends to provide no purpose or meaning for ourselves.

You must mean "APFS volume".

It is a slow to compile language, and that's my primary complaint about it. If you have basic errors they come back very fast, and code that compiles often works the first time, but still. If not for this quality it would be my clear favorite language.

I would love to see what Instruments, the memory debugger, sanitizers, runtime issues, and Xcode's more elaborate kinds of breakpoints can do for a headless service. I've only ever tried them for GUI apps but of course these tools are also made for the daemons that comprise macOS.

My guess at the upshot: Some domains, like math, are general but have outsized effective vocabularies like all possible numbers, which makes them more expensive to train by the same method that works for domains of regular-sized vocabularies. If you train for reasoning steps in such a problem domain, you can reinforce the comparatively few general terms of the vocabulary like "add", "inverse", "solve". And that leaves the arithmetic of number combinations separate from particular problems because you're not emphasizing one-shot answers. You can train N reasoning cases + M arithmetic cases instead of N*M whole math problems. So you have to use more inference power but you can get better answers for less training.

Theory aside, I would think a good application-side method is to use this general reasoning process to structure a final expression and then pass that through a traditional evaluator. Then the reasoning and training thereof need only go as far as symbol manipulation. This is something like Wolfram Alpha, if its NLP handed off to the evaluator much later in the process.

Here's a paper your idea reminds me of. https://arxiv.org/abs/2501.19201

It's also so not far from Meta's large concept model idea.

Swift Concurrency as a feature set includes async/await and async for, which solve a large part of Combine's same problem with better safety and less setup/teardown. These days Combine is still useful, specifically for multiple observers and several cases of adapting to older event publishing sources.

Kibana was discontinued, maybe you're thinking of that one?

Check out Vapor