This is amazing! Most definitely headed in the right direction.
The separation layer between front and back must be cut at the smallest possible 'slice'.
Lots of people here snarking would understand if they 'felt' the latency and additional overhead. Not enough thought has been put in carfully slicing the data for individual use cases.
I'd go even further, in his demo of 'generating load by moving the config often' -- I think that 'top' app should have 'jit-ed' more of the rendering on the client such that the only information traversing pi<>client is compresed delta's of the ps hose.
Yep, I made my own! (Xoogler 2017-2023) this is my noogler IDE story, one of my favorite, proudest hacks!
I developed a fork of the IntelliJ IDE on my second week at google out of raw frustration over latency.
At the time I was commuting 2-3hrs/day SF<>MTV on the gBus.
Connectivity on the bus wasn't optimal, and there was high latency. Cider didn't have deep integration, and wasn't able to let me explore and understand the internal APIs effectively. I found it easier to enter a debug session within Intellij then 'vibe' and explore the internal apis via superComplicatedObject.ini<tab>.
Faced with an alien architecture + ADHD-unfriendly flow-crushing remote desktop latency -- and the lack of discoverability, I started hacking at it and without any knowledge of the system and architecture. Just tracing Intellij execution, subprocesses and network calls.
I was able to hack together a prototype in a few days that allowed me to run IntelliJ on my Mac, while the heavy bits ran on my corp desktop. The system would mount the remote filesystem over sshfs, would monitor and patch network connections and setup transparent shim binaries. Half of Intellij was running on the Mac (the front end) and the other half ran on Linux. Intellij didn't "know" that that it was running on a mac. This was initially implemented in a ~250 line shell script that patched everything.
It was called MDProxy[1] and ended getting adopted and supported during COVID as more development went remote. This became a source of many peer bonuses and spot bonuses. circa 2017* remote coding options at the time:
typing | code
latency | integration
--------------------------
cider low | meh
mdproxy low | great
ssh+vi med | meh
rdp+iJ crushing | great
Dude I was there 2019-2022 and mdproxy was a huge win when I realized I could work while traveling. I remember following some incantations on someone’s personal page to get it running. Then covid happened and I was ahead of everyone for a few weeks because I already had been doing real work on my laptop. Thanks!
Yeah, I was working out of the Sydney office. Almost everything was incredibly slow due to that latency, not just chromoting but also just accessing most sites through beyondcorp.
oh wow! that sounds awesome! (I guess I left around the time you were starting)! I was based in LAX (so no G-Buses for us, but I had to visit MTV often - like once twice a month, and enjoyed getting on one of them)). Kudos!
I’m surprised you find ssh+vi having medium typing latency. I have ssh’ed to either my desktop to (later) my cloudtop and latency has always been great. The ssh latency is good enough that I can run X forwarding to launch graphical instances of emacs and gvim. The latency was basically unnoticeable.
Later I rented a vacation home in South Lake Tahoe and worked remotely. It was only then that I realized it had terrible latency.
latency on the gBus was at the time ~250msish but would regularly spike much more on certain sections. Each keystroke would have to roundtrip before appearing on the screen.
Using something like mosh would mitigate it, but there was no UDP tunnel available through beyoundcorp.
Cider and MDProxy were running rendering locally so the keystrokes were nearly instant.
i registered for their demo and it seems to be unable to do any of the advertised features. nearly everything crashes; feels like a ux wireframe not yet wired it
That's strange. I use it daily myself and some of my clients do too (to communicate with me). The main tools work reasonably well for us. There are definitely rough edges and bugs still, it's a one-person project.
