`unsafe` is the part where the compiler trusts you to uphold your own invariants, necessary to prevent Unsoundness. For example:
- unsafe fn get_unchecked(index) - compiler believes you will ensure index < length.
- unsafe fn set_capacity(capacity) - compiler trusts you will not set capacity to value that will cause UB. Even if its code boils essentially to set a field - which is safe according to Rust, but may invalidate other invariants preserving soundness.
The VW Multivan Hybrid is great! The electric range is quite small (60km I think?) compared to a full EV but still sufficient for some daily trips. And smaller batteries charges fast.
I usually solve this by commiting my fixup in a dummy commit, then do a rebase -i HEAD~n where n is the number of commits I want to look back at. Then during the rebase I just move my commit below the one that seem the most appropriate and mark it for squash. Execute the rebase. Done
Another way to handle this if you haven't made the change yet is to do a `git rebase -i head~4` (or however far back) and mark the place where the change needs to happen as "edit". Make your change, add the file, then `git rebase --continue`.
If you've already made the change but haven't committed it, you can stash it before doing the rebase, then pop the stash while editing that commit.
Well, at the smallest level (if I recall correctly) it's a single solar system; they have a few beefy servers on stand-by, one is always in use for Jita, the main and most active trading hub, and others can be spun up and a whole solar system transferred over if it gets busy. And as someone else pointed out, you can organize a large fight in advance so they can transfer it over.
But there's the bottleneck, because they can only do the calculations of ship movement & actions on a single node. I'm sure it's been optimized to no end as well. IIRC it's written in Python, but that's not going to be the main performance bottleneck.
I have only the smallest of clues about distributed systems, the only way they could scale it up is to somehow make it so they can run a single solar system or cluster of ships on multiple servers, but for that you get the overhead of inter-server communication or you need an asynchronous, eventually-consistent game instead of something realtime.
Yes, so in that sense it's sharded. In another sense it's all one server, as you can warp between different systems and meet all the players there in the game. Everything is run on one giant server.
Not sure how it is now, but back in 2014-2016 you could inform them of big battles ahead of time for a specific system, at which point they would, in their own words, reinforce the node (moving that particular system to its own allocation of resources). This often was the difference between being able to duke it out in an epic space battle or wait for the system to load while everyone lagged to death.
Swiss here. Not an expert on the project but AFAIK the idea is to reduce the impact of transportation on the surface.
With globalization and population increase, the need for point to point logistic is going to go through the roof in urban areas in the next years.
Currently this translates to having more trucks on the highways and roads, as our rail wail system is close to saturation already. Not to mention our road are really small compared to US (ie: highways are two-lanes per direction). This creates a ton of air and noise pollution and traffic jams.
This new transportation system should absorb some of the goods traffic and hopefully scale country-wide in the future while sparing the environnement at the surface as much as possible.
