> Aside from memory safety, which is solved by using a compiler that just doesn't allow unsafe memory operations
I don't see how that's possible without turning the language into something that isn't C, either by adding significant new functionality (e.g. fat pointers) or subtracting enough functionality that it's a much less capable language (e.g. disallowing dynamic memory allocation).
Also they’re no where near each other. These Chinese rover cannot get there.
Also also, if China were to create a new mission to collect them, they would see their costs balloon to unsustainable levels as well, as the issue is how the mission is designed. The samples are all over the place and would need a rover specifically designed to collect them and return them to a launcher.
The US Mars sample return project was always half baked in the hopes that doing something would garner funding for the rest of the mission.
Not true - only ten samples were dropped off at a “depot” close to each other. The rest are on-board Perseverance and can be picked up all at once, which was always the primary plan.
Interesting question. Article VIII of the Outer Space Treaty [1] states:
> A State Party to the Treaty on whose registry an object launched into outer space is carried shall retain jurisdiction and control over such object, and over any personnel thereof, while in outer space or on a celestial body. Ownership of objects launched into outer space, including objects landed or constructed on a celestial body, and of their component parts, is not affected by their presence in outer space or on a celestial body or by their return to the Earth. Such objects or component parts found beyond the limits of the State Party to the Treaty on whose registry they are carried shall be returned to that State Party, which shall, upon request, furnish identifying data prior to their return.
It is clear, then, that the sample containers are still the property of the US, and that if the Chinese brought them back to Earth, they would be required to give them to the US.
> There are still some types of CRT-related vacuum tubes in production for applications digital equivalents are objectively less performant in.
Like what? The only significant applications I'm aware of for vacuum tubes nowadays are high-power RF amplifiers (including household microwave magnetrons) and intentional X-ray emitters.
Night vision goggles. The photodiode + CsO + lead coated charged glass capillary amp thing is apparently still superior to solid state image sensors with amplifiers in metrics like SNR, minimum luminosity, and longer wave IR response. The performance gap is wide enough that there's a Chinese Norinco subsidiary that entered the market during 2010s by licensing technology from an EU company.
> I was wondering how you could possibly sync up something like a Carrier that has multiple fighters.
Same way as everything else - you play out the simulation and see what happens. The behavior of the interceptors is as deterministic as any other unit. (They just happen to not be directly commandable by their owner.)
No, I get that. The pondering was before I knew it was a recording of actions. Once you know that, it is a fully self-contained box with external nudges from the players which get inserted into the simulation.
Not feasible. The VODs are from a spectator's perspective; there's a lot of action happening "off camera" (like players building units) which affects what's seen on camera later, and which would be extremely difficult to reconstruct from what's visible.
Yes, e.g. https://github.com/gulshngill/bwrepanalysis. But I doubt an agent would learn much from them without a lot of additional processing - the replay files are little more than a stream of the orders given during the match (e.g. "at tick 17, player 1 ordered unit 234 to attack-move to 56,78"). They're difficult to make sense of without a lot of additional context, like the map layout, the location and status of other units, what parts of all that are actually visible to each player, etc.
This is not a viable strategy in competitive play. It's a huge resource/time investment with a dubious payoff.
If you could win as Protoss by building Dark Archons, raiding your Zerg opponent's base to capture a worker, building a bunch of Zerg production and tech buildings, and attacking with a combined army... you most likely outclass your opponent, and could have won much faster using a more conventional strategy.
What you're describing is a casual game, not competitive play. And, of course, all bets are off if you're playing with additional rules like "no rush" which remove the element of tempo from the game.
> So why not set up a simple grid (say, Pages on a mac or Libre Office or Scribus) and pair the best photo you can grab with a description opposite it, on a nice background?
Or, for that matter - skip the photos, just do text, maybe with a few bits of clip art if you're feeling daring. Photos are hardly essential for coffee drinks, which tend to all look the same in real life anyway.
> It's also nice that it translates directly to the file system.
On the other hand, this means that it's bound by filesystem naming rules - e.g. you can't have an object named "abc/", or a pair of objects named "a" and "a/b".
I don't see how that's possible without turning the language into something that isn't C, either by adding significant new functionality (e.g. fat pointers) or subtracting enough functionality that it's a much less capable language (e.g. disallowing dynamic memory allocation).
reply