Live data from Hacker News

Reducing Tailscale’s binary size on macOS

tailscale.com

1–10 of 34 posts

Re: Reducing Tailscale’s binary size on macOS

#3
post #2

Generally on Apple platforms the move here would be putting the shared binary into a dynamic .framework rather then trying to eliminate the shared dependency. Is this a limitation of authoring it in Go that it has to be entirely static?

It could also be a legacy of a lot of the team coming from Google, which statically links everything except glibc.

Re: Reducing Tailscale’s binary size on macOS

#4
post #2

Generally on Apple platforms the move here would be putting the shared binary into a dynamic .framework rather then trying to eliminate the shared dependency. Is this a limitation of authoring it in Go that it has to be entirely static?

(I’m the author of the post)

The solution we ended up with was partially a matter of the minimum change to fix the issue, and partly because we have a lot of platforms to cover with a small team, so the fewer platform-specific concepts we have (frameworks in this case), the easier it is to maintain.

Re: Reducing Tailscale’s binary size on macOS

#6
post #2

Generally on Apple platforms the move here would be putting the shared binary into a dynamic .framework rather then trying to eliminate the shared dependency. Is this a limitation of authoring it in Go that it has to be entirely static?

As a user I’d prefer faster startup over shaving off a couple MB tbh.

Re: Reducing Tailscale’s binary size on macOS

#7
Guys, please figure out a way to reduce your footprint on openwrt.

11452 -rwxr-xr-x 1 root root 11.2M Sep 1 2021 /usr/sbin/tailscaled

7612 -rwxr-xr-x 1 root root 7.4M Sep 1 2021 /usr/sbin/tailscale

I love tailscale, but it forces me to use usb sticks on most of my openwrt routers.

Re: Reducing Tailscale’s binary size on macOS

#9
post #6
post #2

Generally on Apple platforms the move here would be putting the shared binary into a dynamic .framework rather then trying to eliminate the shared dependency. Is this a limitation of authoring it in Go that it has to be entirely static?

As a user I’d prefer faster startup over shaving off a couple MB tbh.

Even if so that takes benchmarking on the target systems. Linking can be fast compared to reading a few extra MB from disk.
Post reply on HN