Re: [wsjt-devel] Expiration Date on Software

[Matthew Miller]

Seems like the best way then would be if they maintain their own channel, as is 
the case with CHIRP, VirtualBox, and countless other applications.  Then I 
could add that source and the package manager would use the more up to date 
packages seamlessly.  The packages are already being built for a number of 
different platforms in the proper package formats, tossing them in a proper 
repository for each wouldn’t be a significant increase in effort.

Side-note, I also encountered a problem where version 2.X seems to not be 
compiled against the correct glibc versions for Ubuntu 16.04-LTS base, which 
may be related to why its not updated in the Ubuntu channel if they are just 
picking up what is already built.  I have been having to recompile it myself 
with 2.0 and 2.0.1 as well as the 2.1RC5.

FWIW I had no idea about any update until a local ham told me about needing to 
update with 2.0 when I mentioned it one morning.

The other idea would be as someone else suggested, put a "header" or something 
with a version that goes out over the air...now you won't have to make the 
software "phone home", it can simply decide the version the other people are 
sending and if its newer than what it has, tell the user "Hey, it looks like 
there is a newer protocol version, you should go  to check for 
updates!"  That would be a cross-platform solution without needing to worry 
about package managers or "phoning home" or Internet access at all.  Maybe that 
would be the best way?

-Matt / KK4NDE

-Original Message-
From: Christoph Berg [mailto:m...@debian.org] 
Sent: Friday, May 10, 2019 12:21 PM
To: WSJT software development
Subject: Re: [wsjt-devel] Expiration Date on Software

Re: Adam Bartlett 2019-05-10 

> One of the challenges of automatic updating is package managers and 
> such on the Linux side are often generations behind (not a big deal, 
> but if a user installs Ubuntu, types "apt install wsjtx" and they 
> still have 1.x in their repo it's going to confuse them) and trying to 
> deal with those can be less than fun.  As someone who's had to support 
> a lot of users over the years (and has been a professional release 
> engineer), automated updates can be difficult to get right and very 
> easy to get wrong (proper cryptographic signing of packages, controls 
> to ensure malware or unapproved features do not escape into a release, etc).

Also, updating a piece of software that came over some channel over a different 
channel will likely be annoying. So no automated downloads or whatever please. 
(Says the Debian maintainer.)

> My opinion is that the occasional nag screen would be useful - call 
> home to Princeton (or SF/Github/etc), if there's a update listed in a 
> XML file it

Fwiw, it's part of the Debian policies that packages shouldn't call home 
without the user's consent (you can probably also derive that from the GDPR). 
Maybe that's less strict with hamradio software that is meant to be used 
publically, but still.

I guess the biggest problem here is that we can't tell when a certain version 
should expire. 1.9.x is clearly dead, but 2.0.x will possibly work forever 
unless the protocol changes again...

Not trying to fix that problem might actually be the smartest solution.

Christoph DF7CB


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] JTDX Audio Input 100 %

[Neil Zampella]

FWIW .. it affects the other program as it turns up the MiC/Line In to
100%, so no matter what program uses that audio it will be at 100%

Neil, KN3ILZ

On 5/10/2019 11:06 AM, Enrique Scheuer wrote:

Hello Mike,thanks Im already aware but it doenst mention that it aslo
affects  JTDX  .
73 de Enrique
PY2CP

Em sex, 10 de mai de 2019 às 11:42, Black Michael via wsjt-devel
mailto:wsjt-devel@lists.sourceforge.net>> escreveu:

Known bug

http://physics.princeton.edu/pulsar/k1jt/Reported_bugs.txt

de Mike W9MDB


On Friday, May 10, 2019, 9:27:57 AM CDT, Enrique Scheuer
mailto:enrique.sche...@gmail.com>> wrote:


Hello sirs,

After installing WSJT-X rc5 the my JTDX 135 audio input also
jumped to 100 pct and I am not suceeding to fix it. Any suggestion?

73 de Enrique
PY2CP
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/wsjt-devel




---
This email has been checked for viruses by AVG.
https://www.avg.com
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] JTDX Audio Input 100 %

[Gary McDuffie]

> On May 10, 2019, at 09:04, Jason Peardon  wrote:
> 
> Lower it until the scale in WSJT-X is around 60% consistently.

That should be 30 on the audio meter in WSJT-X when tuned to a clean frequency 
and just listening to white noise.

Gary - AG0N

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Expiration Date on Software

[Christoph Berg]

Re: Adam Bartlett 2019-05-10 

> One of the challenges of automatic updating is package managers and such on
> the Linux side are often generations behind (not a big deal, but if a user
> installs Ubuntu, types "apt install wsjtx" and they still have 1.x in their
> repo it's going to confuse them) and trying to deal with those can be less
> than fun.  As someone who's had to support a lot of users over the years
> (and has been a professional release engineer), automated updates can be
> difficult to get right and very easy to get wrong (proper cryptographic
> signing of packages, controls to ensure malware or unapproved features do
> not escape into a release, etc).

Also, updating a piece of software that came over some channel over a
different channel will likely be annoying. So no automated downloads
or whatever please. (Says the Debian maintainer.)

> My opinion is that the occasional nag screen would be useful - call home to
> Princeton (or SF/Github/etc), if there's a update listed in a XML file it

Fwiw, it's part of the Debian policies that packages shouldn't call
home without the user's consent (you can probably also derive that
from the GDPR). Maybe that's less strict with hamradio software that
is meant to be used publically, but still.

I guess the biggest problem here is that we can't tell when a certain
version should expire. 1.9.x is clearly dead, but 2.0.x will possibly
work forever unless the protocol changes again...

Not trying to fix that problem might actually be the smartest
solution.

Christoph DF7CB


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Expiration Date on Software

[Adam Bartlett]

One of the challenges of automatic updating is package managers and such on
the Linux side are often generations behind (not a big deal, but if a user
installs Ubuntu, types "apt install wsjtx" and they still have 1.x in their
repo it's going to confuse them) and trying to deal with those can be less
than fun.  As someone who's had to support a lot of users over the years
(and has been a professional release engineer), automated updates can be
difficult to get right and very easy to get wrong (proper cryptographic
signing of packages, controls to ensure malware or unapproved features do
not escape into a release, etc).

My opinion is that the occasional nag screen would be useful - call home to
Princeton (or SF/Github/etc), if there's a update listed in a XML file it
displays (and can be set to ignore) if not it just runs, it would have been
useful during the 1.9-2.0 transition (I caught myself wondering one day a
few months ago why a machine I don't use often but use occasionally for
remote operating wasn't showing any FT8 with an accurate clock while the
waterfall was chock full, it was because it was still on 1.9). If we're
planning on ever "breaking" the encoding again, I think update alerts is a
feature worth tossing in the next minor release (not 2.1) feature pile.

73 Adam N5YHF

On Fri, May 10, 2019 at 10:06 AM WB5JJJ  wrote:

> If the program on startup finds a valid Internet connection, then check
> for an update automatically.  If one is available, download it, or at least
> supply a link to the file, and THEN allow the user to install (or delete)
> it as they feel.  Make it keep bugging the user on startup of WSJTx until
> the update is done.  Most software I use has this kind of feature.
>
> If the Internet is not available, allow the software to run as always, but
> put up a warning that suggests the user check the website for an update.
> This notice could happen on a weekly or even monthly schedule, or until the
> Internet is restored.  Or they could then use another computer with
> Internet access, to download the software and install it on the one without
> Internet.
>
> As was found with v1.9.1 expiring, many users downloaded it way back or
> maybe had someone else install it for them and don't have a clue where to
> check for updates.  An update link in the About box would be very helpful
> for those that forget where it came from.
>
> WB5JJJ - George
>
> On Fri, May 10, 2019 at 6:59 AM Onno Benschop  wrote:
>
>> Backwards compatibility is a thing ...
>>
>> Also, if the new version of the software knows how to decode an older
>> encoding, you already have an implied version number.
>>
>> It's not like this takes eons to decode, nothing wrong with trying
>> several times, newest version first, next version next and so on.
>> --
>> finger painting on glass is an inexact art - apologies for any errors in
>> this scra^Hibble
>>
>> ()/)/)() ..ASCII for Onno..
>>
>> On Fri., 10 May 2019, 16:11 Reino Talarmo, 
>> wrote:
>>
>>> Hi Onno,
>>>
>>> >A better idea is to include a protocol version number in the QSO
>>> information, that way both sides have a chance to alert the operator.
>>>
>>>
>>>
>>> A nice idea, but that information needs to be sent using the lower layer
>>> of the previous protocol version….
>>>
>>> 73, Reino, oh3ma
>>> ___
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] JTDX Audio Input 100 %

[Enrique Scheuer]

Hello Mike,thanks Im already aware but it doenst mention that it aslo
affects  JTDX  .
73 de Enrique
PY2CP

Em sex, 10 de mai de 2019 às 11:42, Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> escreveu:

> Known bug
>
> http://physics.princeton.edu/pulsar/k1jt/Reported_bugs.txt
>
> de Mike W9MDB
>
>
> On Friday, May 10, 2019, 9:27:57 AM CDT, Enrique Scheuer <
> enrique.sche...@gmail.com> wrote:
>
>
> Hello sirs,
>
> After installing WSJT-X rc5 the my JTDX 135 audio input also jumped to 100
> pct and I am not suceeding to fix it. Any suggestion?
>
> 73 de Enrique
> PY2CP
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Expiration Date on Software

[WB5JJJ]

If the program on startup finds a valid Internet connection, then check for
an update automatically.  If one is available, download it, or at least
supply a link to the file, and THEN allow the user to install (or delete)
it as they feel.  Make it keep bugging the user on startup of WSJTx until
the update is done.  Most software I use has this kind of feature.

If the Internet is not available, allow the software to run as always, but
put up a warning that suggests the user check the website for an update.
This notice could happen on a weekly or even monthly schedule, or until the
Internet is restored.  Or they could then use another computer with
Internet access, to download the software and install it on the one without
Internet.

As was found with v1.9.1 expiring, many users downloaded it way back or
maybe had someone else install it for them and don't have a clue where to
check for updates.  An update link in the About box would be very helpful
for those that forget where it came from.

WB5JJJ - George

On Fri, May 10, 2019 at 6:59 AM Onno Benschop  wrote:

> Backwards compatibility is a thing ...
>
> Also, if the new version of the software knows how to decode an older
> encoding, you already have an implied version number.
>
> It's not like this takes eons to decode, nothing wrong with trying several
> times, newest version first, next version next and so on.
> --
> finger painting on glass is an inexact art - apologies for any errors in
> this scra^Hibble
>
> ()/)/)() ..ASCII for Onno..
>
> On Fri., 10 May 2019, 16:11 Reino Talarmo, 
> wrote:
>
>> Hi Onno,
>>
>> >A better idea is to include a protocol version number in the QSO
>> information, that way both sides have a chance to alert the operator.
>>
>>
>>
>> A nice idea, but that information needs to be sent using the lower layer
>> of the previous protocol version….
>>
>> 73, Reino, oh3ma
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] JTDX Audio Input 100 %

[Jason Peardon]

If you are running Windows 10:

Right click the speaker icon in the bottom right corner down by the clock
Select: Open Sound Settings
In the new window that opens find "Input" where the microphone is listed
Below that you should see Device Properties; click this
In the new dialog box that opens you will see tabs across the top; click
Levels
Chances are your microphone level is at 100% (this causes the WSJT-X gain
scale (bottom left) to often go Red and causes clipping on input signal.
Lower it until the scale in WSJT-X is around 60% consistently.

Hope that helps!

73, Jason - KC1LAE


On Fri, May 10, 2019 at 10:42 AM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Known bug
>
> http://physics.princeton.edu/pulsar/k1jt/Reported_bugs.txt
>
> de Mike W9MDB
>
>
> On Friday, May 10, 2019, 9:27:57 AM CDT, Enrique Scheuer <
> enrique.sche...@gmail.com> wrote:
>
>
> Hello sirs,
>
> After installing WSJT-X rc5 the my JTDX 135 audio input also jumped to 100
> pct and I am not suceeding to fix it. Any suggestion?
>
> 73 de Enrique
> PY2CP
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] JTDX Audio Input 100 %

[Black Michael via wsjt-devel]

Known bug
http://physics.princeton.edu/pulsar/k1jt/Reported_bugs.txt

de Mike W9MDB 

On Friday, May 10, 2019, 9:27:57 AM CDT, Enrique Scheuer 
 wrote:  
 
 Hello sirs,
After installing WSJT-X rc5 the my JTDX 135 audio input also jumped to 100 pct 
and I am not suceeding to fix it. Any suggestion?
73 de EnriquePY2CP___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] JTDX Audio Input 100 %

[Enrique Scheuer]

Hello sirs,

After installing WSJT-X rc5 the my JTDX 135 audio input also jumped to 100
pct and I am not suceeding to fix it. Any suggestion?

73 de Enrique
PY2CP
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Expiration Date on Software

[Onno Benschop]

Backwards compatibility is a thing ...

Also, if the new version of the software knows how to decode an older
encoding, you already have an implied version number.

It's not like this takes eons to decode, nothing wrong with trying several
times, newest version first, next version next and so on.
--
finger painting on glass is an inexact art - apologies for any errors in
this scra^Hibble

()/)/)() ..ASCII for Onno..

On Fri., 10 May 2019, 16:11 Reino Talarmo, 
wrote:

> Hi Onno,
>
> >A better idea is to include a protocol version number in the QSO
> information, that way both sides have a chance to alert the operator.
>
>
>
> A nice idea, but that information needs to be sent using the lower layer
> of the previous protocol version….
>
> 73, Reino, oh3ma
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Expiration Date on Software

[Matthew Miller]

The other problem with an expiration, what happens when the devs forget to push 
a new version on schedule?

Don’t think it could happen?  Would you believe last week that very thing 
happened with Mozilla Firefox on a security certificate breaking things for 
everyone globally that used the browser last weekend.
https://arstechnica.com/information-technology/2019/05/firefox-add-ons-mass-disabled-by-certificate-bug-hotfix-for-some-ready/

Now, could you imagine what would happen if a forced expiration happened…say a 
couple days before some contest, and there wasn’t yet a new version out?
Or the proposed thing of “what if you don’t have Internet”…what happens if you 
have a SOTA or DXpedition that requires more than a couple days of prep and you 
don’t realize that a new version came out between when you packed up and when 
you arrive, now your software is bricked?

Requiring manual intervention to keep things working can and will fail sooner 
or later.

-Matt / KK4NDE

From: Matthew Miller [mailto:mmill...@mail.umw.edu]
Sent: Friday, May 10, 2019 7:20 AM
To: 'WSJT software development'
Cc: 'Gustafson Neil'
Subject: Re: [wsjt-devel] Expiration Date on Software

Even easier than modifying the hosts file, I can just change the system date to 
get around an offline check.

-Matt / KK4NDE

From: rjai...@gmail.com [mailto:rjai...@gmail.com]
Sent: Thursday, May 09, 2019 11:21 PM
To: WSJT software development
Cc: Gustafson Neil
Subject: Re: [wsjt-devel] Expiration Date on Software

The online check is good except some may then modify hosts file and similar to 
defeat it. If it comes with a kill switch if it can’t phone home successfully 
then that may work out. An auto update feature, I suppose

Older versions on the air did cause problems in the past. Some users hung on to 
them either deliberately or unintentionally.

73
Ria
N2RJ


On Thu, May 9, 2019 at 10:52 PM Matthew Miller 
mailto:mmill...@mail.umw.edu>> wrote:
I would recommend against it -- how would you pick a reasonable date to ensure 
you don't need it to be updated sooner, and also not too soon that people have 
to reinstall just to update the date?

A more reasonable approach would be to have it poll a file on the server that 
tells the software what the most recent version is that is released, and 
possibly have a flag or option telling it if the update will break 
backward-compatibility (like 2.0 did).  Then you could have a nag screen that 
tells you to download the latest version X and links to the changelog.

I will point out I was unaware for many months that v2.0 had come out because I 
had no reason to check the website since what I have was working fine.

Also, at least for Linux distributions, you could set up a software repository 
channel instead of just having the download packages, this way the updates 
would be pushed out seamlessly to everyone in real time, other apps such as 
CHIRP do this and it is very convenient.  I don't know if Mac has anything 
similar, I don't believe Windows does (unless you get set up in the Win10 
store).

Point is, for a beta the expiration makes sense like a trial expires.  For 
production software, there are much more conventional reasonable  ways to 
encourage users to update.

-Matt / KK4NDE

-Original Message-
From: rjai...@gmail.com 
[mailto:rjai...@gmail.com]
Sent: Tuesday, May 07, 2019 7:19 PM
To: WSJT software development
Cc: Gustafson Neil
Subject: Re: [wsjt-devel] Expiration Date on Software

That's a good idea. Some held on to old versions so they could retain features 
that were detrimental to the herd, such as lock rx=tx.

Expiring the versions is a very good idea.

Ria
N2RJ

On Tue, 7 May 2019 at 19:14, Gustafson Neil via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net>> 
wrote:
>
> Hi All:
>   Recent mention of an expiration date on RC 5 of WSJT-X...  Perhaps all 
> releases of WSJT-X should expire in some reasonable timeframe.  Today I 
> debugged a failing FT8 station that had not been used as such in some months. 
>   After some effort in checking connections, config., etc., it was realized 
> that release 1.8 was installed (e.g. obsolete payload format).  One example 
> of why older releases should be disabled at some point in time.
>
> Thanks and 73,
> Neil W3ZQI
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___

Re: [wsjt-devel] Expiration Date on Software

[Matthew Miller]

Even easier than modifying the hosts file, I can just change the system date to 
get around an offline check.

-Matt / KK4NDE

From: rjai...@gmail.com [mailto:rjai...@gmail.com]
Sent: Thursday, May 09, 2019 11:21 PM
To: WSJT software development
Cc: Gustafson Neil
Subject: Re: [wsjt-devel] Expiration Date on Software

The online check is good except some may then modify hosts file and similar to 
defeat it. If it comes with a kill switch if it can’t phone home successfully 
then that may work out. An auto update feature, I suppose

Older versions on the air did cause problems in the past. Some users hung on to 
them either deliberately or unintentionally.

73
Ria
N2RJ


On Thu, May 9, 2019 at 10:52 PM Matthew Miller 
mailto:mmill...@mail.umw.edu>> wrote:
I would recommend against it -- how would you pick a reasonable date to ensure 
you don't need it to be updated sooner, and also not too soon that people have 
to reinstall just to update the date?

A more reasonable approach would be to have it poll a file on the server that 
tells the software what the most recent version is that is released, and 
possibly have a flag or option telling it if the update will break 
backward-compatibility (like 2.0 did).  Then you could have a nag screen that 
tells you to download the latest version X and links to the changelog.

I will point out I was unaware for many months that v2.0 had come out because I 
had no reason to check the website since what I have was working fine.

Also, at least for Linux distributions, you could set up a software repository 
channel instead of just having the download packages, this way the updates 
would be pushed out seamlessly to everyone in real time, other apps such as 
CHIRP do this and it is very convenient.  I don't know if Mac has anything 
similar, I don't believe Windows does (unless you get set up in the Win10 
store).

Point is, for a beta the expiration makes sense like a trial expires.  For 
production software, there are much more conventional reasonable  ways to 
encourage users to update.

-Matt / KK4NDE

-Original Message-
From: rjai...@gmail.com 
[mailto:rjai...@gmail.com]
Sent: Tuesday, May 07, 2019 7:19 PM
To: WSJT software development
Cc: Gustafson Neil
Subject: Re: [wsjt-devel] Expiration Date on Software

That's a good idea. Some held on to old versions so they could retain features 
that were detrimental to the herd, such as lock rx=tx.

Expiring the versions is a very good idea.

Ria
N2RJ

On Tue, 7 May 2019 at 19:14, Gustafson Neil via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net>> 
wrote:
>
> Hi All:
>   Recent mention of an expiration date on RC 5 of WSJT-X...  Perhaps all 
> releases of WSJT-X should expire in some reasonable timeframe.  Today I 
> debugged a failing FT8 station that had not been used as such in some months. 
>   After some effort in checking connections, config., etc., it was realized 
> that release 1.8 was installed (e.g. obsolete payload format).  One example 
> of why older releases should be disabled at some point in time.
>
> Thanks and 73,
> Neil W3ZQI
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Expiration Date on Software

[Reino Talarmo]

Hi Onno,

>A better idea is to include a protocol version number in the QSO information, 
>that way both sides have a chance to alert the operator.

 

A nice idea, but that information needs to be sent using the lower layer of the 
previous protocol version….

73, Reino, oh3ma

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Expiration Date on Software

[Jonathan Magee]

I would be against a kill switch if it can't phone home as this would
restrict people to only using the program if they were online. This would
stop people using it if they were located somewhere where there was no
internet access.

73
Jonathan
GI7KMC

On Fri, 10 May 2019 at 04:23, rjai...@gmail.com  wrote:

> The online check is good except some may then modify hosts file and
> similar to defeat it. If it comes with a kill switch if it can’t phone home
> successfully then that may work out. An auto update feature, I suppose
>
> Older versions on the air did cause problems in the past. Some users hung
> on to them either deliberately or unintentionally.
>
> 73
> Ria
> N2RJ
>
>
> On Thu, May 9, 2019 at 10:52 PM Matthew Miller 
> wrote:
>
>> I would recommend against it -- how would you pick a reasonable date to
>> ensure you don't need it to be updated sooner, and also not too soon that
>> people have to reinstall just to update the date?
>>
>> A more reasonable approach would be to have it poll a file on the server
>> that tells the software what the most recent version is that is released,
>> and possibly have a flag or option telling it if the update will break
>> backward-compatibility (like 2.0 did).  Then you could have a nag screen
>> that tells you to download the latest version X and links to the changelog.
>>
>> I will point out I was unaware for many months that v2.0 had come out
>> because I had no reason to check the website since what I have was working
>> fine.
>>
>> Also, at least for Linux distributions, you could set up a software
>> repository channel instead of just having the download packages, this way
>> the updates would be pushed out seamlessly to everyone in real time, other
>> apps such as CHIRP do this and it is very convenient.  I don't know if Mac
>> has anything similar, I don't believe Windows does (unless you get set up
>> in the Win10 store).
>>
>> Point is, for a beta the expiration makes sense like a trial expires.
>> For production software, there are much more conventional reasonable  ways
>> to encourage users to update.
>>
>> -Matt / KK4NDE
>>
>> -Original Message-
>> From: rjai...@gmail.com [mailto:rjai...@gmail.com]
>> Sent: Tuesday, May 07, 2019 7:19 PM
>> To: WSJT software development
>> Cc: Gustafson Neil
>> Subject: Re: [wsjt-devel] Expiration Date on Software
>>
>> That's a good idea. Some held on to old versions so they could retain
>> features that were detrimental to the herd, such as lock rx=tx.
>>
>> Expiring the versions is a very good idea.
>>
>> Ria
>> N2RJ
>>
>> On Tue, 7 May 2019 at 19:14, Gustafson Neil via wsjt-devel <
>> wsjt-devel@lists.sourceforge.net> wrote:
>> >
>> > Hi All:
>> >   Recent mention of an expiration date on RC 5 of WSJT-X...  Perhaps
>> all releases of WSJT-X should expire in some reasonable timeframe.  Today I
>> debugged a failing FT8 station that had not been used as such in some
>> months.   After some effort in checking connections, config., etc., it was
>> realized that release 1.8 was installed (e.g. obsolete payload format).
>> One example of why older releases should be disabled at some point in time.
>> >
>> > Thanks and 73,
>> > Neil W3ZQI
>> > ___
>> > wsjt-devel mailing list
>> > wsjt-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Expiration Date on Software

[Onno Benschop]

A better idea is to include a protocol version number in the QSO
information, that way both sides have a chance to alert the operator.

I should also point out that in ICT data exchange it's common practice to
include a version in the meta-data to prevent exactly this issue.

--
finger painting on glass is an inexact art - apologies for any errors in
this scra^Hibble

()/)/)() ..ASCII for Onno..

On Fri., 10 May 2019, 11:22 rjai...@gmail.com,  wrote:

> The online check is good except some may then modify hosts file and
> similar to defeat it. If it comes with a kill switch if it can’t phone home
> successfully then that may work out. An auto update feature, I suppose
>
> Older versions on the air did cause problems in the past. Some users hung
> on to them either deliberately or unintentionally.
>
> 73
> Ria
> N2RJ
>
>
> On Thu, May 9, 2019 at 10:52 PM Matthew Miller 
> wrote:
>
>> I would recommend against it -- how would you pick a reasonable date to
>> ensure you don't need it to be updated sooner, and also not too soon that
>> people have to reinstall just to update the date?
>>
>> A more reasonable approach would be to have it poll a file on the server
>> that tells the software what the most recent version is that is released,
>> and possibly have a flag or option telling it if the update will break
>> backward-compatibility (like 2.0 did).  Then you could have a nag screen
>> that tells you to download the latest version X and links to the changelog.
>>
>> I will point out I was unaware for many months that v2.0 had come out
>> because I had no reason to check the website since what I have was working
>> fine.
>>
>> Also, at least for Linux distributions, you could set up a software
>> repository channel instead of just having the download packages, this way
>> the updates would be pushed out seamlessly to everyone in real time, other
>> apps such as CHIRP do this and it is very convenient.  I don't know if Mac
>> has anything similar, I don't believe Windows does (unless you get set up
>> in the Win10 store).
>>
>> Point is, for a beta the expiration makes sense like a trial expires.
>> For production software, there are much more conventional reasonable  ways
>> to encourage users to update.
>>
>> -Matt / KK4NDE
>>
>> -Original Message-
>> From: rjai...@gmail.com [mailto:rjai...@gmail.com]
>> Sent: Tuesday, May 07, 2019 7:19 PM
>> To: WSJT software development
>> Cc: Gustafson Neil
>> Subject: Re: [wsjt-devel] Expiration Date on Software
>>
>> That's a good idea. Some held on to old versions so they could retain
>> features that were detrimental to the herd, such as lock rx=tx.
>>
>> Expiring the versions is a very good idea.
>>
>> Ria
>> N2RJ
>>
>> On Tue, 7 May 2019 at 19:14, Gustafson Neil via wsjt-devel <
>> wsjt-devel@lists.sourceforge.net> wrote:
>> >
>> > Hi All:
>> >   Recent mention of an expiration date on RC 5 of WSJT-X...  Perhaps
>> all releases of WSJT-X should expire in some reasonable timeframe.  Today I
>> debugged a failing FT8 station that had not been used as such in some
>> months.   After some effort in checking connections, config., etc., it was
>> realized that release 1.8 was installed (e.g. obsolete payload format).
>> One example of why older releases should be disabled at some point in time.
>> >
>> > Thanks and 73,
>> > Neil W3ZQI
>> > ___
>> > wsjt-devel mailing list
>> > wsjt-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel