MolodenskyHey Wyatt,
I've been building a docker image containing our app (which uses TA/TF) and noticed that each new container/instance has the full trial period available. It seems like UseTrial(TA_SYSTEM) / UseTrial(TA_DISALLOW_VM) don't account for this case, which kind of makes sense, but which on the other hand is also bad for people who try to sell their app.
Do you have any suggestion how one could disallow trials within containers?
I'm a little bit surprised that I didn't find any other posts on this topic in the forum. Hope I'm not missing anything that is obvious to everyone else 🤔
Best regards - Dan
Hey Dan,
Do you have any suggestion how one could disallow trials within containers?
It's coming in TurboActivate 4.0 with a simple flag TA_DISALLOW_SANDBOX. So, you'll be able to pass that to UseTrial() like this:
HRESULT hr = TA_UseTrial(handle, TA_SYSTEM | TA_DISALLOW_VM | TA_DISALLOW_SANDBOX);Ideally by the end of May.
MolodenskyWyatt wrote:> Ideally by the end of May.
Awesome!
One more question:Suppose someone is using a former version of our Software (pre-TA-4.0). In the case of unverified trials the license servers are never contacted, so I suppose there won't be a way to disallow trials in containers by default, e.g. by setting a switch somewhere on the LimeLm website. Do you know of any way how we could still disallow unverified trials for pre-TA-4.0 versions within containers, without completely deactivating the unverified trial.
Do you know of any way how we could still disallow unverified trials for pre-TA-4.0 versions within containers, without completely deactivating the unverified trial.
No, you will just have to release a new version of your app using the latest version of TurboActivate.
petrpThe ability to recognise Docker runtime environment is quite critical for any (linux) software running in trial or activated mode - the main reason for using LimeLM.
The TA 4.0, which is suppose to include the new TA_DISALLOW_SANDBOX , has been scheduled for release on end of May 2015, there were also promises of release by end of the year 2015, now it is February 2016 and waiting continues... well, delays in software development are typical, but...
Maybe it could be better to release critical fixes and improvements sooner - in smaller and more regular incremental updates of the library... Better to make more small releases, then waiting years for one huge upgrade. RERO: Release early, release often...
- Is there any way how to alpha / beta test TA 4.0 now?- If not, what about to release a new minor version upgrade with TA_DISALLOW_SANDBOX inside, if TA 4.0 is getting more and more delay?
>> "The ability to recognise Docker runtime environment is quite critical for any (linux) software running in trial or activated mode - the main reason for using LimeLM."
Yes, it is.
>> "now it is February 2016 and waiting continues... well, delays in software development are typical, but..."
There were both delays and plan changes (including infrastructure improvements). Together that pushed the date back.
>> "Maybe it could be better to release critical fixes and improvements sooner - in smaller and more regular incremental updates of the library..."
Yes, that's what we did with the 3.x release. The 4.x is a big leap forward (with necessary API changes) and thus it required it's own release -- it wasn't something that could be rolled out incrementally.
The 4.x release and onward we will continue our trend of incremental releases.
>> "- Is there any way how to alpha / beta test TA 4.0 now?"
No, we're too close to release.
>> "- If not, what about to release a new minor version upgrade with TA_DISALLOW_SANDBOX inside, if TA 4.0 is getting more and more delay?"
We couldn't do that without, ironically, delaying 4.0.
We're well aware of the demand. We're working to get it out as soon as possible.