Re: Linux RMS - headed for digital dustbin?


Stuart Longland VK4MSL
 

On 05/10/18 08:09, Steve wrote:
Is the real challenge here a Winlink development team which is myopic in
their support for various operating systems?  If W1HKJ can build, test,
and support three operating systems for the FLDigi suite, why can't
they?  In Emcomm situations, where interoperability is the key, that
just doesn't make sense.

It is most difficult to be boxed into a position where one has to tell a
volunteer that they must pay homage to a large company in Redmond,
Washington, in order to use Winlink Express forms.  That would be like
telling hams they all have to buy radios from the same company.
This is just a symptom of a larger problem, people who write software
for legacy operating systems only and don't document how their software
operates.

Really, it should not matter that Winlink Express is Windows-only. It
should not matter that they only support Windows.

The protocol should be open and documented. Sufficient for someone to
come up with an alternate but interoperable system.

Example: consider ECMAScript. Prior to that coming on the scene, there
were several attempts at doing scripting on web pages. Microsoft threw
their hat in the ring with, wait for it, VBScript, but it never took
off. The other way was to embed applets, again mostly using proprietary
extensions.

ActiveX only took off in enterprise circles, with it generally being
accepted as a poor solution elsewhere. Macromedia^WAdobe Flash and Java
were more common ways of filling in where JavaScript couldn't.
JavaScript has largely taken over, because it is open and royalty free.

I've actually considered some ideas for an emergency comms system here:
https://stuartl.longlandclan.id.au/blog/2017/03/26/digital-emergency-comms-ideas/

I've also considered the idea of whether to use a "blockchain" as a way
of indicating the route taken by a message. The idea that the sender
starts the chain (the message is the "genesis"), and each party
forwarding hashes and signs the previous block. That way you have
mathematical proof that a message was passed on via a particular route
and that the message received at the far end is "authentic".

It should be possible for anyone to obtain the relevant public keys,
verify each signature, and reproduce each hash, to prove that a message
was sent by a particular person and took a given route.

There was also scope for encryption in there, ACMA rules allow that for
bonafide emergencies, but I realise this is problematic elsewhere, so
would be a strictly optional feature. You'll have to go to special
effort to enable it.

Many of the ideas considered there would be compatible with the UDRC.
The project though is on the back burner whilst I deal with some more
pressing projects.

Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

Join main@nw-digital-radio.groups.io to automatically receive all group messages.