A tcp packet walks in to a bar and says “I want a beer”, barman says “you want a beer?” and tcp packet says “yes, a beer” .

In high society, TCP is more welcome than UDP. At least it knows a proper handshake.

A bunch of TCP packets go into a bar, until it’s overcrowded. The next day, half as many go in.

A bunch of TCP packets walk into a bar. The bartender says, “Hang on just a second, I need to close the window.”

When I try to send SYNs to chicks, I don’t get any ACKs. Just FINs and RSTs.

IP packet with TTL=1 arrives at bar. Bartender: “Sorry, can’t let you leave…and you don’t get any beer either…” 

The worst part about token ring jokes is that if someone starts telling one while you are telling yours, all joking stops.

The great thing about TCP jokes is that you always get them.

The problem with TCP jokes is that people keep retelling them slower until you get them.

I would tell some UDP jokes too but I never know if anyone gets them

The best thing about UDP jokes is that I don’t care if you get them or not.

I had a funny UDP joke to tell, but I lost it somewhere...

The sad thing about IPv6 jokes is that almost no one understands them and no one is using them yet.

I tried to come up with an IPv4 joke, but the good ones were all already exhausted.

A DHCP packet walks into a bar and asks for a beer. Bartender says: “here, but I’ll need that back in an hour!

DHCP jokes only work when there is only one person telling them

The worst part of SSH jokes is that, even when they're not funny, you suck it up and just pretend they were anyway.

The problem with token ring jokes is you need to wait your turn to laugh

I’d make a joke about UDP, but I don’t know if anyone’s actually listening…

AGE++;
TTL--;

Today users weren't able to sign up on our website in production.

The guilty code :

int ttl = 5256005760;

The first who find why will have a candy.

Forgot to post a book yesterday, so maybe I’ll post two books today...

Anyway, this book, I found it recently never seen it before. But boy is it great.

It’s similar to the programming pearls book as far as what it’s about. Think of the refactoring book, clean code, programming pearls, and the mythical man month books, thrown in a blender, added some new spice and some new things, and filtered down into 100 or so page book, simple quick and enjoyable actually.

This book the references staple books by Sedgwick, knuth, Brooks, Myers, and so many others. It’s funny how things come full circle.

My favorite quote from the book. I’ve been essentially saying this for years, but to see it on a book, it’s lovely... more people need to realize it too.

“Understanding how things work at a low level becomes a base for making good decisions at the high level”

Followed up with if you’ve never built a computer from scratch your missing out... get yourself a breadboard and some TTL logic.. and build a 4 bit CPU, once you know how to program in assembly the next step is building your own computer ... if your university didn’t teach a class that did this they ripped you off....

Don’t bitch at me.. the book said that.. and I agree! 100% because it’s true, you can’t debate that.

Oh and btw this is another book written by a female developer.. kudos to her for nailing so many topics in such a short book!

What is it with inabhorrent arrogance plastered all over IT as a whole?

I get younger, inexperienced people telling me I'm wrong constantly, criticising my work despite them having no clue (visible from their own work standard and TTL of their projects) .
Similar from older generation, who are resistant to change and aren't even part of my team telling me I'm doing my job badly.

I've been wondering why I have such big issues with DNS propagation on a website I moved - I just checked and somebody modified the old A record to have TTL of... 7 days.
Jesus fucking christ, why?

/**
* // sad truth to everyone focusing only on age++ part :) IN YOUR FACES!
*/
public void birthday() {
age++;
ttl--;
}

Aahhh, TTL 600, what a wonder

The lone wolf dies, but the packt survives.

10 minute ttl is too long!

Every time!

TL;DR When talking about caching, is it even worth considering try and br as memory efficient as possible?

Context:
I recently chatted with a developer who wanted to improve a frameworks memory usage. It's a framework creating discord bots, providing hooks to events such as message creation. He compared it too 2 other frameworks, where is ranked last with 240mb memory usage for a bot with around 10.5k users iirc. The best framework memory wise used around 120mb, all running on the same amount of users.

So he set out to reduce the memory consumption of that framework. He alone reduced the memory usage by quite some bit. Then he wanted to try out ttl for the cache or rather cache with expirations times, adding no overhead, besides checking every interval of there are so few records that should be deleted. (Somebody in the chat called that sort of cache a meme. Would be happy , if you coukd also explain why that is so😅).
Afterwards the memory usage droped down to 100mb after a Around 3-5 minutes.

The maintainer of the package won't merge his changes, because sone of them really introduce some stuff that might be troublesome later on, such as modifying the default argument for processes, something along these lines. Haven't looked at these changes.

So I'm asking myself whether it's worth saving that much memory. Because at the end of the day, it's cache. Imo cache can be as big as it wants to be, but should stay within borders and of course return memory of needed. Otherwise there should be no problem.
But maybe I just need other people point of view to consider. The other devs reasoning was simple because "it shouldn't consume that much memory", which doesn't really help, so I'm seeking you guys out😁

So I was very bored this week and deceided to get my head wrapped around Kubernetes and the hype around it. After trying to get a cluster run on my old contano servers I almost lose my nerve and just went for DigitalOcean. Holy shit I am impressed by the service. 30 seconds TTL DNS, hourly rate billing and spinning a scaleable cluster in only minutes. I fell in love