![]() ![]() That is where the main effort is located. And setting up a different license server infrastructure is most likely even more work. Tieing it into the existing license server infrastructure however is a major effort. Just hacking a small license manager into the executable that does some verification is not that a big part. The Windows version uses the FlexLM license manager but the important thing is the server binding to their license server(s). The license manager included in the executable is only a small part of the work. I'm going to try bypassing the NI Package Manager by copying an already-completed installation from a VM into Wine. I already filled out the Site Feedback form reporting it as a bug, but I guess if nothing else it'll make them aware that the message is misleading. I guess it wouldn't necessarily be worth the effort for a free product though-hell, I wasn't expecting them to ever give away LabVIEW for noncommercial hobbyist use at all, as much as I hoped they would. I wonder though, do they really need anything elaborate for a license manager? I doubt it would be difficult to put something together from scratch. Though I swear I remember using a trial version on my Mac at some point back when I used one. Net prior to at least 4.6.2.Īh right, I forgot about that. Net Core specification but rather the full. Net functionality and definitely not developed towards the. That NI package manager won't work is not surprising, it is most likely HEAVILY relaying on. Current Wine is a lot better but so are the requirements of current LabVIEW in terms of the Win32 API that it exercises. It was a rough ride and far from perfect even with the Wine patches applied but it sort of worked. I made LabVIEW run on Wine way back with LabVIEW 5.0 or so, also providing some patches to the Wine project along the lines. ![]() That's supposedly also the main reason holding back a release of the Community editions on non-Windows platforms. ![]() So only the patches are downloadable without a valid SSP subscription, since they are only incremental installers that add to an existing full install, usually replacing some files. This means that if you could download the full installer just like that, there would be no way for NI to enforce anyone to have a valid license when using it. LabVIEW on non-Windows platforms has no license manager built in. So if I were to download a different edition for Linux and crack it to work without a license, while I'm aware that would be against the EULA, would I really be violating the spirit of the EULA as long as I don't use it for anything I wouldn't be allowed to use Community Edition for? It would only be as a necessary part of a workaround for something they'd presumably allow if it were technically feasible, so maybe NI wouldn't care. But it does make me wonder about something: IIRC the only reason they don't have it available for Linux is because of technical issues with the license manager, rather than any desire to force people to use Windows. Still though, it doesn't have Community Edition. My guess is there's a bug where it thinks "2020 Patch" is the latest, even though it requires "2020" in order to install. It seems to think that LabVIEW 2020 isn't the latest version, saying an SSP subscription is required to download it. I haven't tried WINE, but there is a Linux installer for non-community versions of LabVIEW: (It uses RPM packages)
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |