Hacker News new | past | comments | ask | show | jobs | submit | niteshade's comments login

Something that might be useful to know with these devices is that they're quite liable to bricking during updates.

If you do install an update, make sure you reopen its' web portal and confirm the version number is different to what it was before. If it hasn't changed from before, you'll have to wait a while as its still flushing bytes to its flash memory, and if you accidentally trigger an update again here, you'll be left with a brick (speaking from experience).

Depending on the device you bought, you might also be able to flash custom firmware on it: https://github.com/ludwig-v/wireless-carplay-dongle-reverse-...


> Does it hand along an encrypted stream that it can't decode or does it decode/re-encode?

It definitely does decode/re-encode audio streams, as music playback quality suffers quite a bit (both latency and quality).


> Dioxus is similar to modern React Native in architecture. Your rust code is running natively and you can call into JNI and Objective-C freely without a VM in your way.

Given the similarity, would it be feasible to add a compatibility layer to bring in React Native Turbo Modules? (Fabric support would be unlikely I'd imagine)


I don't believe people have used buttons in their cars specifically to control their phones, though.

I do agree that it would be nice to know whether voice control is safer, but unfortunately I can't find any studies that compare voice vs tactile control (all I can find is studies on touch vs tactile)


If the voice control was reliable it would absolutely be safer, it's like telling your passenger to change the AC, except they don't have to move and bother you.

If the voice control is bad and you are never sure if it heard it correctly then it wouldn't be safer.


Not GP, but I recently attempted to migrate a single-node Docker Compose setup to Docker Swarm and ran into the following issues:

- No ability to use secrets as environment variables, and no plans to change this

- Cannot use `network_mode` to specify a service to use for network connections a la Docker Compose

There were a few other minor issues which resulted in ditching Docker Swarm completely and moving to a Nomad + Consul stack instead.


While the way secrets work in Swarm seems weird when compared to Kubernetes, this is usually pretty easily solved by a quick overriding entrypoint in the docker stack file that does essentially this:

    export SOME_VAR=$(cat /run/secrets/some_secret)
    exec /original/entrypoint.sh

Can you explain the second one? I don't get the usecase.


I remember reading (perhaps here on HN) that Apple does weird/nonstandard things to wifi packets to enable Continuity/Handoff features, so it could be related.


We use both the 1Password CLI and 1Password Connect.

The CLI tool is handy for retrieving secrets from your vaults in the CLI, handy for one-off uses like scripts etc.

The Connect server is more suited for infrastructure secrets and allows you to whitelist which vaults are available through it. You can then use secrets exposed from Connect as part of your Docker image build process on CI, for example.


I got some partial/incomplete answers on Fast mode, but changing it to Smart mode immediately improved the quality of the output.

Would be nice if you could +/- the output, just my 2c.


Do you happen to know how to configure this in iTerm? It's the one feature I miss the most from Warp.

EDIT: Found some more info

iTerm calls it "prompt marks": https://arc.net/l/quote/muwfagqi

If you're also using Starship (https://starship.rs/), then you might want to look at this issue: https://gitlab.com/gnachman/iterm2/-/issues/10537#note_15803...


Unclear why this gets its own app instead of being a tab in the News app


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: