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?

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.

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.

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.

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.

yep that makes sense

The bug was introduced only last year in macOS 26:

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

> 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.

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

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.

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

It definitely exists, but it could be a completely unrelated issue.

https://discussions.apple.com/thread/250867747

+1 here -- Mutsu are fantastic, readily available at NYC greenmarkets in the fall and into the winter, though there are pretty large differences in flavor and texture between various orchards too. Samascot is my fav.

If you have an Apple Silicon mac you can install Win11 in UTM and it works great for dev purposes. Can get the free builds via Windows Insider, too.

I would recommend getting an official consumer build to test all of the latest consumer features like Copilot

Parallels has a Microsoft partnership and has an official AMR64 image which I was able to grab (and run in anything). I’m sure there are a lot more now, though!

except: 1) avoid the possibility of head injuries, and 2) if you suffer more than slight symptoms from daily routine, dial it back

While avoiding head injury is a good path to pursue, sometimes the head injury finds you.

It can take very little whiplash of the skull to cause a concussion.

Sure, but there's only so much you can do to avoid such risks. We control the risks that we can control; the rest is up to luck.

Sure, it doesn't take much. But most people's active daily routines don't result in frequent head trauma.

Or you can be walking safely outside and get hit by a car

or you might have an alternate prefix for "things that go in development build changelogs but not final changelogs", e.g. "-"

you can also install reaper and this plug-in and get something highly winampish with its own special authenticity:

https://landoleet.org/reaplay.zip

fwiw dro’s been around a long time and i would be inclined to trust them :)

Yes, Exactly, Yes!

:) Thanks

Is plain win32 API supported on arm64/Windows? Is there a version of MSVC? Or does one use mingw?

Hello,

Win32 is supported with MSVC just fine.

You can also use MinGW with LLVM (not MinGW with GCC), available at: https://github.com/mstorsjo/llvm-mingw

Win32 is supported, and a supported tool chain comes with Visual Studio.

> I’m not highly conversant with ARM linux, but in my mind I imagine it’s still largely a second class citizen

IMO ARM linux is great, the real thing lacking is good hardware to run it.

Yeah, I tried out a Raspberry Pi 4 as a desktop replacement and pretty much everything is supported except for proprietary stuff like games.

Eh... that was not my experience: https://www.jeffgeerling.com/blog/2020/i-replaced-my-macbook...

(Unless you're speaking almost entirely of webapps, which mostly run fine even on the measly 1.5 GHz 4-core Pi ARM processor.)

I think most of the gripes described are really issues that come from moving from a MacOS desktop to try a Linux desktop; if you were moving from a x86 Linux desktop to the Pi the experience would have been much less painful.

You are stating in step #2 that the Pi4 cannot output 4k at 60Hz. Could you please insert a footnote that it actually can?

https://www.raspberrypi.org/documentation/configuration/hdmi...

I meant everything that runs on x86 Linux. Of course iMovie and Adobe stuff doesn't work, lol.

I had an ARM Chromebook for a while (around 2016) that I customized with a 256GB SD card and Linux Mint. The software all worked well, but the WiFi card died after a year and effectively bricked the damn thing. Cross-compiling might be an issue, but that's not a primary use case.

You mean all the Android handsets? The history of Linux on ARM is colorful, full of corporate missteps and giant brands (namely HTC and to lesser extent Samsung) that were created from that.

None of them come close to the performance Apple achieves on their chips.

"Interesting to see that it took 15 years to get where he is today."

If I had started it in 2000 it would've taken 20 years to get to where it is (OK fine, would be) today...