LabVIEW
Why is SSH not free
Solved!
I use an open source .NET library for my SSH. I just put a wrapper class around it to handle the terminal operations I need.
@Mark_Yedinak wrote:
@crossrulz wrote:
I use an open source .NET library for my SSH. I just put a wrapper class around it to handle the terminal operations I need.
What is your solution for a RT target?
I have not had that need. But with the RT Linux, I'm sure there is some library out there you can use, if it isn't already built into the OS.
The problem is that all these Python libraries are written by the community. There isn’t a single company that develops Python and associated libraries. NI, even if they wanted, could never develop all the libraries for LabVIEW that users might want and being a for profit company has no means to do that for free either. The share holders would very quickly stop that as it cuts into the dividends for them.
Sure you have 3rd party libraries in LabVIEW too. Some are free and others are not. I have been involved in both as contributor to OpenG and maintainer of Lua for LabVIEW and others. Both experiences are not exactly perfect. As OpenG developer it often felt pretty one sided, with feedback, not always very friendly, only when it didn’t work somehow, but very seldom with actual debugging effort from the user. The mentality is often one of entitlement to these libraries and the according right to feel upset if it doesn’t work the way the user wants, even if that expectation is technically unfeasable.
For paid for libraries there is pretty much no market except in some niche areas. It’s basically not possible to earn enough money with it to pay for the effort. All these libraries are usually based on work that was at some point developed for some project. We have probably several thousand such libraries internally. Some couldn’t even be productized (or even reused for other client projects) since the client paid for the full development costs and therefore basically owns the source code. Others could, but the step from a library for internal use in projects that works but with caveats and special things you just have to know to never try to do, to a library that can be passed to users with the experience ranging from beginners to experts is huge! Polishing the API, filling in functional gaps that were not needed in the original project, testing every possible use case, writing documentation and user manual can easily take up several times the amount of time needed to develop the initial library. And all that work is expected by users like you to be given to you for free, noppes, nada!
The OpenG community used to be fairly active in the past but in essence it consisted of one guy (Jim Kring) driving it, and about two handful developers spending many free hours in developing and improving libraries. Jim Kring moved on founding his own company and had other priorities then and so did most developers. We all need to have a job that pays the bills and at some point family obligations too that make spending whole nights trying to get such stuff to work simply for the sake of it, much less important.
And yes there wasn’t really a next generation that felt enough for it to pick up the baton and keep it alive. Complaining that such libraries don’t exist for free is easy, developing them and providing them for free to the community however is a very different thing. Just saying!
@crossrulz wrote:
I have not had that need. But with the RT Linux, I'm sure there is some library out there you can use, if it isn't already built into the OS.
Of course there is. It's called libssh2 (who could have guessed and the 2 indicates that it is the newer implementation). NI doesn't install it with their kernel nor do they have their own libnissh(2) module to install on a target and it doesn't seem to be available in the NI opkg repository.
However here is a CMake based build file to compile the libssh2 sources for use with the NI Linux RT controllers.
And here is the LabVIEW frontend to the library and this is the source code for the LabVIEW interface shared library with a CMake superbuild for the NI Linux RT controllers for it
For 50'000 Euro I would definitely hack it myself. 
Wait I did at some point something along that line. It was a fully non-blocking (reentrant) TCP VI library using an OpenSSL library as backend and at the same time also supporting IPv6 (on platforms that support it, all RT controllers at that point didn't). Feedback was more or less non-existent so I abandoned it after a while as the effort to debug and improve it got simply to much.
But there exists another library here. Either you didn't see this or really needed an awful lots of stations with this library to get to 50000 bucks and if you had gotten so many seats, I'm sure Shaun would have been happy to cut a deal with you.
The nice thing about my library was that unlike your .Net solution, this would have happily worked on NI RT controllers too as well as LabVIEW for MacOSX and Linux, but not sure if you care about them.
But to get back to your SSH problem. The links I provided are neither expensive nor closed source. The worst thing you may have to do is recompiling the shared library on the target for some exotic cases so all your points about expensive 3rd party solutions and having to go through them for any change in the library is moot.
@rolfk wrote:
For 50'000 Euro I would definitely hack it myself.
Wait I did at some point something along that line. It was a fully non-blocking (reentrant) TCP VI library using an OpenSSL library as backend and at the same time also supporting IPv6 (on platforms that support it, all RT controllers at that point didn't). Feedback was more or less non-existent so I abandoned it after a while as the effort to debug and improve it got simply to much.
But there exists another library here. Either you didn't see this or really needed an awful lots of stations with this library to get to 50000 bucks and if you had gotten so many seats, I'm sure Shaun would have been happy to cut a deal with you.
The nice thing about my library was that unlike your .Net solution, this would have happily worked on NI RT controllers too as well as LabVIEW for MacOSX and Linux, but not sure if you care about them.
But to get back to your SSH problem. The links I provided are neither expensive nor closed source. The worst thing you may have to do is recompiling the shared library on the target for some exotic cases so all your points about expensive 3rd party solutions and having to go through them for any change in the library is moot.
Hi Ralph,
I was not aware of any other solutions, though I looked extensively and asked several times here and elsewhere over the course of a year. As I already solved the issue in a satisfactory way I hope the solution you mention can be of help to others.
From the topic I referred to it is apparent that my grief lies with NI, not the community.
The mechanism for buying extensions through libraries can be restrictive. The examples I encountered were implemented in that (restrictive) way and with that were totally unusable for the purpose I needed. The included documentation never gave other indication than living with the restrictions, high cost (unless discounted to perhaps $1000 - $2000) and uncertain future support.
As I mentioned I'm happy that a free (and relatively easy) tool was able to do the task.
