Ask HN: Viable tech for hotdesking in software dev?
Anyway, part of this idea involves moving between areas or projects. Laptops are one obvious answer - possibly outfitting desks with additional monitors, equipment as necessary. However we build fairly chunky (large) enterprise systems and sometimes running databases, FE tools, BE tools and the app (which might consist of a few components/services) takes a lot of resources. In terms of performance, battery considerations, upgradability and cost, desktops have many advantages. Point being, for the cost of a killer laptop, the corresponding desktop machine wipes the floor with it and I'd favour the responsiveness and performance.
My question is, is there a viable tech solution to facilitate modern (backend/fullstack) software development using some remote access/terminal arrangement. In the same office - gigabit LAN etc - with dedicated machines hiding in a cupboard or rack somewhere. BE/fullstack dev is currently in Windows land.
I guess for me that means working with multiple monitors and ideally multiple desktops.
In years gone by I've seen Citrix, terminal services, RDC, VNC.. but I'd like to know if it's viable for software engineering itself, and what kind of issues might crop up. Is the tech viable?
(Struggling to find an appropriate place to ask this question. Forgive me if this is off-topic for an Ask HN, but it's about efficiency in a growing team of hackers.. if I can swing it that way!)
35 comments
[ 5.5 ms ] story [ 914 ms ] threadHave you considered personal workstations on movable desks as apparently used by Valve?
The most practical option is just give people the hardware they need, then facilitate their comfort and mobility accordingly. Desktops and laptops being used simultaneously at the same desk is very common. I'd also suggest desks with wheels.
As far as remote solutions for your situation, I don't think there are any acceptable ones. Low-latency video streaming wouldn't even cut it. Personally I'd limit myself to solutions that actually run the display signal itself. There might be some clever things you can do with the latest versions of Thunderbolt/USB/HDMI/DisplayPort; I'm not fully up to speed.
If you do end up theorycrafting that approach, one additional point of consideration might be virtualization with direct hardware passthrough. You could probably do some cool things like assign one GPU per hotdesking location, and pool any unused GPUs as computing resources. Storage could be a similar story, with neat separation.
That said, running your own on-premises AWS can become very complicated and very expensive. I wouldn't go that route unless you're really, really set on the hotdesking thing.
Generally (I was on an interview bender recently) I see desktops with raised monitors ganged together (either displayport or hdmi supports daisy-chained monitors) and a keyboard and everyone is issued a lightweight laptop and defers all the beef to the cloud/vm farm.
I keep going back to windows remote desktop as really the best remote desktop solution. It supports multiple monitors, and if you are a Windows environment with an AD you can roam from desk to desk trivially.
The main hassle would be switching everything; you could build a signal switcher(/multiplexer!) using FPGAs, but that would be expensive and take ___quite___ a while to do.
In fact as an industry we're moving to IP - a modern video stream is in the 12gbit range, so that's a backplane of about dozen terabit, so that's not cheap either. On top of that, 1 lost packet and it's a big problem, so we dual stream it all.
I think I've seen the coax pools for 1k>1k units in cabling pictures online... these would _start_ at 5 figures, I presume, with full installations probably even rolling into 6 figures?
And... double wow, 12Gbps. Is there nothing like a realtime, lossless, zero latency compression scheme that works for video? Hmm, Huffman coding would probably only chew off a few Mbps, and not make much of a dent.
It sounds like video transmissions run over UDP. That's kinda insane... but TCP wouldn't work either, I'm guessing the transmission format is probably so closely tied to the wire protocol that repeated frames would give everything major indigestion too.
This has been a cool TIL
We use SDI rather than HDMI, but fundamentally it's a container, with an active picture frame in 4K video of 2160 lines, with 3840 samples per line. Each sample is a 10 bit sample of the luma, and every other sample gets 2 extra 10 bit samples of chroma (The eye being less sensitive to chroma). This is 4:2:2 sampling.
This means that a single 4K frame is 2160x3840x20 bits, and in the americas there are about 60 lots of 165mbit, every second. SDI adds various things like blanking thanks to it's legacy of a digitised version of PAL/NTSC. Audio is tiny, <15mbit/sec.
Normal HD, with interlacing, is far more reasonable, at 1080x1920x20x30ish, 1.2gbit (less in 25fps countries), but SDI adds another 300mbit a second on top of that (UDP/RTP also adds overhead too).
The cheapest SDI routers you can get tend to be blackmagic ones, which are fine. There's a lot of people in the industry that remember the days of analog routers, where they were legitimatly expensive. Since SDI came out thought the electronics is little more than a switch chip. A 40x40 matrix will cost about $1300, but prices increase exponentially.
On wan links we tend to use compressed video in the 5-30mbit range (5mbit from somewhere skanky with poor internet). We have forward error correction on that, but the standards aren't great at high bit rates (only coping with 25 lost packets). A 20ms outage on a line with that type of error correction causes on air disruption.
Using something like ARQ which allows missing frames to be repeated adds latency, on a link from Europe to Singapore for example it could add 600ms. That's on top of the c. 100ms propagation latency and 400ms encode/decode, pushing the latency from half a second to over a second, and people start getting grumpy. There's still no guarentees either - as if you were to lose 100ms of traffic at 30mbit, you end up peaking your traffic far higher than the 30kbit/ms that you normally send -- to retransmit that 100ms in 100ms, you need to peak at 60mbit.
As an example of how important latency is for two-way communication, I'm currently investigating replacing our 12 frame (480ms) latency encoders from a couple of locations in London with ones that run at about 1-2 frames (40-80ms).
With wan links sending the same packet on two links doesn't even work. I've seen outages of 20ms on both a private wire and two separate internet paths in the past -- presumably some common router in the subsea cable system does something. Currently using temporal shifting (and some receive buffering) as well.
The expectations that the broadcast industry place is somewhat different to the IT industry. 3 second end-to-end latency is nearer 'store and forward' than 'low latency'. Compression in a production facility is unacceptable, and increasingly we're moving away from things like 5:1 compression on wan links and bandwidth becomes cheaper. One broadcaster in the UK has just replaced the main in-country network with an uncompressed network based on multi-path 100gbit wavelengths running over dark fibre. Another has replaced it's core switching network with multi-terabit backplanes. Just getting 10gbit/second in/out through the kernel is a challange - doing it with nanosecond packet timing that the next SMPTE standard currently requires is proving even harder.
I'm not entirely sure what you mean by "1920x1080x20x30", particularly the "20". I take the "30" to mean 30fps.
SDI rings an "I've heard of that!" bell. Huh, 37MB/s of overheard - nice. :(
I get the impression analog routers/multiplexers were basically every input port physically wired to every output port, with a tiny switch to disconnect the lines that weren't being used. Yeah, those would be exponentially expensive, because even though you can't physically have more than one input going to a given output (outside of practical special effects, maybe?), you can't get away from physically wiring all inputs to all outputs. And then I'm guessing the sea of internal wiring was all super high quality and so forth to minimize line losses...
40x40 for $1.3k is _very_ impressive. But yeah, it's just a specialized ethernet switch (albeit with really high maximum internal throughput), so that makes sense. The switch from analog to packet switched routing does make sense financially.
Hmm. What did everyone use after everything went digital, but before the switch to packet switching? What video formats got used back then? What time period am I even describing? I just realized I've always been mildly curious.
TIL about ARQ, and what to call what I've been using in my own messaging system design ideas. I do wonder though... in the context of video distribution, if you just repeat the last good frame you had if you don't get the next frame in time - why does there need to be realtime acknowledgement at all? Instead of acknowledging every single frame (I assume this is how current systems work), either send periodic beacons containing the last eg 10 or 100 or 1000 last message IDs, eg [ 1, 3, 8, 9, 10, 13, 17, 20, ... ] so the sender compute the number of frames dropped, or even better, if frame IDs are guaranteed to be sequential, the receiver can compute the number of dropped frames and simply just ping back the packet loss percentage value. That would take care of the sender blindly going too fast a la TCP rate control. Then, on the receiving end, if the receiver doesn't get the next frame in time for playback system to show it, it just shows the last received frame until it has a new one.
I get the impression ARQ works a bit like Skype on a bad day, where the feed locks up periodically then the image jumps forward in time (if you will) when the next properly decodeable frame comes in - except I suspect ARQ only has very tiny such jitters and jumps. What I just described would probably be equivalent, but (unless I'm horribly mistaken, or misunderstand) with much lower latency.
Note - I realize the way things are already done were carefully engineered and there are good reasons behind the techniques currently being used. I presume that the above idea has very possibly been thought of and disregarded - and I'm curious what the reason was.
400ms encode/decode is impressive. 40-80ms even more so. But that sounds perfectly reasonable given that this uncompressed video; I expect the faster encoder simply has faster silicon in it :)
TIL about the info about the traffic peaking and retransmission. That was interesting to carefully read through a couple of times :)
Talking about encoders and distances, that reminds me - I'm curious about how good those cellular backpack things are, the ones that take umpteen SIMs and seemingly set up a load-balanced aggregate connection over all of them. I'm guessing the latency is somewhere north of "higher than planes fly"? :P
What did you mean by "temporal shifting" in the context you used it? I also wonder what the traceroute on the private wire would have looked like. I can't imagine the link was tunneled (haha!) so if nothing showed up that would be perplexing.
I remember when satellite links used to have 3 second delays to TV live news broadcasts, only around 2006-2008 or s...
Otherwise, modern high-end laptops are quite powerful if you pick the large models not 13 inch thin ones, and you can certainly run a bunch of virtual machines/docker containers/whatever on a maxed-out laptop while it still being perfectly responsive; but you might want to have people running both a killer laptop and a beefy desktop if they're not deploying/running/testing everything on remote servers, the cost isn't that high.
https://www.amazon.com/Mount-Adjustable-Universal-Computer-H...
I don't have a solution for multiple buildings, you're right about that.
https://www.joelonsoftware.com/2006/09/07/a-field-guide-to-d...
If everybody cares, then as you note, not everyone agrees that it's good. If few or no people care, then why hotdesk?
Either way, someone has to set the policy. Even at Valve, with no structure, someone has to say "we hotdesk, it's our culture". Someone has to sell the haters on it (or tell them to take a hike).
And even if only one person hotdesks, depending on that person, that could still be enough to leave an impact.
> Why does your desk have wheels? Think of those wheels as a symbolic reminder that you should always be considering where you could move yourself to be more valuable. But also think of those wheels as literal wheels, because that’s what they are, and you’ll be able to actually move your desk with them.
> You’ll notice people moving frequently; often whole teams will move their desks to be closer to each other. There is no organizational structure keeping you from being in close proximity to the people who you’d help or be helped by most.
> The fact that everyone is always moving around within the company makes people hard to find. That’s why we have http://user — check it out. We know where you are based on where your machine is plugged in, so use this site to see a map of where everyone is right now.
https://www.eclipse.org/che/
[1] https://www.spice-space.org/
Additionally, teams may want to rearrange desks (e.g., in a circle, or back-to-back, or whatever). There's no reason not to have flexibility here.
You'll find that most people will still accumulate stuff, and will need some kind of storage. People also get attached to their chairs and their working posture (sitting/standing, monitor height) as well as their particular keyboard and mouse brand, etc. -- hot-desking seems bad for this.
You can trial it quite simply. All you have to do is have user login network mount a home dir and you are in business.
In general laptops cost quite a bit, break lots, and people want to take them home which creates issues. I think a lot of companies just give developers laptops now. However, it can be quite nice for the developer to have "not at work = down time" as an option, larger screens and keyboards are generally smiled upon, and desktops are WAY CHEAPER. You can even go 100% diskless.
PXE is usually centrally supplied kernel vs. individual developer compiled kernel, though, which can be annoying if people want funky features. However, you can do this diskless as a default and just say those who want to sidestep the system can boot from an external SSD.
Just to be clear, if you're already running Windows, RDP is free.
Don't fall in the trap of voip phone systems that don't allow you to be logged in two places at once (usually for licensing reasons): someday you (or your colleages) will be hunting for the voip phone that someone forgot to logout.
For remote desktop, etc. This is a very mature technology: try to pick the tech that better blends with all the other tech stach at home. Citrix, for instance works great but it ecosystem is not trivial the best part is they even have an integrated VPN (Netscaler) you can use.
On the hardware side, take a look at HP Moonshot servers. I bet there are equivalents our there from other brands, but those are worth seeing: 4.3U servers that can house 50+ physical desktops with own storage.