Masatoshi Nishiguchi

It is nice to have but after all I did not use it in [my project](https://github.com/mnishiguchi/dypa01/blob/8538f65b96a74d466de18df5ecd042bfb9decb82/lib/dypa01.ex#L23) because I realized I could avoid starting twice for the same port at the...

As a debugging tool `find_pid/1` should be OK, but yeah maybe we can wait until somebody else finds it necessary. I personally decided not to use it in my code...

@fhunleth Is it doable to standardize on `nerves_livebook`'s firmware provision options? https://github.com/livebook-dev/nerves_livebook#firmware-provisioning-options

Ah I see. Thanks for your explanation!

Maybe we can just use this pattern for all the examples, until we have plans for the ConfigProvider thing? https://github.com/nerves-project/nerves_examples/blob/main/hello_phoenix/firmware/config/target.exs#L75-L88 And if it is OK to be the default, maybe...

As I quickly compare `blinky` and `hello_leds`, only remarkable difference is how blinking loop is implemented in the top-level module: - `blinky` - loop and intervals are managed by our...

How about let users specify options to `use Toolshed` like `use Toolshed, :nerves` for nerves specific use? https://github.com/phoenixframework/phoenix/blob/v1.6.10/installer/templates/phx_single/lib/app_name_web.ex#L107-L109

Maybe `exit/0` is Nerves specific as well since people use regular IEx for non-Nerves use cases? https://github.com/elixir-toolshed/toolshed/blob/main/lib/toolshed/misc.ex#L63-L65

I guess next step is to determine what functions to keep as generic core `Toolshed` as opposed to the Nerves-specific. Which functions will surely stay in the core? I think...

It sounds like a great idea to me. It will help us discover modules easily. I have a feeling it will be more maintainable to have per-command modules in this...