Then what would you do? serial port? ssh? what is your terminal connected to if you don’t have an OS?

Serial port or serial port over "ethernet"[1] (technically it's 8p8c[2]).

My router doesn't have a video port, but it does have a dummy terminal port. I had to scrounge a video card for my server to set it up, but it does have a serial port [3]. So that would have been nice.

Also would be nice for a modern remake of dumb terminal with abandoned monitors.

[1] https://www.cabling-design.com/references/pinouts/EIA-TIA-56...

[2] https://en.wikipedia.org/wiki/Modular_connector#8P8C

[3] https://serverfault.com/a/529159

It doesn’t (look like a go layout) and that’s a good thing because pkg/ src/ etc aren’t good go directories.

Since go 1.25 you can declare the what is the “root” of a go module, which is a good thing. Not everyone wants the top level directory filled with go files specially in a multi language repo. So this idea that /src is not good go directory will soon be outdated.

MQ shines in async calls/event delivery. gRPC / http2 / websockets / thrift is better for synchronous calls ?

With the ISO/oasis standard AMQP you can actually do synchronous calls without an intermediary. You also have 'direct' message routing capability with components like apache qpid dispatch router.

I can't see a reason why one would use gRPC/thrift and then having to build flow control, delivery guarantees and other messaging features yourself.

gRPC is built on http/2. I imagine it supports flow control and delivery guarantees already? It's just http/2 + protobuf

My understanding iz ZMQ is a messaging/rpc mechanism while WDT is aimed at large data transfers (though it also works well with lots of small data as it's streaming)

Also I don't know that ZMQ uses multiple streams ?

bittorrent is optimized for sending to many and across peers. for fastest data transfer the time it takes to read the data is the bottleneck once the network is optimized, so hashing before sending would be more costly (for a 1:1 copy)

we are considering 1:many case for future development but there are tools (like bittorrent) which already excel at this

Facebook internally use SDN which hashes source host/port destination host/port to pick paths. By using multiple connections on independent ports we do get multiple path utilized and can thus get better reliability and throughput if some are less healthy than others.

http://udt.sourceforge.net/ is a solution using UDP but we decided that TCP with multiple flow was a better tradeoff for us (not to reinvent most of the window, congestion control, etc... of TCP)