alt.hn

4/6/2026 at 8:20:54 PM

A macOS bug that causes TCP networking to stop working after 49.7 days

 https://photon.codes/blog/we-found-a-ticking-time-bomb-in-macos-tcp-networking

by RyanZhuuuu

4/6/2026 at 9:22:36 PM

I got tired of the AI writing before finding out if they even attempted to contact Apple about this issue? Does anyone know?

Also, massively over-dramatised. Yes, a bug worth finding and knowing about, but it’s not a time bomb - very few users are likely to be affected by this.

Knowing the nature of OS kernels, I’m guessing even just putting a Mac laptop to sleep would be enough to avoid this issue as it would reset the TCP stack - which may be why some people are reporting much longer uptimes without hitting this problem, since (iirc) uptime doesn’t reset on Macs just for a sleep? Only for a full reboot?

Anyway, all in all, yeah hopefully Apple fix this but it’s not something anyone needs to panic about.

by EdNutting

4/6/2026 at 11:11:30 PM

> very few users are likely to be affected by this

I have a reasonably strong suspicion that I experienced this a week or two back, on a MacBook that doesn't go into sleep automatically and quite likely had 50-ish days of uptime.

It had all the symptoms described - tcp connections not working while I could still ping everywhere just fine, and all the other devices on the same network were fine. Switching WiFi networks and plugging in to ethernet didn't help. A reboot "fixed" it.

by bigiain

4/7/2026 at 12:12:08 AM

Yep, I concur: this explains a bizarre behavior I’ve noted in my Mac laptops for ages now. I have a tendency to just suspend them without rebooting for ages, especially the work one that doesn’t leave my office as frequently. Periodically, I’d come in to find the system bizarrely frozen just as they describe: TCP stack blocked up, but everything else on it behaving normally. (Well, mostly: some apps would block starting and bounce eternally, but I suspect that’s because they’re trying to make a network call while starting up and it’s blocking.) The only fix was a reboot.

It’s not a disaster, but very annoying. At least now I can just schedule a reboot every 30 days at minimum to keep things running.

by castillar76

4/7/2026 at 6:48:48 AM

GP said that suspending without rebooting prevents the issue.

My uptime resets only when forced by an OS upgrade and I have never experienced this issue. This is consistent with the sleep-heals-the-stack theory.

by fingerlocks

4/6/2026 at 11:16:26 PM

I would not be surprised if people on HN were more likely to hit this issue than Apple's average users. We're a weird bunch ;)

by EdNutting

4/7/2026 at 2:34:08 AM

Can confirm at least on of us (me) is weird.

by bigiain

4/7/2026 at 10:25:31 AM

I think I might've hit my head on this a few times with my Mac Mini that's on basically 24/7 and doesn't go to sleep.

Sometimes it just stops networking completely, turning the wifi adapter on/off brings it back just fine. It's also a good time to reboot =)

by theshrike79

4/6/2026 at 9:26:23 PM

yes we have reported to Apple and they have filed it in their internal system.

by RyanZhuuuu

4/6/2026 at 10:26:04 PM

Did you need to make this blog post 20 pages long and have AI write it? Especially in such dramatic style?

Remember the golden rule: if you can't be bothered to write it yourself, why should your audience be bothered to read it ourselves?

by otterley

4/7/2026 at 2:41:43 AM

Might want to update it if you used the blog post explanation because it's incorrect as justinfrankel noted below. From the post:

    tcp_now   = 4,294,960,000  (frozen at pre-overflow value)
The mistake in the blog post is timer isn't wrapped, even though it notes it should be:

    timer     = 4,294,960,000 + 30,000 = 4,294,990,000 - MAX_INT = 22,704
Therefore:

    TSTMP_GEQ(4294960000, 22704)
    = 4294960000 - 22704
    = 4294937296
    = 4294937296 >= 0 ?  → true! (not false)
This is a bug of course, but it would cause sockets in TCP_WAIT state to be reaped anytime tcp_gc() is called, regardless of whether 2*MSL has passed or not. This only happens though if tcp_now gets stuck after 4,294,937,296 ms from boot.

A bug similar to what the blog described can happen however if tcp_now gets stuck at least 30 seconds before it it would have wrapped. Since tcp_now is only updated if there is TCP traffic, this can happen if there is no TCP traffic for at least 30 seconds before before it would roll over (MAX_INT ms from boot).

It's should be easy to prevent the latter from happening with some TCP traffic, though reaping TCP_WAIT connections early isn't great either.

by Aloisius

4/6/2026 at 9:26:16 PM

Apparently no. They'll be fixing it themselves? It really reads like Claude run amok on the blog.

> We are actively working on a fix that is better than rebooting — a targeted workaround that addresses the frozen tcp_now without requiring a full system restart. Until then, schedule your reboots before the clock runs out.

by delusional

4/6/2026 at 9:18:05 PM

Does anybody else find these AI-authored blog posts difficult to read? Something about the writing style and structure just feels unnatural, it's hard put my finger on it.

At the very least, the writing takes way too long to get to a point.

by tjohns

4/7/2026 at 12:01:51 AM

Same, AI written anything is really difficult for me to read and pretty exhausting.

by dawnerd

4/6/2026 at 9:52:46 PM

AI does a good job of condensing the blog post to 2 paragraphs -- Mac refuses to let the tcp_now clock rollover when it exceeds the max value in its data type.

by gowld

4/6/2026 at 10:16:09 PM

Can it summarize it down to a non-post?

by coldtea

4/6/2026 at 11:04:08 PM

Can it summarize this entire hacker news post out of existence?

by brianwawok

4/6/2026 at 11:04:57 PM

Use AI to expand your thoughts into a long-winded post, use AI to compress the long-winded post into something that can be digested by a human.

by nslsm

4/6/2026 at 11:18:55 PM

This but Gemini and Email - literally marketed as "write bullet points and Gemini will draft your email", followed by "received a long email? Let Gemini summarise it for you."

The world's most effective _de_compression technology for email - total waste of time and compute when combined, but each product would make sense in isolation if human-generated mail was the majority of email sent/received (except sadly it isn't). We're using AI to spam people, AI to detect spam, AI to write non-spam and AI to summarise non-spam. AI inefficiency at every level and no way back.

by EdNutting

4/6/2026 at 11:14:55 PM

Step 3) Sam Altman profits.

by bigiain

4/6/2026 at 9:11:54 PM

> It will not be caught in development testing — who runs a test for 50 days?

You don't have to run the system for 50 days. You can simulate the environment and tick the clock faster. Many high reliability systems are tested this way.

by mcculley

4/6/2026 at 11:09:34 PM

IIRC the initial value for the jiffies time counter in Linux kernel is initialized at boot time to something like five minutes before the wraparound point, precisely to catch this kind of issues.

by dezgeg

4/6/2026 at 11:11:31 PM

WinCE too

by bobmcnamara

4/6/2026 at 9:40:34 PM

It uses a hardware clock, one that pauses during sleep. There is no tick.

If you wanted to see how time impacts the program, you'd prob change fns like calculate_tcp_clock to take uptime as an argument so that you could sanity check it.

by hombre_fatal

4/6/2026 at 11:36:47 PM

Yes. I do mean designing software to make it testable.

The code that uses that value can be run in an environment where that value can be controlled.

I have written code that does this same thing and built a test harness for it.

by mcculley

4/6/2026 at 10:30:16 PM

We're talking about a company that produces the hardware their OS is running on. I'm sure they can find a way to make the hardware clock run faster.

by adamtulinius

4/7/2026 at 3:01:09 PM

Yeah, but if you're going to go through all that work because you have to foresight to test how clocks impact code, it would be simpler to stub and test the few functions that call the code (where the bug was). The bug wasn't in the hardware.

by hombre_fatal

4/6/2026 at 9:16:40 PM

Heck, many video games are tested this way.

by sho_hn

4/6/2026 at 8:47:30 PM

Sounds like it affects every open TCP connection, not just OpenClaw. (It's pretty rare for a TCP connection to live that long, though.)

by otterley

4/6/2026 at 8:55:14 PM

Individual TCP connections don't need to live that long. Once a macOS system reaches 49.7 days of uptime, this bug starts affecting all TCP connections.

by josephcsible

4/6/2026 at 9:14:44 PM

> Once a macOS system reaches 49.7 days of uptime, this bug starts affecting all TCP connections.

Current `uptime` on my work MacBook (macOS 15.7.4):

    17:14  up 50 days, 22 mins, 16 users, load averages: 2.06 1.95 1.94
Am I supposed to be having issues with TCP connections right now? (I'm not.)

My personal iMac is at 279 days of uptime.

by throw0101d

4/6/2026 at 9:24:12 PM

According to the post:

$ netstat -an | grep -c TIME_WAIT

If the count it returns keeps growing, you're seeing a slow leak. At some point, new connections will start failing. How soon depends entirely on how quickly your machine closes new connections.

Since a lot of client traffic involves the server closing connections instead, I imagine it could take a while.

It's unclear if it'll leak whenever your mac closes or only when it fails to get a (FIN, ACK) back from the peer so the TCP_WAIT garbage collector runs. If it's the latter, then it could take substantially longer, depending on connection quality.

by Aloisius

4/6/2026 at 9:26:04 PM 

    % netstat -an | grep -c TIME_WAIT | wc -l
       1

by throw0101d

4/6/2026 at 9:43:40 PM

You want to drop the wc -l.

Mac `grep -c` counts lines that match, so it always prints 1 line, so piping to wc -l will always return 1.

Or just open up and do netstat -an |grep TCP_WAIT and just watch it. If any don't disappear after a few minutes, then you're seeing the issue.

by Aloisius

4/7/2026 at 5:15:44 AM

They probably aren’t affected because the buggy code was only added in macOS 26:

https://github.com/apple-oss-distributions/xnu/blame/f6217f8...

by comex

4/7/2026 at 9:15:24 AM

Ouch - "every Mac" from the original post is a hallucination then.

I can live with the writing style when the topic is interesting (here it was for me) but complete untruths are much worse.

by pjjpo

4/6/2026 at 9:27:09 PM

You can run `sysctl kern.boottime` to get when it was booted and do the math from there.

I also can't reproduce. I want to say I have encountered this issue at least once, yesterday I before rebooted my uptime was 60 days.

But it's not instant, it just never releases connections. So you can have uptime of 3 years and not run out of connections or run out shortly after hitting that issue.

by 0x457

4/6/2026 at 9:22:05 PM

I'm just going from the bug description in the article, but it seems that depending on your network activity, the exact time you will actually notice an impact could vary quite a bit

by spogbiper

4/6/2026 at 9:23:25 PM

if it's in keepalive or retransmission timers, desktop use would mask it completely. browsers reconnect on failure, short-lived requests don't care about keepalives. you'd only notice in things that rely on the OS detecting a dead peer — persistent db connections, ssh tunnels, long-running streams.

by driftcoder

4/6/2026 at 11:19:07 PM

> 17:14 up 50 days, 22 mins, 16 users, load averages: 2.06 1.95 1.94

> Am I supposed to be having issues with TCP connections right now? (I'm not.)

If my skim read of the slop post is correct, you'll only have issues on that machine if it hasn't spent any of that time asleep. (I have one Macbook that never sleeps, and I'm pretty sure it hit this bug a week or two back.)

by bigiain

4/6/2026 at 9:01:11 PM

Sure they do. They need to live until torn down.

They almost never do live that long, for whatever reason, but they should.

by CamperBob2

4/6/2026 at 9:04:12 PM

I meant that having a connection live that long isn't necessary to trigger this bug. I know that for some workloads, it can be important for connections to live that long.

by josephcsible

4/6/2026 at 9:01:02 PM

Obviously, OpenClaw is now more important than anything else.

by gpvos

4/6/2026 at 9:08:27 PM

For OpenClaw this bug is a security feature

by mememememememo

4/6/2026 at 9:19:02 PM

have multiple macOS machines with 600-1000+ day uptimes, which do TCP connections every minute or so at a minimum, they are still expiring their TIME_WAIT connections as normal.

these kernel versions:

Darwin Kernel Version 20.6.0: Thu Jul 6 22:12:47 PDT 2023; root:xnu-7195.141.49.702.12~1/RELEASE_ARM64_T8101 arm64

Darwin Kernel Version 17.7.0: Wed Apr 24 21:17:24 PDT 2019; root:xnu-4570.71.45~1/RELEASE_X86_64 x86_64

so... wonder what that's about?

by justinfrankel

4/6/2026 at 9:30:36 PM

ah reading their analysis, there are errors that explain this. Particularly this:

  tcp_now   = 4,294,960,000  (frozen at pre-overflow value)
  timer     = 4,294,960,000 + 30,000 = 4,294,990,000
              (exceeds uint32 max → wraps to a small number)
timer wraps to a small number, they say

  TSTMP_GEQ(4294960000, 4294990000)
they forgot to wrap it there, it should be TSTMP_GEQ(4294960000, small_number)

  = (int)(4294960000 - 4294990000)
  = (int)(-30000)
  = -30000 >= 0 ?  → false!
wrong!

There may be a short time period where this bug occurs, and if you get enough TCP connections to TIME_WAIT in that period, they could stick around, maybe. But I think the original post is completely overreacting and was probably written by a LLM, lol.

by justinfrankel

4/6/2026 at 11:50:39 PM

There does appear to be a bug, but it's not what the blog describes.

If tcp_now stops updating at <= 2^32 - 30000 milliseconds, then TSTMP_GEQ(tcp_now, timer) will always fail since timer is tcp_now + 30000 which won't wrap.

This does look like it is possible since calculate_tcp_clock() which updates tcp_now only runs when there's TCP traffic. So if at 49 days uptime you halted all TCP traffic and waited about a day, tcp_now would be stuck at the value before you halted TCP traffic.

In cases where tcp_now gets stuck at > 2^32 - 30000, it looks like TCP sockets in the TIME_WAIT will end up being closed immediately instead of waiting 30 seconds, which isn't great either.

by Aloisius

4/7/2026 at 7:31:47 AM

Are you sure?

tcp_now’s maximum cannot physically reach 2^32 because the trailing zeros of that number exceeds the bit width of data type.

Therefore, tcp_now + 30000 will wrap when tcp_now is equal to 2^32 - 3000. Your inequality sign should be strict <, otherwise the result does not follow.

by fingerlocks

4/7/2026 at 6:47:23 PM

Yes, you are correct. Bad editing on my part.

It should be that if tcp_now gets stuck before (<) (2^32 - 30000) ms from boot, it would cause deadline timers for reaping TCP_WAIT would always be greater than tcp_now because it wouldn't wrap. If stuck at or after (>=) (2^32 - 30000), it would cause them to potentially be reaped faster they should be.

Actually looking at the code a bit more, it looks like calculate_tcp_clock() is run at least once per hour even when there's no TCP traffic or sockets open, so getting into the state where it never reaps TIME_WAIT sockets which would be hard to predict if this would happen.

It also looks like if tcp_now gets stuck, other tcp timers may have problems as well.

by Aloisius

4/7/2026 at 12:01:22 AM

yep that makes sense

by justinfrankel

4/6/2026 at 9:30:42 PM

The bug was introduced only last year in macOS 26:

https://github.com/apple-oss-distributions/xnu/blame/f6217f8...

by comex

4/6/2026 at 9:58:28 PM

> Apple Community #250867747: macOS Catalina — "New TCP connections can not establish." New connections enter SYN_SENT then immediately close. Existing connections unaffected. Only a reboot fixes it.

This is a weird thing to cite if it's a macOS 26 bug. I quite regularly go over 50 days of uptime without issues so it makes sense for it to be a new bug, and maybe they had different bugs in the past with similar symptoms.

by plorkyeran

4/6/2026 at 9:49:51 PM

Interesting. The article mentions complaints on the forums running Catalina, so that must be something else.

by Aloisius

4/6/2026 at 10:03:16 PM

As someone who also operates fleets of Macs, for years now, there is no possible way this bug predates macOS 26. If the bug description is correct, it must be a new one.

by js2

4/6/2026 at 9:59:29 PM

The article is written using AI, so unless you verified the complaints, the safe default assumption is that they don't exist.

by groby_b

4/6/2026 at 11:34:41 PM

This type of problem plagues all sorts of software. Having experienced this type of problem before, for Guild Wars game servers -- which run deterministic game instances that live for long periods of time -- we initialized a per-game-context variable that gets added to Windows GetTickCount() to a value such that the result was either 5 seconds before 0x7fff_ffff ticks, or 5 seconds before 0xffff_ffff ticks, so that any weird time-computation overflow errors would be likely to show up immediately.

by netcoyote

4/7/2026 at 4:11:21 AM

Yep, everything that relies on overflow needs to overflow soon after start, so that it's well tested.

by toast0

4/6/2026 at 8:36:34 PM

lol reminds me of the windows 95 crash bug after 49.7 days. Have we learned nothing. https://pipiscrew.github.io/posts/why-window/

by loloquwowndueo

4/6/2026 at 8:46:50 PM

I was just trying to remember where did I last see this magic number of days.

by aranelsurion

4/6/2026 at 8:49:05 PM

The article does mention a few instances found over the years, including the windows one. That’s the one I remember though because we used to joke it was not a big deal - the only way for a windows 95 computer to reach 49 days of uptime is if it’s literally not doing anything or being used in any way. Windows 95 would crash if you looked at it funny.

by loloquwowndueo

4/6/2026 at 10:09:41 PM

And throws in a Pac-man 8-bit level counter overflow just to remind us that AI cannot be trusted!

by StilesCrisis

4/6/2026 at 9:23:41 PM

OS/2 had a similar bug, and people used that as a server, so I'm sure it bit some people.

by flomo

4/6/2026 at 8:50:19 PM

49-7=42 it is all clear

by larodi

4/6/2026 at 8:39:11 PM

Quite literally "the new old thing."

by ok123456

4/6/2026 at 9:15:24 PM

probably same thing for boeing 787 jets - https://www.theregister.com/2020/04/02/boeing_787_power_cycl...

says 51 days, which would be an interesting number of (milli)seconds

by auspiv

4/6/2026 at 9:45:54 PM

It could be an overflow but related with the frequency at which the register was increasing, rather than the max value of te register. E.g. +1 this uint16 (65535) once every 500,000 cycles on this 32 Mhz chip, that previously was a 1 Mhz chip and never had a problem.

by otherme123

4/6/2026 at 9:32:32 PM

that's why the 49.7 days sounded familiar!

by znpy

4/6/2026 at 8:58:49 PM

What does this have to do with OpenClaw exactly?

by gghootch

4/7/2026 at 8:45:14 AM

Hmm?

torp@machinename ~ % uptime 11:43 up 59 days, 1:22, 4 users, load averages: 2.87 2.69 2.70

Sleep is disabled on that machine and it definitely had networking working fine last night.

Mac Mini M2, Sequoia.

Incidentally my laptop says 75 days uptime, but that one does go to sleep.

by nottorp

4/6/2026 at 8:38:26 PM

i'm on sequoia M1 laptop with uptime 16:38 up 228 days, 21:03, 1 user, load averages: 6.14 5.93 5.64

guess i'm marked safe!

by beanjuiceII

4/7/2026 at 7:45:42 AM

Interesting. I think I can confirm this. Got a Tahoe system with 55 days uptime that's mostly idling:

% netstat -an | grep TIME_WAIT | wc -l

850

All other systems with < 49.7 days uptime report low single to double digit numbers.

by AndroTux

4/6/2026 at 9:02:53 PM

This made me remember some folks that are "I never reboot my MacOS and it's fine!". Yeah probably it is but I'll never trust any computer without periodic reboots lol.

by MatMercer

4/6/2026 at 9:17:06 PM

I’m still at where when I connect external hard drive or SSD via USB, use it and then eject it, I shut down the MacBook Pro completely before I unplug the USB cable. Just in case.

The longest uptime I have had on any of my recent laptops is probably around 90 days but that’s because that laptop was sitting in my garage with wall power connected (probably bad for the battery) and some external storage connected and I’d remote into that machine over WireGuard now and then. When I did reboot that machine it was only out of habit that I accidentally clicked on reboot via a remote graphical session.

Most of the time my remote use of the laptop in the garage would be ssh sessions, but occasionally I’d use Remote Desktop. Right after I clicked reboot in the Remote Desktop session I realized what mistake I had just done - I have WireGuard set up to start after login. So after the reboot, I was temporarily unable to get back in. As I was in another country I couldn’t just walk over to the garage. But I do have family that could, so I instructed one of them over the phone on how to log in for me so that WireGuard would automatically start back up. You’d think this would happen only once, but I probably had to send family to the garage on my behalf maybe three or four times after me having made the same mistake again.

For the laptops that I actually carry around and plug and unplug things to etc, normal amount of time between reboots for me is somewhere between every 1 and 3 days. Cold boot is plenty fast anyway, so shutting it down after a day of work or when ejecting an external HDD or SSD doesn’t really cost me any noticeable amount of time.

by QuantumNomad_

4/6/2026 at 9:41:15 PM

> I’m still at where when I connect external hard drive or SSD via USB, use it and then eject it, I shut down the MacBook Pro completely before I unplug the cable. Just in case.

That sounds... a bit paranoid? At least on Linux (Gnome), if I click to "safely remove drive" it actually powers off the drive and stops external mechanical drives from spinning. No useful syncing is going to happen anyway once a hard drive no longer spins. A modern OS should definitely be reliable enough that it can be trusted to properly unmount a drive.

> For the laptops that I actually carry around and plug and unplug things to etc, normal amount of time between reboots for me is somewhere between every 1 and 3 days. Cold boot is plenty fast anyway, so shutting it down after a day of work or when ejecting an external HDD or SSD doesn’t really cost me any noticeable amount of time.

I personally don't reboot my laptop that often, but it's not because of a boot taking too much time. It's because I like to keep state: open applications, open files, terminal emulator sessions, windows on particular virtual desktops, etc.

by Delk

4/6/2026 at 10:55:15 PM

> A modern OS should definitely be reliable enough that it can be trusted to properly unmount a drive.

The problem isn't just in the OS side of the stack. Disk firmwares - especially SSDs - love to lie to the layers above [1].

[1] https://news.ycombinator.com/item?id=46239726

by mschuster91

4/6/2026 at 9:24:30 PM

$ uptime

22:22:45 up 3748 days 21:20, 2 users, load average: 1.42, 1.36, 1.02

It's very funny, I think it's because my laptop battery died and when I replaced it, it had to update the time from 10 years ago? I'm not sure why, as the laptop is from mid-2012.

by exe34

4/6/2026 at 9:31:54 PM

> 17:27:20 up 1112 days, 10:36, 50 users, load average: 0.20, 0.19, 0.18

I thought I had a record going here with my Dell laptop, but I guess you win. After a certain point, I just decided to see how long I can make it go.

by jasonjayr

4/8/2026 at 4:51:18 AM

50 users???

by MikeRichardson

4/7/2026 at 8:45:48 AM

I'm pretty certain I've run into this a couple of times now since upgrading to Tahoe last year and had been wondering what the deal was. Had never thought to check the uptime and make note of it, but I basically never shut down my laptop.

by cthalupa

4/7/2026 at 10:18:48 PM

How old is this bug? I can't imagine it exists on iOS or iPadOS; have those kernels really drifted that far apart though?

by NautilusWave

4/6/2026 at 8:50:56 PM

Exactly like arduino

by dvh

4/6/2026 at 10:24:13 PM

Wasn't windows 95 famous for having an issue like this?

by bawolff

4/6/2026 at 10:26:35 PM

Arduino too; I assume they all have to do with storing milliseconds in a uint32_t, and then getting unpredictable behavior when it rolls over

by guywithahat

4/6/2026 at 9:03:42 PM

Ctrl+F "OpenClaw". No results. Que?

by Philpax

4/6/2026 at 9:48:57 PM

Ignoring the AI article contents.

God I wish Apple offered first party support for Linux on Mac computers.

by apatheticonion

4/6/2026 at 8:48:52 PM

I only have 11 days left until my machine crashes and I lose all of my tabs.

by throw03172019

4/6/2026 at 10:09:32 PM

Nobody keeps their Macs running for more than 49.7 days? We have Windows Servers here (with long-term TCP/IP connections) that are only rebooted every 6 months to apply patches.

by fortran77

4/8/2026 at 3:54:48 PM

Macs that no longer get reboot-requiring updates by Apple usually have long(er) uptimes. :) My record here with my primary Mac mini was a bit over a year. Only to be forced to reboot because of a power outage.

Generally it feels like sometimes you boot into a stable "session" that can go on forever, but often enough you boot in a "session" and something goes wrong quickly and you'll have to reboot after a week or two. But I do experience the same with my Raspberry PI. :)

by binaryturtle

4/6/2026 at 10:15:31 PM

I rarely restart my Mac mini, and I have never had such an issue beyond my internet provider suddenly stopping properly working in the middle of the night.

by nalekberov

4/6/2026 at 9:00:28 PM

In case of OpenClaw, this is a feature.

by WesolyKubeczek

4/6/2026 at 9:06:43 PM

When some Russians do a prompt injection and OpenClaw is threatening to send your NSFW pics to Grandma unless you give it some Bitcoin all you have to do is drag out the negotiations for 49 days!

by 4fterd4rk

4/7/2026 at 6:53:32 AM

I’d be afraid the Grandma would send some of her own NSFW pictures right back.

by WesolyKubeczek

4/6/2026 at 11:13:52 PM

Orz! A kindly reminder for rebooting.

by revv00

4/6/2026 at 9:04:54 PM

too much words and text for simple thing..... probably written by openclaw

by cute_boi

4/6/2026 at 9:08:27 PM

I thought Alan Cox fixed all the TCP IP bugs in the early 1990s lol

by jijji

4/6/2026 at 10:12:31 PM

Did Alan Cox work on tcp? I thought he was working on memory and stuff.

That's what the wiki says anyway: [1], and a publication with his name is about huge pages [2]

[1] https://wiki.freebsd.org/AlanCox

[2] https://www.usenix.org/legacy/events/osdi02/tech/full_papers...

by toast0

4/7/2026 at 4:28:00 PM

Alan Cox of course worked on the TCP/IP stack:

"His involvement with Linux began in the early 1990s when he was working on a project that required a stable networking solution. This led him to discover Linux, which was still in its infancy at the time.

Contributions to Linux Kernel

Cox's contributions to the Linux kernel are extensive and far-reaching. He is best known for his work on the Linux networking stack, which was critical in making Linux a viable option for server environments. Cox identified and addressed numerous issues in the kernel's TCP/IP implementation, enhancing its performance and reliability." [0]

"For those not familiar with the Linux kernel contributors, Alan Cox wrote large parts of the networking stack, was the maintainer of the 2.2 branch, and was commonly considered the "second in command" to Linus Torvalds at one point: http://en.wikipedia.org/wiki/Alan_Cox" [1]

"Alan started working on Version 0. There were bugs and problems he could correct. He put Linux on a machine in the Swansea University computer network, which revealed many problems in networking which he sorted out; later he rewrote the networking software. [2]

[0] https://machaddr.substack.com/p/kernel-chronicles-insights-a...

[1] https://news.ycombinator.com/item?id=8548738

[2] https://web.archive.org/web/20200923003028/https://www.swans...

by jijji

4/8/2026 at 2:54:57 AM

Wrong Alan Cox for a kernel with the FreeBSD tcp stack from ~ 2000.

by toast0

4/8/2026 at 4:06:30 AM

So, you're implying that there is a second person named Alan Cox from Swansea, Wales who worked on FreeBSD, not Linux? Where is your source for that? lol

by jijji

4/8/2026 at 2:44:56 PM

You asked about Alan Cox, I said no, and provided links. You moved the goal posts to Swansea.

Alan Cox relevant to Mac is Alan Cox, professor(+etc) at Rice and well known FreeBSD contributor; no connection to Swansea, Wales, AFAIK. https://scholar.google.com/citations?user=z28ApZkAAAAJ&hl=en

I do see some networking stuff on there, but much after Apple forked tcp. I don't know that Apple took much memory management from BSD either. Most likely, neither Alan Cox is relevant to Mac.

by toast0

4/7/2026 at 1:18:51 AM

[dead]

by 486sx33

4/6/2026 at 9:11:26 PM

A ticking time bomb? What an overly dramatic way to talk about a bug that requires a reboot. Its not even a hard crash.

by awithrow