I think the point is that automatically-generated documents by LLM is lower quality the manually-generated ones or at least guaranteed lower quality than automatically-generated + manually-reviewed.

Therefor if you are not putting human effort on the document it is low-value.

We have seen this before when big data started to be a thing, tons and tons of reports being auto-produced weekly (or even daily), but even if they contain relevant information they are low-value because no one can take action on so much information.

> Therefor if you are not putting human effort on the document it is low-value.

That's true. The document is low-value.

Asking people to put in personal effort isn't going to change that. If they comply, the document they produce will still be worthless, and you still won't want it.

You're diagnosing a problem unrelated to the problem you actually face.

If you look into large fully-vibecoded projects getting styling changes to work is a nightmare. The problem with agents is using them on large projects without manual review for consistency, guidelines and taste. Doesn't really matter the type of project.

Agents can't look at a large system holistically, guidelines on .md files only go so far.

PS5 supports keyboard and mouse, there is no reason why it can't be a browserbox...

I think the reason is that other consoles were jailbroken because of their browser, so now sony doesnt include it.

Raspberry Compute Module (basically a normal raspberry without built-in I/O) is widely used in the industry at large. What they are not meant to be is the lowest cost per CPU/GPU flops so they are mostly used in high-value-add / low-volume / gen-1 products.

https://www.raspberrypi.com/products/compute-module-5/?varia...

I personally worked on a system with raspberry compute modules 3 and 4, the total system cost was in the ~million dollar range. This was definitely a commercial product with dozens of engineers doing R&D, not a hobby project.

We were looking into smaller systems with lower profit margins (~20k USD) and for those we were considering moving away from raspberry CMs because of cost.

The main advantage of the raspberry CM ecosystem is just how widely popular it is and how cheap and available "dev boards" are (just grab a non-CM raspberry and it is almost the same thing). Most of these types of systems don't really have the I/O that makes testing and developing a lot easier.

Being popular is quite important because firmware issues are notoriously expensive to troubleshoot and fix often requiring the manufacturer help. Said manufacturer does not give a damn if you are a low-volume customer. More popular systems have more information available online and are less likely to have bugs (or at least the bugs are known).

I remember one of our other systems bluetooth module had a weird edgecase bug that caused the module to shutdown after several days of it being powered on. It took multiple engineers >1month of work to basically go "yep nothing we can do about this and manufacturer is not helping"

I know they are being used in Ukranian drones and some police-car systems in some cities (although this was hearsay from a coworker and I don't remember the city). But those are just the examples I heard of.

The ABI stuff is huge, we might be heading (at least in the WASM world) to a place where non-C libraries are not locked to certain dev ecosystems. On top of not having to deal with C linking madness.

Use cases I am more excited about:

1) Replace webhooks in web apps with wasm binaries provided by the customer, but that run in the web app servers.

2) Safer plugin system for professional software (plugins for photoshop, plugins for IDEs, etc)

3) Safer mod system for games and server-side mods that run on the game-maker server.

We had that in the 90's with Java. Why would this approach succeed today?

Why wouldn't it? It's a different technology stack, developed with the benefit of decades of additional experience running hostile code on the web.

You mean like the CLR?

Kind of strange that such experience still allows for WASM to be the target of C and C++ compilers, and there is no bounds checking support inside linear memory regions.

WASM sandbox is miles better than the JVM

WASI is a standard on where to poke holes on the sandbox for your specific use-case

WASM+WASI as a compilation target allows any program written for modern operating systems to work on any WASM runtime

From the introduction section of the Java specification [1]:

"The Java Virtual Machine is the cornerstone of the Java platform. It is the component of the technology responsible for its hardware- and operating system-independence, the small size of its compiled code, and its ability to protect users from malicious programs."

[1] https://docs.oracle.com/javase/specs/jvms/se26/html/jvms-1.h...

There are (or have been) lots of languages using the JVM as a compilation target, whether it is well-suited for this or not. Wikipedia has a partial list: https://en.wikipedia.org/wiki/List_of_JVM_languages

My point is that it isn't well suited for it. Hence WASM.

Check out https://extism.org, it is built for those kinds of use cases. However I think WASI and components could enhance it.

sorry I meant "most excited about", WASI and components should be useful for the usecases I mentioned too.

For example a SaaS services that accepts WASM plugins could provide a WASI that lets the plugin write to a object-store filesystem (like AWS S3) provided by the SaaS owner.

i had this same vision when i created hyper-mcp with modular plugin system via WASM plugins. Too bad, the community moves on from MCP to CLI with coding agent

https://github.com/hyper-mcp-rs/hyper-mcp

I work on a 10+ year old codebase, there are some weeks I barely change any code.

Sometimes it takes hours of discussion and tracking down decision-makers just to figure out what the intended behavior is.

And even when you can easily find the intended behavior, you need to trace the modules that relies on the current behavior, especially if the change is located near the core of the software.

AI fans would say “this is what the spec is for”.

I haven't tried the compiler yet, but I been very skeptical of the automatic memoization features. Both in that sometimes the default strategy to decide when to memoize is not good enough but also the hidden flow to trigger the memoization causing hard to spot performance regressions.

I would be interest to hear how it worked out for you.

It really does work very well in practice. A few things really help:

- Lints [1] that flag code that cannot be (correctly) optimised. Usually this is obscure code that is too smart for its own good. But the compiler leaves it alone and flags it for review, so most things just keep working.

- Lints that flag code that violate the rules of hooks. These rules became more critical to follow: failure to do so may break rendering. But non-compliant code can be easily be excluded from compilation [2], so you do not have to fix everything at once.

- Popular libraries that are not compatible (yet) are flagged and excluded automatically [3].

The compiler is better than manual memoization, because 1) it is hard not to forget memoizations, and 2) the compiler's output memoizes more granularly than manual memoization realistically could.

I have not found performance regressions. Not saying they're not possible; but we haven't encountered them.

We have a very performance-sensitive project that used preact (chosen for performance) via its compatibility layer, that we switched to React + React compiler. Performance is noticeably better than with preact. Whereas previously the React-only version was incredibly slow even with carefully placed memoizations, because they were very hard to get right.

[1]: https://react.dev/learn/react-compiler/installation#eslint-i...

[2]: https://react.dev/learn/react-compiler/incremental-adoption

[3]: https://react.dev/reference/eslint-plugin-react-hooks/lints/...

I was thinking mainly cases like this

const nestedDependency = { a: { b: { c: 'c' } } }

useMemo(() => nestedDependency.a.b.c, [nestedDependency])

vs

useMemo(() => nestedDependency.a.b.c, [nestedDependency.a.b.c])

neither triggers react hook lint warnings, although I guess this is more relevant to useEffect than memoization.

If you’re interested in what a specific piece of code compiles to, it’s worth checking out the online compiler playground [1]

https://playground.react.dev/

Am I the weird one? I usually have 3/4 terminals open at a time and rarely open new ones. Terminal startup speed is a non-issue for me.

The only thing I demand to be fast on my terminal is grep reverse search (ctrl+r) and of course typing a character. But if your terminal can't keep up with your typing speed there is something deeply wrong with it.

I open and close terminals _constantly_, but I'm usually pretty weird in my workflow, so no comment on your first question.

I run a scrolling WM and have settled into a habit of opening terminals when I need them, then closing them right after. I'll open a terminal, git pull, close it. Etc. I also use a terminal that launches cold in 10-20 ms, so it's not like a pay a price for it.

This is actually what I thought this post was about! But then I saw the Ghostty reference, which, in my experience, is not very fast to launch at all. I got it opening new windows quickly by running the main process as a systemd service, but Foot launches way faster without all that fuss, and allows you to go the daemon route if you want it _even_ faster.

EDIT: Just want to clarify, no shade on Ghostty. That project is cross platform and uses the 100% defensible decision to use the full GTK stack on linux. Foot is Linux AND Wayland only, and uses that very restrictive environment to optimize the hell out of startup and general performance.

I constantly open and close terminals too. Maybe I'm doing a quick lazygit check on cwd. Maybe I'm opening up an ephemeral claude/codex session for a couple questions about why a test failed. Or quickly editing a file with vim. Or remembering where I put that file with yazi or fzf. -- I don't even know, but all of it is contingent on it being fast to open a new terminal in cwd.

So much so that I vibe-coded my own terminal emulator for vertical tabs on macOS (using libghostty for the terminals) that is faster and less weird than iTerm.

+1 for Foot, truly a joy to use.

It can affect shell subprocess startup time as well, which, depending on your setup and the tools you use, might be worth optimising for.

I don't remember when I did it, but it looks like I must have gone through this at some point (maybe due to using GNU Make a lot? Or perhaps it was some other tool) - my zsh setup does a bunch of autocomplete setup only in the interactive case, and it seems to help a bit with startup time, at least on macOS:

    % for i in {1..5}; do /usr/bin/time zsh -i -c exit; done # zsh in interactive mode
            0.05 real         0.03 user         0.02 sys
            0.02 real         0.01 user         0.01 sys
            0.02 real         0.01 user         0.00 sys
            0.02 real         0.01 user         0.00 sys
            0.02 real         0.01 user         0.00 sys
    % for i in {1..5}; do /usr/bin/time zsh -c exit; done # zsh in non-interactive mode
            0.01 real         0.00 user         0.01 sys
            0.01 real         0.00 user         0.00 sys
            0.00 real         0.00 user         0.00 sys
            0.00 real         0.00 user         0.00 sys
            0.00 real         0.00 user         0.00 sys

For the interactive case, I don't really mind (within limits - the worst case, on macOS after a reboot, takes several seconds, and that's tedious). I also start new interactive terminal sessions fairly rarely.

Maybe, but notice that almost all of the article, and its followup posted today, is about the speed of starting a shell not of a terminal emulator window. So if you use interactive sub-shells, anything from shelling out of a vi clone or mailx, through :terminal in NeoVIM, to running tmux/screen or script, then the concerns are relevant.

That said, it is almost totally about the Z shell. So you might still qualify as 'weird' in this case on the alternative grounds of not using the Z shell. (-:

Same here. Main terminal w/ tmux, editor terminal with tmux (runs nvim so I can jump to it with a key bind), ssh to remote server with remote tmux, scratchpad term with tmux. I try to reuse the same panes a lot, otherwise open a new tmux window temporarily to do something (C-b c). Basically never open a whole new separate terminal instance on top of those.

> But if your terminal can't keep up with your typing speed there is something deeply wrong with it. For the poor sools that had to work in VDI with radio link...

I open terminal far more often than that. But you should also remember that the startup cost is also paid by some subshells, and any shell scripts you run (the actual cost will vary: which init files are sourced varies between interactive and non-interactive shells as well as login shells and non-login shells, but it won't be zero cost).

I only notice how efficient my terminal is if something dumps a ton of logs to stdout. Sure I can pipe to a file and use vim, but it's convenient not to need to do that. And sometimes I have like 8 things going at once.

I'd say your workflow is pretty typical, from what I am seeing.

Developers that are very heavily invested in terminal and (over) optimize their terminal configuration are a small but very vocal minority.

I do the same, so there's a good chance you're (we're) the weird one