February-20th-2018, 07:07 AM
I didn't work with the NetPi very much so far, but I like to double Vince's request, as even with the few experiments I did, I can agree that, as a developer, one would really like to have access to the host system as it could possibly significantly lower debugging time.
Beside the proposed opening of the sources, maybe another approach could be to provide "dev-firmware" that allows SSH access. Having that, we could at least check out the system configuration. E.g. by being able to inspect the Docker configuration, it would become obvious why certain "features" are not available on the NetPi.
Surely, this would bear the risk that such a firmware will finally be put into the field - which would be bad, security wise. Not sure how you could circumvent that... Maybe such a firmware could be made only available to "registered developers/partners" who agreed to ensure not to distribute such a firmware into the field. Moreover, each downloaded firmware would be "customized" to contain a fingerprint of that user. With something like that, you'd at least be able to pin-point to the misbehaving developer. Another approach could be to automatically shutdown such a dev-firmware after, let's say, 3 days. Although, I'm not sure how to do this in a way that it can't be hacked...
=> These are just brainstorming ideas...
Beside the proposed opening of the sources, maybe another approach could be to provide "dev-firmware" that allows SSH access. Having that, we could at least check out the system configuration. E.g. by being able to inspect the Docker configuration, it would become obvious why certain "features" are not available on the NetPi.
Surely, this would bear the risk that such a firmware will finally be put into the field - which would be bad, security wise. Not sure how you could circumvent that... Maybe such a firmware could be made only available to "registered developers/partners" who agreed to ensure not to distribute such a firmware into the field. Moreover, each downloaded firmware would be "customized" to contain a fingerprint of that user. With something like that, you'd at least be able to pin-point to the misbehaving developer. Another approach could be to automatically shutdown such a dev-firmware after, let's say, 3 days. Although, I'm not sure how to do this in a way that it can't be hacked...
=> These are just brainstorming ideas...
