I used to use VoiceInk, but I found Spokenly [0] to be easier to use for post-processing the output, and more stable overall (local version with Parakeet or whisper is free).

[0]: https://spokenly.app/

This reminds me of go cli being pretty anal about this: you type `go fmt —help`, and it recognises you want help, but instead of showing the help, it tells you to use the totally non-standard cli pattern of `go help fmt` instead.

Reminds me of the rage of doing `man gnutool` and getting something complaining about how GNU info was where to go.

c-x alt-meta-shift eat-flaming-death

This is a great point, and it's actually something I really enjoy that the JVM and Java do nowadays by namespacing the new experimental APIs that you test from release to release and then it's stabilized like that, and becomes broadly available.

Some audio/video receivers still use telnet to control them over the network, like those still sold by Denon/Marantz [0].

[0]: https://assets.denon.com/documentmaster/us/heos_cli_protocol...

Lutron used it for their integrations platform up til very recently. It was extremely convenient, being able to write little scripts that do things like turn off all the lights

Some of KUKA's controllers still use telnet in their startup sequence.

A large industrial robot running an insecure protocol - what could possibly go wrong?

Thankfully all factory networks are airgapped from the internet, so it's a non-issue!

Right?

Their previous security updates feature was mostly unused.

I suppose it’s not really working, or is the product of a team and no other internal team actually use it.

It's more the former. I'm assuming though that Background Security updates are basically the same thing as "Rapid Security Responses" was, which on the Mac I can recall being used once, 13.3.1(a) released the same day as 13.4 as an RSR.

Basically, the amount of stuff Apple can realistically change on the fly without restiching an entirely new system volume snapshot into place is quite small, so unless the stars align it can't be used.

See: https://khronokernel.com/macos/2023/04/18/RSR.html

And then clojure enters: let’s keep few data structures but with tons of method.

So things stay as maps or arrays all the way through.

Nice, but it would have been better with more pictures to match the description IMO

It’s nice, but the previous version wasn’t actually that great compared to Parakeet for example.

We need better independent comparison to see how it performs against the latest Qwen3-ASR, and so on.

I can no longer take at face value the cherry picked comparisons of the companies showing off their new models.

For now, NVIDIA Parakeet v3 is the best for my use case, and runs very fast on my laptop or my phone.

There is https://huggingface.co/spaces/hf-audio/open_asr_leaderboard but it hasn't been updated for half a year.

I like Parakeet as well and use it via Handy on Mac. What app are you using on your phone?

Spokenly has it on Mac and iOS, in both cases for free when using parakeet

Yep, I think a watcher is better suited [0] to trigger on file changes.

I personally can't stand my git commit command to be slow or to fail.

[0]: such as https://github.com/watchexec/watchexec

I prefer to configure my IDE to apply precisely the same linting and formatting rules as used for commits and in CI. Save a file, see the results, nothing changes between save, commit, stage, push, PR, merge.

> I personally can't stand my git commit command to be slow or to fail.

I feel the same way but you can have hooks run on pre-push instead of pre-commit. This way you can freely make your commits in peace and then do your cleanup once afterwards, at push time.

To myself: sometimes I think the background process should be committing for me automatically each time a new working set exists, and I should only rebase and squash before pushing.

That’s reversing the flow of control, but might be workable!

jj already pretty much does that with the oplog. A consistent way of making new snapshots in the background would be nice though. (Currently you have to run a jj command — any jj command — to capture the working directory.)

I don't think you have to, you can run the integrated watcher, no?

You can configure watchman to do it. `fsmonitor.watchman.register-snapshot-trigger = true`

I don't recommend it, though, at least not on large repositories. Too much opportunity to collide with command-line jj write operations.

> I personally can't stand my git commit (...) or to fail.

But that's the whole point of locally checking the code, no? Would you prefer to commit broken things, fix them and then rebase and squash each time?

That website it gold!