The problem with python in some situations is that it will use more CPU cycles, and can be horrendously slow compared to many native alternatives. Just a for example and very rough ( going from memory here . . .) C/C++ for one benchmark I looked at was around 7-8 seconds. ADA2005 roughly 12, nodejs(javascript) roughly 18 seconds, and lots in between but Python was somewhere around 80-90 seconds to complete the same task.
Anyway this is obviously algorithm specific, and I do personally like python syntactically, but in a situation like this . . . yeah I'd most definitely go a different route. On Wed, Oct 2, 2013 at 5:34 PM, Wilfredo Nieves <[email protected]>wrote: > Actually i was thinking about this some more and i believe that an ssh > tunnel would be a very good option. I would go about the configuration > differently though. > > I would add a debug setting that the customer can enable and disable if > they choose to do so. > > For instance if they enable it and then connect network cable then the > device creates the tunnel and allows connection. > > If they disable it the device terminates the connection and closes the > tunnel. This way if they decide they want their device to run wired then > there is no concern about an open port on the network. > > Also a thought would be to have the system monitor the connection and if > after say 1 minute there isn't a response it would automatically disable > debugging or if there is a connection then set a timer for say 5 minutes > this way it gives you time to look at the logs without having to worry > about losing the connection. > > And possibly create a custom reboot script "reboot debug" which reboots > the device in debug mode so that if you have to reboot the device remotely > you don't have to ask the customer to turn debug mode on again. > > A plus about this is that you shouldn't have to worry about trying to > figure out if it is connected to the network wired or wireless. You should > be able to ssh in either way. > > > -WIL > > > > On Wed, Oct 2, 2013 at 4:27 PM, monzie <[email protected]> wrote: > >> Thanks for the links, very helpful. >> >> I take your point about privacy. The use case I am thinking of is this: >> 1. The product is designed to work wirelessly. However I expect some >> customers to have issues connecting to their wireless network because they >> don't know their essid, or type in the wrong passphrase, or their router is >> not configured correctly, etc... >> 2. When the customer exhausts all troubleshooting and still can't >> connect, he can plug in an ethernet cable into the bbk. A valid ethernet >> connection will signal to the bbk to start the ssh connection. >> 3. The software is going to be open source, so technical people like >> yourself can configure it as they wish, for instance disabling the ssh >> debugging option. >> >> Any thoughts on the programming environment for the server? I am leaning >> towards Python. >> >> >> >> On Wednesday, October 2, 2013 2:40:39 PM UTC-4, Wilfredo Nieves wrote: >> >>> You may find these bit of reading interesting. http://** >>> chamibuddhika.wordpress.com/**2012/03/21/ssh-tunnelling-**explained/<http://chamibuddhika.wordpress.com/2012/03/21/ssh-tunnelling-explained/> >>> >>> On Wednesday, October 2, 2013 12:30:33 PM UTC-6, Wilfredo Nieves wrote: >>> >>>> Just my 2 cents. Your idea is absolutely feasible. If you take a look >>>> at minipwner, it creates an ssh tunnel, which I believe is what you want to >>>> accomplish. The only and most unpredictable problem is going to be the end >>>> user. If they are like me nothing goes on my network unless I am absolutely >>>> sure what it is doing and that I am the one in control of it. So the auto >>>> update idea may be your best option. As for the debugging you may also set >>>> it up so that it records the logs and sends them out at set intervals. That >>>> way the customers are sure that there isn't anyone inside their network >>>> when they shouldn't be. >>>> On Oct 2, 2013 6:05 AM, "monzie" <[email protected]> wrote: >>>> >>>>> Problem: >>>>> 1. You release a wildly successful Beagleboneblack (BBK) product. >>>>> The product is one where the customer connects the BBK to the Internet >>>>> thru >>>>> the router on their home LAN (ie. the BBK is behind a router and does NOT >>>>> have a public ip address) >>>>> 2. After product release you find a major bug in your software, and >>>>> the customer support calls start piling up because of this bug. >>>>> 3. You find a fix but because most of your customers are not >>>>> technical, it is difficult for them to update the software. Your >>>>> customers >>>>> start ranting about how terrible your brainchild is, you start losing >>>>> hair, >>>>> gaining weight, and wish you had gone into accounting instead of >>>>> engineering. >>>>> 4. SSH'ing into each BBK would be great because then the fix could be >>>>> easily applied. >>>>> >>>>> I'm thinking of writing a software package that provides a solution to >>>>> this. In a nutshell: >>>>> >>>>> 1. A web server (SERVER1) is built and connected to the internet. >>>>> BBK Side: >>>>> >>>>> 2. Each product is given a unique ID (UNIQUE_ID) before being shipped. >>>>> 3. A daemon process installed on the BBK sends an HTTP request for a >>>>> file named UNIQUE_ID on SERVER1. The request is repeated periodically >>>>> (say >>>>> once every few seconds). >>>>> 4. If the request is successful then the BBK sets up an SSH >>>>> connection to SERVER1. >>>>> >>>>> Tech Support Side: >>>>> 5. Tech support has a list of the customers and their unique IDs. >>>>> 6. When a customer calls in , Tech support creates and SSH connection >>>>> to SERVER1. THen creates the file UNIQUE_ID on the server. >>>>> 7. Tech support can now SSH into the customer's BBK. >>>>> >>>>> I am a little unclear still on SSH port forwarding but I am pretty >>>>> sure the SSH connections thru SERVER1 should be relatively easy to set up. >>>>> >>>>> Thoughts, comments, opinions? >>>>> Is there something out there already that is simple to use? >>>>> >>>>> Anybody want to work with me on this? >>>>> >>>>> Monzie >>>>> >>>>> -- >>>>> For more options, visit http://beagleboard.org/discuss >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "BeagleBoard" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to beagleboard...@**googlegroups.com. >>>>> >>>>> For more options, visit >>>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>>>> . >>>>> >>>> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
