None built in from what I recall. That was from back in 2011, so it’s possible things changed since.

Reading through, it looks like retries do exist, but remember that duplicate packets are treated as a window reset, so it’s possible that transmission succeeded but the ack was lost.

I remember the project demos from the course though - one team implemented some form of fast retry on two laptops and had one guy walk out and away. With regular wifi he didn’t even make it to the end of the hall before the video dropped out. With their custom stack he made it out of the building before it went.

I’ll need to dig through to find the name of what they did.

To be fair, because of window size management it only takes 1% packet loss to cause a catastrophic drop in speed.

Packet loss in TCP is only ever handled as a signal of extreme network congestion. It was never intended to go over a lossy link like wifi.

Seriously though - JIRA isn’t always a massive pain in the ass. It’s just the way it’s used that sucks. Workflow restrictions so devs can’t move tickets from testing back to in progress, dozens of mandatory fields, etc.

When your tools start dictating your workflow rather than the other way around then it’s time to switch tools.

Friends don’t let friends use JIRA

I have either written or gotten a variant of every single one of these comments 🫠:

Please include the JIRA task in the commit title.

Did you run any manual testing?

Where’s the PRD link in the commit message?

Can you please split this into multiple smaller commits?

Can you combine these two commits?

Did you email Jon about this because he’s working on that project with Sarah and you might be duplicating efforts.

This should be named BarFoo instead of FooBar.

Why aren’t you using CorporateInternalLib16 that does 90% of this?

Why aren’t you using ThirdPartyPaidLibByExEmployee?

Why aren’t you using StandardLib thing you forgot existed?

All our I/O should be async.

All our hot loop code needs to be sync.

This will increase latency of NonCoreBusinessFlow by 0.01%. can you shave some time off so we can push in feature B also?

Please add a feature flag so we can do gradual rollout.

What operational levers does this have?

Lgtm - just address those comments

So to be clear: you didn’t laugh?

Well? Do you have any grapes?

Well? Do you have any grapes?

Older C compilers would truncate a variable name if it was too long, so VeryLongGlobalConstantInsideALibraryInSeconds might accidentally collide with VeryLongGlobalConstantInsideALibraryInMinutes.

Legend says that they used to do it after a single letter with Dennis declaring “26 variables ought to be enough for anyone”.

Red circles are deprecated in favor of teal because of accessibility requirement WIP.DOnotUSE.14.g.2025.v0.

They started from XML. There’s nowhere to go but up but spring managed to fuck even that up.

FactoryStrategyFactoryFactoryObserverInterface

Friends don’t let friends use Java 😜

Whoosh

Seriously though, spring configurations are written in XML and you create variables, call functions, and have control flow. Effectively turning XML into a horrible twisted shadow of a programming language.

All in the name of “configurability” through dependency injection.

XML is the second worst programming language ever created by humans

Don’t make the mistake of anthropomorphizing Larry Ellison

This is a shit shitpost post shitpost.

And here I was thinking that adding timezones for mars was going to be the biggest timezone headache in the next 5 years.

TCP Selective Ack is very much a thing, but it does take extra memory so lots of TCP stacks exclude it or disable it by default.

TCP was never designed with wifi in mind. TCP retransmission was only ever meant to handle drops due to congestion, not lossy links.

Tmux is a wonderful complement to mosh. Together you get persistence even when your local client loses power (speaking from experience)

I worked with mosh for years to connect to servers on other continents. It was impossible to work otherwise. It only has two small warts: forwarding, and jump hosts.

The second is fixable/ish with an overlay network, but that isn’t always an option if you don’t control the network. I tried to solve this with socat but wasn’t able to configure it correctly - something about the socket reuse flag was very unhappy.

Also that in order to exploit this it requires an active man in the middle. Which requires any of the following:

• Reverse proxy hijack/NAT hijack - from a compromised machine near the server
• BGP hijack - stealing traffic to the real IP
• DNS hijack - stealing traffic to send to a different IP
• Malicious/compromised network transit
• Local network gateway control
• WAP poisoning - wifi roaming is designed really well so this is actually easier than it sounds.

Almost all of those have decent mitigations like 801.x and BGP monitoring. The best mitigation is that you can just change your client config to disable those ciphersuites though.