In #bevy 0.14 some traits such as AssetReader have been converted to use the recently stabilized async fn as compared to returning a BoxedFuture. This change unfortunately makes these traits no longer object safe. To fix this, erased versions of the traits were created (such as ErasedAssetReader) that do support being used with dyn.
oct can now set up cards in #KDF mode, the text output format was improved for readability, and some minor bugs were fixed.
Finally, version 0.11.0 uses #rPGP, a pure #Rust OpenPGP library 🦀.
As a result, the binary on #Linux links to four fewer dynamic libraries, while at the same time being 10% smaller.
@hko awesome. I use the openpgp-card-agent on 5 machines already and it made my life so much easier. And oct is also an amazing tool when having to deal with opnepgp cards. Thank you so much for that awesome projects 😊
I noticed that #Zed automatically downloads a NodeJS binary from nodejs.org without asking or even informing the user about it. Right after starting it and opening a file, without doing anything else. Then it installs some packages from npmjs via npm. And there’s no option to disable it.
THIS IS ABSOLUTELY UNACCEPTABLE! I can’t stress enough how bad this is from #security point of view. And not just that, consider users on metered connections
Is there a way in Rust to use standard lib traits (Ord, Eq, Into/From...) with async functions?
Perhaps a crate or something?
Or must it be a separate function implemented for the structs?
@Soblow It's not possible. These traits require returning result immediately, and this is their guarantee that cannot be changed. You need to create your own methods for this, or preload data ahead of time.
Ja und Nein, denn Rust ist im grunde sicherer aber auch das kommt darauf an wie mensch es umsetzt. Ich vertraue Rust mehr als anderes Coding, ich schau mir die Libs-Daten an.
»Speichersicherheit – Fast 20 Prozent aller Rust-Pakete sind potenziell unsicher:
Nach Angaben der Rust Foundation verwendet etwa jedes fünfte Rust-Paket das Unsafe-Keyword. Meistens werden dadurch Code oder Bibliotheken von Drittanbietern aufgerufen.«
@kubikpixel Sehr schade finde ich, dass der Artikel nicht darauf eingeht, dass viele der "unsicheren" Pakete tatsächlich nur Wrapper sind, die explizit diese eine Fremdbibliothek einbinden und evtl. abstrahieren - also tatsächlich eine zusätzliche Sicherheitsschicht, um diese Bibliotheken möglichst einfach aktualisieren oder auswechseln zu können.
@h3r2tic@anaopara a statically linked binary might serve you well - with all the shenanigans going on in the library forests of ubuntu vs arch/steamdeck vs fedora and friends. Also OpenBSD. Can we make it uefi bootable? On a PS3? 😆
I think there would be still space for systems programming language with a constraint from day zero that it would 1:1 compatible with plain C”s binary layout and memory model:
Roughly just .text, .bss, .rodata and ,data.
No symbol mangling at all.
All the memory safety etc. fancy features would be then designed within exactly those constraints.
#Rust is essentially a derivative of C++ when compiled to binary, which does not really make it a strong competitor for plain #C. It can substitute C in many cases for sure, just like C++ did, but there’s always need for minimal systems programming language, which also looks elegant in binary, not just in source code.
A compiled C program can be quite easily understood with a binary with no debug symbols at all if you understand the CPU architecture well enough. That is, and will be a strong asset for C.
@jarkko Safety is like a thread you start to pull, and pulls more and more stuff. You need collections for bound checks and robust realloc, but void* casts complicate verification, so you need generics for collections. To reduce bounds checks, you need iterators. Safe unions require sum types. Unsafe free() can be replaced with destructors, which need owned+borrowed pointers. You need thread safety too, etc.
There isn't much that can be removed from Rust without creating holes in the safety.