I get the sense that you might appreciate golang.
Data Science
I get the sense that you might appreciate golang.
He made up hypothetical scenarios that nobody asked about, and then denigrated Rust by attacking the scenarios he came up with.
This seems to be the textbook description of a strawman argument.
It’s also a microkernel and intentional not POSIX compliant (but it’s close to compliant). I like the project, but it’s very experimental on purpose, so we should set our expectations accordingly. I’d love to see it become a success, but it may not be or it may only be successful in a smaller niche than the current Linux ecosystem.
That said, it seems very open to new contributors. I hope more people can help it along.
https://www.baeldung.com/linux/ Also has very well written articles on specific topics and tutorials.
Follow up with what is sometimes called the Unix Bible: https://www.oreilly.com/library/view/unix-and-linux/9780134278308/
I’m expecting that everything that the statistical models reveal or make convincing results about which benefit the owners of the models will be exploited. Anything that threatens power or the model owners will be largely ignored and dismissed.
The few laws that govern this type of activity will be strictly adhered to, right?
You should be aware that this is classified and marketed as a microcontroller, so it’s just a bootloader to some code with no OS or a RTOS.
Something like the RPi Zero is a SBC that’s relatively close in size.
See: https://blog.system76.com/post/cosmic-team-interview-byoux
We considered toolkits like GTK, Flutter, and QT, and though the team was already experienced working with GTK for Pop!_OS, eventually landed on the Rust-based toolkit, Iced.
Rename the project Chameleon and keep calling Tumbleweed and Leap by their distribution names.
It’s trendy to rebrand things with an X.
Let’s call it X.
MacOS and iOS are good examples of amateur marketing
I’ve read that. Defining a supplier as someone with whom you have a direct business relationship with seems intentionally narrow in an unhelpful way that just further muddies the waters around the issue at hand. Making something generally available to others means that you’re supplying others with that thing. While it’s true that you may have no further obligations to those that receive your software, the person receiving the software needs to evaluate their risks around using and depending on that software regardless of the existence of a business relationship with the supplier. Hence supply chain risk evaluation is always necessary. That risk evaluation, or lack thereof, can result in a security problem. These problems can propagate widely within a software ecosystem. This is true with and without the existence of direct business relationships between suppliers and recipients of software.
The whole article can be summarized by saying if you want support services related to the software written by others, negotiate a support agreement related to that software. That has nothing to do with taking a wide or narrow interpretation of the word supplier.
Developers should think about what libraries they trust, but it seems that most of the time they’ll choose whatever is most convenient for handling the immediate problems they’re working to solve.
I’ve been comparing crates on crates.io against their upstream repositories in an effect to detect (and, ultimately, help prevent) supply chain attacks like the xz backdoor1, where the code published in a package doesn’t match the code in its repository.
The results of these comparisons for the most popular 9992 crates by download count are now available. These come with a bunch of caveats that I’ll get into below, but I hope it’s a useful starting point for discussing code provenance in the Rust ecosystem.
No evidence of malicious activity was detected as part of this work, and approximately 83% of the current versions of these popular crates match their upstream repositories exactly.
Probably want to add experimental in there too.