Curious why you'd move from C# to Rust. C# has you covered mostly for memory safety so I would guess performance or lots of shared memory across threads?
This is the answer I think. The correctness of your safe code is dependent on the diligence of the unsafe code except for the most simple cases. A kernel is going to have a pretty high unsafe to safe ratio compared to most usermode apps.
This really gets to the core of what I think Rust is about, you can add compiler checked constraints to your APIs that your C and C++ code can't. It's up to you to use them effectively. Rust's ability to keep your safe code safe is a measure of the language, but also your architecture. The buck has to stop somewhere for the language to prove safety, Rust lets you decide rather than the language itself.
Valve is just hedging against Microsoft having a big red button to kill Steam. They've built their kingdom on top of Microsoft, and Microsoft would love to have it for themselves I'm sure. It's in Valve's best interest to divorce themselves from Windows to protect themselves from Microsoft.
It happens to also benefit the Linux gaming crowd, but it's still ultimately self-interest driving the work. The engineers doing the work are probably doing it for the altruistic reasons, but ultimately Valve is writing the cheques.
NAT is not a security device. A firewall, which will be part of any sane router's NAT implementation, is a security device. NAT is not a firewall, but is often part of one.
Any sane router also uses a firewall for IPv6. A correctly configured router will deny inbound traffic for both v4 and v6. You are not less secure on IPv6.
All the names for waves come from different hardware and software vendors adopting names for the same or similar concept.
- Wavefront: AMD, comes from their hardware naming
- Warp: Nvidia, comes from their hardware naming for largely the same concept
Both of these were implementation detail until Microsoft and Khronos enshrined them in the shader programming model independent of the hardware implementation so you get
- Subgroup: Khronos' name for the abstract model that maps to the hardware
- Wave: Microsoft's name for the same
They all describe mostly the same thing so they all get used and you get the naming mess. Doesn't help that you'll have the API spec use wave/subgroup, but the vendor profilers will use warp/wavefront in the names of their hardware counters.
Not recommending the Steins;Gate anime adaption is pretty wild, it's an incredibly highly rated Anime series. The story telling language of a VN and an Anime are very different so it's no surprise they don't perfectly capture the complexities of the other medium. They don't have to be the same to be worth watching.
fwiw: no idea on the other anime adaptions quality
The hard part of Linux ports isn't the first 90% (Using the Linux APIs). It's the second 90%.
Platform bugs, build issues, distro differences, implicitly relying on behavior of Windows. It's not just "use Linux API", there's a lot of effort to ship properly. Lots of effort for a tiny user base. There's more users now, but proton is probably a better target than native Linux for games.
As if you don't get a jumble of UI frameworks on Linux too.
You can run KDE but depending on the app and containerization you open you'll get a Qt environment, a Qt environment that doesn't respect the system theme, random GTK apps that don't follow the system theme, random GTK apps that only follow a light/dark mode toggle. The GTK apps render their own window decorations too. Sometimes the cursor will change size and theme depending on the window it's on top of.
> Converting directX into Vulkan (potentially very large performance gains)
That's not at all how that works. DirectX12 isn't slow by any stretch of the imagination. In my personal and professional experience Vulkan is about on par depending on the driver. The main differences are in CPU cost, the GPU ultimately runs basically the same code.
There's no magic Vulkan can pull out of thin air to be faster than DX12, they're both doing basically the same thing and they're not far off the "speed of light" for driving the GPU hardware.
Being so absolutist is silly but their counter argument is very weak. Can I invalidate any memory safe language by dredging up old bug reports? Java had a bug once I guess it's over, everyone back to C. The argument is so thin it's hard to tell what they're trying to say.
It's just as reductive as the person they're replying to.
Yes? That's called a bug? The standard library incorrectly labelled something as safe, and then changed it. The root was an unsafe FFI call which was incorrectly marked as safe.
It's no different than a bug in an unsafe pure Rust function.
I'm choosing to ignore that libc is typically dynamically linked, but linking in foreign code and marking it safe is a choice to trust the code. Under dynamic linking anything could get linked in, unlike static linking. At least a static link only includes the code you (theoretically) audited and decided is safe.
You're both wrong, the Mirai uses a fuel cell as the voltage source for an otherwise EV drive train. The Mirai is an EV with a fuel cell instead of a battery.
I remember Star Wars Jedi Survivor had a 5-6 minute shader pre-compile on my 5950X. I heard of people well into the 30 minute mark on lower core count machines. Battlefield 6 was a few minutes on my 9950X, higher again on lower core count CPUs.
Really depends on the game.
There's no easy way around this problem. It never came up as much in the OpenGL/D3D11 era because we didn't make as many shaders back then. Shader graphs and letting artists author shaders really opened pandoras box on this problem, but OpenGL was already on its way out by the time these techniques were proliferating so Vulkan gets lumped in as the cause.
Yes, many games do that too. Depending on how many shaders the game uses and how fast the user's CPU is an exhaustive pre-compile could take half an hour or more.
But in reality the exhaustive pre-compile will compile way more than will be used by any given game session (on average) and waste lots of time. Also you would have to recompile every time the user upgraded their driver version or changed hardware. And you're likely to churn a lot of customers if you smack them with a 30+ minute loading screen.
Precisely which shaders get used by the game can only be correctly discovered at runtime in many games, it depends on the precise state of the game/renderer and the quality settings and often hardware vendor if there are vendor-specific code paths.
Some games will get QA to play a bunch of the game, or maybe setup automated scripts to fly through all the levels and log which shaders get used. Then that log gets replayed in a startup pre-compile loading screen so you're at least pre-compiling shaders you know will be used.
For Vulkan you already ship "pre-compiled" shaders in SPIR-V form. The SPIR-V needs to be compiled to GPU ISA before it can run.
You can't, in general, pre-compile the SPIR-V to GPU ISA because you don't know the target device you're running on until the app launches. You would have to precompile ISA for every GPU you ever plan to run on, for every platform, for every driver version they've ever released that you will run on. Also you need to know when new hardware and drivers come out and have pre-compiled ISA ready for them.
Steam tries to do this. They store pre-compiled ISA tagged with the GPU+Driver+Platform, then ship it to you. Kinda works if they have the shaders for a game compiled for your GPU/Driver/Platform. In reality your cache hit rate will be spotty and plenty of people are going to stutter.
OpenGL/DirectX11 still has this problem too, but it's all hidden in the driver. Drivers would do a lot of heroics to hide compilation stutter. They'd still often fail though and developers had no way to really manage it out outside of some truly disgusting hacks.