This seems like it's implicitly painting a false dichotomy between an implied autonomous Spez that is causing damage and a subservient Spez that is just a name attached to board action. How about this, if Spez is being asked to do stupid things by the board, he's failing extraordinarily to even cushion them with PR, which is the actual least he can do.
I built this and the other rocm packages from AUR (some removed now) along with pytorch build-flagged for rocm. It did eventually work, but It was a real pain in the ass and cost a whole lot of time. After that though, something broke (who knows) and I ended up rebuilding everything again just to get it back to a working state. I'm currently too afraid to update to these community packages, partially because I don't know if the build flags I used are the duct tape keeping my builds functional (I have an rx590-8gb which is maybe at the edge of supported gpus). Instead, I just added every rocm package to my IgnorePkgs, which isn't a great sign.
I really did loath the removal of SMS. It went like this for me: I would set up non-techie family with signal and that would be SMS and secure messaging for them. Then Signal removed SMS, so I had to explain to them that I had actually set them up with something "unstable" and needed to change their apps around. As a consequence, they're more hesitant to try things I suggest and I can't blame them. As for the actual messaging, inevitably they'll forget to juggle apps and just default to SMS and there's only so much I can go against the stream here.
This is cool, but I think being the default in the mainline app is critical. Also, iirc signal doesn't like modified apps, so this might be on shaky ground.
It goes over an older Ketchup recipe and gives some related history. If you like historical food recipes and/or culinary history, you might want to check the channel out.
At first, I was a little put off by how "batteries not included" the standard library was in rust, but I ended up preferring it. The quality of the rust community has generally made library selection pretty easy. There's usually a tacit first choice and often one or more optimized alternative for a particular situation or preference. When there is community disagreement and library churn, I think it ends up evolving better, more liked solutions; I truly believe this wouldn't happen as easily if it was enshrined in the std. Case and point, I've seen standard library implementations in C++ and python that just rot away.
The case sensitive visibility/privacy sound terrible to me. I dislike having to type pub as much as I do, but that seems worse for readability and clarity on top of throwing a wrench into the established rustfmt naming system.
About "Memory management", they already made some progress with non-lexical lifetimes in the past which did indeed improve the end user experience. I think "Polonius" aims to reduce the friction further, but I haven't looked into the specific improvements it might bring in user experience.
Yeah, wgpu isn't updated for the new attributes yet apparently. I looked it up and it was just changed in the 2022-01-19 revision. Definitely a "working draft" as stated.
Wow, WGSL looks different from the last time I checked it out (not too long ago iirc). I've been playing around with wgpu and vulkan, but I disliked the wgsl syntax so much that I didn't bother pursuing it any further at the time. I'm actually going to give it another look now since I don't really like glsl syntax much at all either.