Broadway
Broadway
Posted Feb 5, 2025 9:34 UTC (Wed) by farnz (subscriber, #17727)In reply to: Broadway by joib
Parent article: What’s new in GTK, winter 2025 edition
When I was at university, the "standard" lab setup had an instrument running X11 - HP's were based around HP-RT (AFAICT), other manufacturers had their own OSes, and most of the instruments were old enough to predate RDP (5 to 6 years old was common, some were 10 or more years old).
You could thus connect to the instrument's UI by using xhost to permit the instrument to connect to your local display server (the university licensed Exceed for people on Windows NT to use), and this could be done anywhere where you could get IP networking (albeit accessing X11 applications over dial-up to the university's network was slow and painful, so doing so from home was not a good idea unless you were rich enough to afford ISDN, and even then wasn't great because of the lack of throughput, although ISDN did fix the latency issues).
I can easily see someone my age, who remembers this sort of setup, designing Broadway as a way to recreate it on a modern stack, as an alternative to RDP. And the niche in industry for controlling instruments remotely is larger than you might think; contract manufacturers will let you host an instrument that they attach failed boards to (according to your instruction) on their site, so that you can connect and measure various things before deciding if you want the board X-rayed, sent internationally to your site, or destroyed.
Posted Feb 5, 2025 9:46 UTC (Wed)
by joib (subscriber, #8541)
[Link] (3 responses)
I meant the niche where RDP (or VNC or some similar thing) doesn't cut it and (re)architecting the application as a "proper" webapp isn't possible either, thus necessitating something like Broadway.
Posted Feb 5, 2025 10:01 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (2 responses)
If there was a good way to interact with the remote instruments over ~300 ms to ~3,000 ms of latency, then the SME would spend less time doing the one-off check at the remote site than they currently spend working with the test developer to script the same one-off check, even though it'd be slower than doing the check locally. And that's the sort of niche that Broadway targeted - but because instrument UIs aren't written in GTK (or as web apps, usually - they're binaries running on the instrument, after all, and can use a full set of native UI APIs), it's a non-starter commercially.
Posted Feb 5, 2025 18:58 UTC (Wed)
by DemiMarie (subscriber, #164188)
[Link] (1 responses)
Posted Feb 5, 2025 19:11 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
Instead, they want you to use their badly-run connection for everything, so that they can monitor what's going on and look for "suspicious" activity that's not in keeping with "approved" operations. And part of what they do is block your kit from accessing the Internet except in pre-booked intervals, so that they can ensure that you can't see who else is on site at the same time - Starlink would bypass that, and therefore not be allowed.
Broadway
The contract manufacturer niche is already one where RDP-alikes don't cut it, because contract manufacturers abroad tend to be placed where labour and power are cheap, with no consideration for Internet quality. The current way this is handled is to upload Python scripts or LabView scripts that can be executed as a one-off and return a report; that way, we don't need to directly access the instrument. But this is a pain, because it means that you have both the subject matter expert (SME) for the likely cause of failure and the test developer working together to turn a one-off check into a run-once program - the SME interacts with the local instrument, showing the test developer what they want to know, then the test developer writes the script and runs it, showing the SME the report and how it got the various values. This is iterated on until the test developer understands what the SME meant to do, and then it's sent to the contract manufacturer, run there, and the report comes back. Repeat until the SME comes to a decision
Broadway
Remote instrument access
The bigger issue is that contract manufacturers are working for multiple companies at once, and want to tightly segregate them - I should not be able to get information about a competitor's boards being built at the same manufacturer as mine. That means that they are extremely leery of letting you have your own fibre-optic Internet link, for fear that you'll do something like put a WiFi AP on there that can be used by a secret camera to film the line when it's used for something else.
Remote instrument access