You're off by a factor of 10x.
Starlink is at 480-550 km
Amazon Leo is at 590-630km
At most that's about 30% the distance or about 30% more latency. Also an extra round trip of 300km is about 1ms extra latency.
It is in character for the tech giantâ"its research division produced the first prototype for a 2 nanometer node chip back in May 2021.
With that development, âoewe highlighted the research, and now all leading foundries are manufacturing theseâ
Just because they don't make it doesn't mean they can't license the patent to the foundries.
I don't think "continuous" means what you think it means. The reason you can do this is because the models are continuous.
One of the defining papers in this field is 2013 "Intriguing properties of neural networks" by Szegedy et al. In their own words from the abstract, "we find that deep neural networks learn input-output mappings that are fairly discontinuous to a significant extent"
I'm using the word "continuous" in the same sense as them. (Perhaps it does indeed mean what I think it means...)
In image processing like this article is talking about, the classic example of a harmful response is that your car's camera sees "speed limit 30" sign, but a small sticker it makes the image processor believe it saw a "speed limit 70" sign.
(this is an actual demonstrated attack. It means that pranksters could cripple self driving.)
The thing about these image classifiers is that they're not "continuous". You can make it see a stop sign as a right-of-way sign, or a green light.
Probably not but there are two existing datacenters downtown along with Seattle Internet Exchange. Not a lot of room to expand though I imagine in the building.
[invariant-heavy and proof-heavy guidance to the AI] How do you do that?
My main AGENTS.md has ten lines about the most important coding principles:
- Prefer functional-style code, where variables are immutable "const", there's almost no "if/else" branching branching, and most functions are side-effect free.
- Code should have comments, and functions should have docstrings. The best comments are ones that introduce invariants, or prove that invariants are being upheld, or indicate which invariants the code relies upon.
I am adamant about clean engineering. What I look for:
- Invariants are the best way to document all aspects of code. These include code invariants (stating what assumptions a function makes about shared data, and how it upholds them), and architecture invariants (for instance the main index.js never touches state except through component accessors).
You must document *meaning* of every field, and also enums and disjoint type fields.
- "Meaning" says briefly what the field/enum represents. From a well-written meaning, a smart reader will be able to deduce all the invariants around this field/enum, and deduce how it will be used in the code.
- It is hard work to distill a good meaning! You must put considerable effort into it.
The instruction on "meaning" ended up carrying a lot of weight to the AI. It adopted the habit of putting a comment on every single field and function that starts with the word "// Meaning: " and they're honestly, genuinely good ones! Single-line sentences on fields that carry a lot of good weight.
Separately, I have a LEARNINGS.md file which I have the AI auto-update every time it gets course corrected by me. Over the first two weeks there were a lot of course corrections, but now there are only a few a day. The file ended up carrying my senior engineer wisdom, more or less, the kind of things I normally mentor to junior developers on the team over several years. Here's an extract: https://gist.github.com/ljw100...
My CS degree had a lot of theorem proofs in it, invariants, that kind of thing. I've always had the habit of aiming to prove my code correct under all possible circumstances. Usually not a formal proof, but using the same skeleton as a formal proof would.
It got me a job on the C# language design team (when I tried to prove an algorithm correct, couldn't, discovered a counter-proof that the runtime had a flaw).
As I mentor junior devs and review their code, I'm always telling them to reason about their invariants better and document them.
Now in the age of AI, I find that invariant-heavy and proof-heavy guidance to the AI ends up getting its work done quicker and higher quality. OpenAI mentioned the same thing in a blog post in February.
Sure, there are many paths to professional success and engineering excellence that don't involve this kind of CS heavy approach. But, there are many that do...
For int'l flights: Amazon Leo is launching next year. Delta is waiting.
And LEO is even easier than GEO since it doesn't have any moving parts. GEO had to rotate to keep alignment. LEO are all using phased arrays.
For existing code in the QA he said leave it be and it's better to fix.
For new code, he's recommending Rust and the advantage he talks about is that it makes the code more maintainable by people. And one thing that every AI coding talk I've seen agrees on is that what makes code more maintainable by people also helps AI and vice versa.
People and AI both have limited attention and memory. The less context necessary the easier it is to evaluate safety.
Another thing not in the summary he touches on is hardware safety. Not just software bugs but also compromised hardware which if your driver is memory safe can also prevent a buggy or adversarial piece of hardware since the hardware is effectively user input.
To balance out OP's selective quoting to avoid people strawman-ing his argument as a fanatic who can't balance risk:
"No, we don't want [rust] rewrites, so unless you're the maintainer and owner of that file, just do it for new stuff. Leave existing C code alone, and let's evolve forward after that."
Now, that doesn't mean he thinks Rust is magic. It's not. He cited one of the first Rust components merged into the kernel: QR code display logic used when the kernel crashes. "That logic was written in Rust. Famously, it had a memory bug. It was given a buffer and its size, and the rest of the st code never checked the buffer size... Could scribble all over memory..."
I think a tool that lets one person do the work of 20 will result in 17 people being laid off, as the company triples its rate of work. (I can see triple being feasible and achievable in the software industry, but maybe not more)
Oh, and a "train" is a bit like 100 cars back to back.
Anyone expecting corporations to not try to make a profit and extract maximum value for their shareholders ignore that that's their fiduciary duty.
"this belief is utterly false. To quote the U.S. Supreme Court opinion in the recent Hobby Lobby case: 'Modern corporate law does not require for-profit corporations to pursue profit at the expense of everything else, and many do not.'"
https://www.nytimes.com/roomfo...
"We
The absent ones are always at fault.
