Jul 15, 2023·edited Jul 15, 2023Liked by Steve Stroh N8GNJ
As someone who follows and regularly plays with digital protocols both on HF and VHF/UHF, I really struggle to see what the fuss with VARA is all about. Sure, it's a technically excellent protocol, but the modem/software is abysmal and has at times even been user hostile**. The modem software is written in VB6 which was deprecated in favor of VB.NET in 2003. Microsoft has only committed to supporting the VB6 runtime through Windows 11 (but they could extend it at their leisure I suppose. See https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-basic-6/visual-basic-6-support-policy). This means for an optimal experience a Windows machine is required*.
The dependency on VB6 and the GUI also prevent the modem from starting as a proper service (Yes, you can hack it to run under a VNC X session under Linux/wine). This requires automatic login in order to start the modem automatically on Windows. This is really bad from a security standpoint if the VARA modem is in a shared location (think repeater site.)
Windows tends to be much more maintenance intensive than other OSs, and more power hungry as well. There is also no chance of a hardware TNC being developed which makes filling coverage gaps--which is something I do currently using a KPC-3 for AX.25 packet several times a year for public service events--much more difficult. You can't just hand two boxes to a ham unfamiliar with the setup and say "Hey, plug this in and turn it on." You also are probably going to have to spend a couple hours doing updates/testing before the event. I suppose this is why there are hams experimenting with repeaters for VARA. To me it's just not worth the hassle to use and support a mode that is completely closed--both in protocol and source--and requires that much manual intervention to run.
*Yes, VARA somewhat runs in WINE. Badly in my experience. It seems to work well enough on the client side but on a packet switch/node it just doesn't have the reliability. Sure, there are workarounds (see https://eindhoven.space/2022/07/12/kicktnc-sh-raspberry-pi-vara-hf-tnc-stabilization/) but this totally fails on the KISS principal. All that aside, WINE doesn't run on mobile devices so either a hardware TNC or Android/iOS implementation is never going to happen.
**At least one release of VARA had DRM put in the software that broke WINE compatibility.
As someone who follows and regularly plays with digital protocols both on HF and VHF/UHF, I really struggle to see what the fuss with VARA is all about. Sure, it's a technically excellent protocol, but the modem/software is abysmal and has at times even been user hostile**. The modem software is written in VB6 which was deprecated in favor of VB.NET in 2003. Microsoft has only committed to supporting the VB6 runtime through Windows 11 (but they could extend it at their leisure I suppose. See https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-basic-6/visual-basic-6-support-policy). This means for an optimal experience a Windows machine is required*.
The dependency on VB6 and the GUI also prevent the modem from starting as a proper service (Yes, you can hack it to run under a VNC X session under Linux/wine). This requires automatic login in order to start the modem automatically on Windows. This is really bad from a security standpoint if the VARA modem is in a shared location (think repeater site.)
Windows tends to be much more maintenance intensive than other OSs, and more power hungry as well. There is also no chance of a hardware TNC being developed which makes filling coverage gaps--which is something I do currently using a KPC-3 for AX.25 packet several times a year for public service events--much more difficult. You can't just hand two boxes to a ham unfamiliar with the setup and say "Hey, plug this in and turn it on." You also are probably going to have to spend a couple hours doing updates/testing before the event. I suppose this is why there are hams experimenting with repeaters for VARA. To me it's just not worth the hassle to use and support a mode that is completely closed--both in protocol and source--and requires that much manual intervention to run.
*Yes, VARA somewhat runs in WINE. Badly in my experience. It seems to work well enough on the client side but on a packet switch/node it just doesn't have the reliability. Sure, there are workarounds (see https://eindhoven.space/2022/07/12/kicktnc-sh-raspberry-pi-vara-hf-tnc-stabilization/) but this totally fails on the KISS principal. All that aside, WINE doesn't run on mobile devices so either a hardware TNC or Android/iOS implementation is never going to happen.
**At least one release of VARA had DRM put in the software that broke WINE compatibility.
"If your goal does not have a schedule, it is a dream.", I think this is nonsense. The MMDVM had/has no schedule, even in its early days.