![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://fry.gs/pictrs/image/c6832070-8625-4688-b9e5-5d519541e092.png)
It’s true technical analysis does show the opposite, however it’s a technical analysis. AKA Engineers making educated guesses. Which is the reason the FCC allowed a limited test area to run actual trials to verify. And the fact that the FCC has not immediately shut it down implies that they have not been able to confirm what that technical analysis predicted.
Don’t get me wrong I’m no big huge fan of starlink over here, but both AT&T and Verizon have a long standing history of competing through litigation rather than actual service so I’m inclined to give T-Mobile and starlink the benefit of the doubt here.
When everyone was first getting new frequency opened up AT&T and Verizon fought over millimeter wave while T-Mobile mostly ignored it and went for the mid band 600-800mhz. This caused the T-Mobile to have an insane lead over actual 5G deployment you can now get good 5G speeds out in the middle of rural fuck nowhere because you’ll be on the 700 band 12.
Meanwhile millimeter wave is still useless because a piece of rice paper will block the signal entirely so it only works in extremely extremely limited areas of town with direct line of sight and no obstacles to the Tower. So Verizon and AT&T started complaining to the FCC that T-Mobile has too much spectrum and they can’t possibly compete even though they made absolutely no attempt whatsoever during the initial bidding to get any mid-band.
Now we see the same thing here, T-Mobile is getting ahead of everyone Verizon and AT&T are lagging behind they plan to roll out the exact same service, with the exact same frequencies, with the exact same technology, however they are still in the planning phase and starlink/t-mobile is just about ready to activate it so they are complaining
They are amazing but at the end of the day they are still humans and they can make mistakes. In the YouTube video referenced one of the C devs is heavily against rust.
Decided to go look for CVEs from code the guy manages (Ted Ts’o) I found these
CVE-2024-42304 — crash from undocumented function parameter invariants
CVE-2024-40955 — out of bounds read
CVE-2024-0775 — use-after-free
CVE-2023-2513 — use-after-free
CVE-2023-1252 — use-after-free
CVE-2022-1184 — use-after-free
CVE-2020-14314 — out of bounds read
CVE-2019-19447 — use-after-free
CVE-2018-10879 — use-after-free
CVE-2018-10878 — out of bounds write
CVE-2018-10881 — out of bounds read
CVE-2015-8324 — null pointer dereference
CVE-2014-8086 — race condition
CVE-2011-2493 — call function pointer in uninitialized struct
CVE-2009-0748 — null pointer dereference
Do you see a pattern in the type of error here? It’s pretty much entirely memory related and right in the wheelhouse of something rust would just outright not allow short of just slapping everything into unsafe blocks.
The Old Guard is not perfect, and they are acting as a barrier to new talent coming in. Sometimes change is good and I’m heavily in the camp that rust one of those times. Linus seems to agree as he allowed the code into the kernel which he would never do lightly or just because it’s fomo