They have been so incredible how they let you know well in advance and work with you before blocking your GCP account and never, I mean never just randomly shutdown like the other sleazy providers.
This is a huge surprise, never thought I would see this in my life time.
Who is the "You" in "you haven't addressed the root cause"?
If you are asking Railway to spend effort doing this rather than simply moving away from GCP, I'm not sure why they would unless they want to sue GCP to recover damages to brand and long term customer retention.
The moment GCP shut off without any forewarning, its done deal, no need to ask any further questions.
Clearly for commercial oriented opensource software, security through obscurity is one way to keep the pace in the short term. Not an option for proper open source software.
Will this be the case that people who use open source software that is easily detectable will also start to shy away from using them for the fear of zero-days?
One of the benefits of Open source has been that there are more eye balls on the source, leading to more secure code/better quality. I think given enough time the bug reports will plateau and we will be back to a normal cadence - once the tsunami is over, hopefully things will settle at a more manageable cadence .
I'm not sure that the benefit of many eyes helps here. So much of this bulk scanning is low-effort, and if you're a smart person developing closed source software you get the benefits of bulk scanning, but _at the time of your choosing_ .
OSS has always had tradeoffs and I sadly think this one is going straight to the "Cons" column. We still think the Pros outweigh the Cons, but this is NotGreat.
It's certainly possible to write optimizations that generate nondeterministic llvm outputs, but the docs explain conditions when that can happen, and warn against it.
I think the fear of being located isn't based on the fact that someone can decrypt an encrypted transmission, its simply because someone can trace that a particular location is transmitting some radio waves.
You encrypt it because encryption is cheap and gives you confidence that the message content won't be intercepted.
The transmission itself would need to be stealthy or separated (by distance and/or time) from the pilot. For example, the pilot might leave a transmitter to send a message "moving south, will hide on X hill" hours after the pilot leaves, or even toss a transmitter into a river. But most likely just very spread-spectrum/CDMA to make it indistinguishable from noise.
The real migration challenges are in the server side/consumer home internet space which I'm not sure if there are clear stats around the adoption there.
I think IPV6 is a great example of over engineering, trying to do too much in one iteration. In an ideal scenario this could work, but in the context of large scale change with no single responsible party, it usually doesn't work well.
On the server side, everyone is moving behind CDNs that support IPv6 by default.
On the consumer home internet side, consumer ISPs are slowly one by one lighting up IPv6, and it just works since consumer routers are mostly auto-configure (often literally controlled by the ISP). Mobile is largely IPv6 already.
The biggest challenge is in corporate/academic/medium-size business networks where they have lots of obscure subnets and firewall rules and old software and hardware running a critical task under a dusty table somewhere.
The problem has nothing to do with over engineering, or really anything to do with the actual contents of the IPv6 standard. It is just devilishly hard to make any backwards-incompatible change to layer 3, and address expansion is always going to be backwards incompatible.
IPv4 addresses are in fact a subspace of IPv6 (that's NAT64). They were not by fiat declared invalid. The actual thing I think you're complaining about - the necessity for NAT64 at all - is unavoidable, because you need a NAT/protocol-translation layer for packets to actually move between the new address space and the old one.
SLAAC-by-default is not, in my experience implementing IT automation, an actual barrier for adopters. You have a router sending out RS instead of a DHCP server, to an admin this is not a meaningful change.
NAT64 is a temp bolt on and also not the same thing. If I own 1.1.1.1 in v4, that doesn't mean I own some equivalent of 1.1.1.1 in v6. They had router nat64 and relay nat64, both with dealbreaker problems.
You don't exactly need a translation layer. If they just gave me 1.1.1.1:: in v6, anyone migrating v4 to v6 would have the same route to me as before, and other changes like DNS6 could be gradual. Then after v4 is abandoned enough, I can sell 1.1.1.1.2:: to someone or use it instead of NAT.
SLAAC is a good design as a non-default that people who know what they're doing could enable, but a lot of people don't even want public v6 addrs for hosts, they just want NAT/DHCP.
> You don't exactly need a translation layer. If they just gave me 1.1.1.1:: in v6, anyone migrating v4 to v6 would have the same route to me as before, and other changes like DNS6 could be gradual.
Think about this on a concrete, packet by packet level - I, from a v6 network, with a 128-bit address that cannot be represented by IPv4, decide to open a connection to 1.1.1.1. 1.1.1.1 doesn't have v6 set up, and so can't read my v6 packet and craft a response packet, because its address is invalid in v4. We need a gateway in the middle that will translate the packets from one format to another and perform the NAT function from one address space to another. This is an irreducible complexity.
> a lot of people don't even want public v6 addrs for hosts, they just want NAT/DHCP.
People don't care about whether their address is public or not, they want connectivity. SLAAC gives that to them; it is you that are insisting on adding complexity for the sake of having a non-routable address. As a user, I enable IPv6 on my router and go on my merry way; as an ISP, I assign my customer's router a /60 or /56 via DHCPv6 instead of a /24 and go on my merry way. Running an IPv6 address allocation system is a an easy, solved problem and has been for decades.
The hard problem is dual-stacking, and there is no way around that.
I mean, you own 2002:101:101::/48. You also own ::1.1.1.1, ::ffff:1.1.1.1 and 64:ff9b::1.1.1.1.
> If they just gave me 1.1.1.1:: in v6, anyone migrating v4 to v6 would have the same route to me as before, and other changes like DNS6 could be gradual
That's not really how routes work. Or DNS.
I think you're mainly arguing we should import v4's allocations into v6, but about the only benefit is that people don't have to bother requesting new allocations. It doesn't help with any other aspect of the transition, and there are good reasons to avoid doing it -- the v4 address space is highly fragmented and also very unfairly allocated.
Plus we have plenty of people saying we should take back v4 allocations from companies that own them. That's not possible, but _not_ giving owners of v4 /8s an entire 1/256th of the v6 address space certainly is.
This doesn't give me a clear idea as a layman on how to interpret this information. Is it ok for the layman to believe that may 1st 1985 the variations of -5 to 5 were around 86 mean but in 2025 the same were around 82 mean, if that were to be the case, irrespective of the variations, it would not give me an idea of whether its concerning or not (this is just a random example, don't read too much into my beliefs)
I don't quite understand the temperature color scale of -5 to 5, what is the baseline here on -5 to 5, is it relative to global average of that day? Or a period of time?
@huntergemmer - assuming you are the author, curious about your experience using .claude and .cursor, I see sub agents defined under these folders, what percent of your time spent would you say is raw coding vs prompting working on this project? And perhaps any other insights you may have on using these tools to build a library - see your first commit was only 5 days ago.
I urge you to understand what he is going through, he started the project, made it available freely, as more effort was required he added a premium offering to keep the whole thing running and hire more help.
Please pause to think before coming to a rush judgement. How would you react if you had done exactly the things he had done, and you just had to lay off most of your team yesterday. We are humans and not robots, for all he has done, he has certainly earned the right to some times focus on what's affecting him first before he can focus on OSS.
Be Kind, we are all born billionaires with billions of "kindness tokens" in the bank, don't use them sparingly.
This is a huge surprise, never thought I would see this in my life time.
reply