The modern Terminal is based on a private fork of Chromium to give it the look and feel of a VT100 terminal, and integrate their private networking and security technologies. The BBT predates HTTP, and backwards compatibility is hugely important to the company- they have a museum where a second-generation Terminal from ~1985 shows the current news, because they are so dedicated to backwards compatibility that they still can support the 1985 hardware.
This isn’t really true. The old terminal monitors are essentially dumb CRTs and the the museum pieces are just displaying the output from a regular PC running the modern app converted to an appropriate signal + BNC connectors so you see something and not just a black screen.
The old terminal hardware communicated over dedicated serial lines and worked in conjunction with many other “server-side” pieces of software that no longer exist, so it would be impossible to make one function as it did back in the day.
I would love to learn the specs of the original 1983 terminal. By the look of it, it's NTSC timings, so 200-ish lines, but it shows text and graphics, so it must have some bitmap capability. If I were to replicate the look, I'd use something that can display ReGIS or NAPLPS.
They ran iRMX on an 8080 variant and had graphics card that handled the A/V aspects. I suspected the displays could have actually been PAL because it had slightly higher resolution, but I haven’t been able to confirm that yet. I have one of those “Smithsonian” pieces on my desk waiting for me to have to some free time to try to repair the CRTs when I someday have more free time than I do now (any good resources for that??).
Hey Andrew, former BB employee here. What's the dev experience like over there now? Back in 2011 when I left, RnD was leaning heavily on the custom JavaScript + IDE for frontend dev, and mostly cpp and non-relational mmap DBs on the backend.
How have things evolved?
So much has changed since that time. There's a great recent talk by Jason Williams and Paul Williams that goes into a lot of detail [1]. Most things now use TypeScript developed natively in VS Code using extensions and a CLI for the additional proprietary bits. That all nicely integrates with agentic workflows, skills, etc. ComDb2 is very relational, very battle-as-in-jepsen-tested and has been open-source for a long time now [2]. C++ is still king, but there's plenty of Python, Go, Rust, Haskell, OCaml, etc. running around.
Ok, lemme ask you this: What has been your favorite Bloomberg keyboard over the years? I preferred the mid-2000s mechanical keyboard before they started going lower profile keys, which suffered from off-center binding when pressing near the edge of a key.
mandevil · · focus · HN ↗
apaprocki · · focus · HN ↗
The old terminal hardware communicated over dedicated serial lines and worked in conjunction with many other “server-side” pieces of software that no longer exist, so it would be impossible to make one function as it did back in the day.
rbanffy · · focus · HN ↗
apaprocki · · focus · HN ↗
rbanffy · · focus · HN ↗
ryen · · focus · HN ↗
apaprocki · · focus · HN ↗
[1]: <a href="https://www.youtube.com/watch?v=y1MCLZm8yAY" rel="nofollow">https://www.youtube.com/watch?v=y1MCLZm8yAY
[2]: <a href="https://github.com/bloomberg/comdb2" rel="nofollow">https://github.com/bloomberg/comdb2
ryen · · focus · HN ↗