On 21/01/2024 06:55, phoebus phoebus wrote:
My role is strictly technical, focused on providing unbiased, pragmatic,
and fact-based assessments of solutions, whether they are proprietary
or open source.
From my point of view, you are trying hard to avoid discussion of
technical issues. It is still unclear to me why you want namely a
customized terminal emulator instead of combining existing applications,
perhaps with a tiny custom helper.
- SSH, VPN, etc. to ensure secure connection to the server.
- A terminal application without passthrough printing.
- A filter in between that in response to escape-code-1 starts sending
data to the serial port instead of the terminal application and switches
back to the terminal application on receiving of escape-code-2.
Even if "expect" is not suitable (I am in doubts, but I am not closely
familiar with it), creation of the custom tool should be easier than
modification of a terminal emulator. Moreover, it would allow to change
other parts of the solution.
Developers anyway would need a testbench to debug code you need without
relying on your server. It does not matter whether it would be a filter
or a terminal emulator. Nobody is trying to force you to name companies.
The real issue is that you are refusing questions concerning *examples*
for what use cases suggestions would not work.
What I read in this thread is just "we have special needs". It resembles
replies from enterprise support stuff who either do not know any
technical details or are afraid to disclose some know-how they might heard.
P.S.
https://lists.debian.org/msgid-search/zzrrbqsut2fnu...@einval.com
Monthly FAQ for Debian-user mailing list (modified 20240102)
* It is not necessary to answer every post on the mailing list.
* It may also be useful for someone to post a summary email from time to
time to explain long threads.
