> You contribute to projects run by others with the understanding that others run the project, is this not the default assumption others have too when contributing to FOSS?
There are certain unspoken rules you don't break out of a of tradition of process and decorum — this decision broke that rule, overturning 5+ years of accrued experience and institutional memory, so I can understand why this might feel like a rugpull which would reasonably upset the average contributor.
These antics are acceptable in a BDFL project where the stakes are low, but try this in an actual major project with thousands of contributors and see how it goes.
I think the best case scenario I can think of is the microsoft typescript js->go conversion, whereas the bun zig->rust is probably the worst case.
I wrote a multi-page essay about this for our condo association last year. There's lots of complexity and externalities here — Pepco grid modernization, PJM interconnection cap auctions, AI buildouts in NOVA, etc; it's a really complicated issue.
That sounds like it would be a huge asset for other people making these considerations in their own communities. Would you be open to sharing your work?
The US app is still laggy (even on the iPhone 17 Pro) and constantly logs you out. My theory is that they set the login timeout to a low number to make it harder to accrue points.
> ability to stream US TV when abroad (by exiting from my home network)
Should note that Tailscale does not work natively with hdhr for mpeg television streams b/c wireguard doesn't natively support udp multicast/broadcast. Also can't directly port forward b/c hdhr sets a default ttl of 2.
My understanding is that most VPNs in general don't support udp multicast due to operating on the network layer rather than data link, though iirc OpenVPN supports multicast traffic through its virtual TAP (Layer 2) rather than TUN (Layer 3).
Tailscale does create a TUN/TAP virtual network[0], though udp multicast is still not natively supported.
By 'stream US TV' I assume they just mean using popular streaming services like Netflix. If that's the case, than UDP multicast packets aren't involved at all, since it's all unicast.
Your advice would apply if they're using a local TV tuner or IPTV setup to share live TV on the local network or something, but that seems unlikely. But for content coming from mainstream Internet streaming services, it's good bet they're not using multicast.
I stopped reading when I realized it wasn't a deep dive into the most interesting question I had, which is the technical hardware design process and finding a factory to actually take your design and manufacture it.
I noticed this and modified the .car to just make window corners sharp. It looks a bit jarring, but functionally speaking, it feels like a big improvement.
There are certain unspoken rules you don't break out of a of tradition of process and decorum — this decision broke that rule, overturning 5+ years of accrued experience and institutional memory, so I can understand why this might feel like a rugpull which would reasonably upset the average contributor.
These antics are acceptable in a BDFL project where the stakes are low, but try this in an actual major project with thousands of contributors and see how it goes.
I think the best case scenario I can think of is the microsoft typescript js->go conversion, whereas the bun zig->rust is probably the worst case.