Empowering everyone to build reliable and efficient software.
Python dependency management and packaging made easy.
Get performance insights in less than 4 minutes. Scout APM uses tracing logic that ties bottlenecks to source code so you know the exact line of code causing performance issues and can get back to building a great product faster.
libgccjit AOT codegen for rustc
GCC Front-End for Rust
🍺 The missing package manager for macOS (or Linux)
Vagrant is a tool for building and distributing development environments.
Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority).
Semantic Versioning Specification
Community maintained packages for OpenWrt. Documentation for submitting pull requests is in CONTRIBUTING.md
🦾 A list of reported app support for Apple Silicon and the new Apple M1 Macs
“Zero setup” cross compilation and “cross testing” of Rust crates
Alternative rust compiler (re-implementation)
seL4 specification and proofs
🏆 Collection of bugs uncovered by fuzzing Rust code
Restart daemons after library updates.
small utility to simplify debian rust security work
The modern packager’s security nightmare
news.ycombinator.com | 2021-02-21
> It's maddening to hear people say things like, "Oh if everyone just used semantic versioning this wouldn't be a problem". Of course this cannot work. _Think about it_. There are innumerable ways two pieces of code can be incompatible. ... If you call these things "breaking" changes, you will constantly be increasing the major version.
One of the things that prompted the OP was this breakage in Python's cryptography package  (OP actually opened this issue) due to the introduction of a Rust dependency in a 0.0.x release. The dependency change didn't change the public API at all, but did still cause plenty of issues downstream. It's a great question on the topic of semver to think about how to handle major dependency changes that aren't API changes. Personally, I would have preferred a new major release, but that's exactly your point syllogism — it's a matter of opnion.
As a sidenote, Alex Gaynor, one of the cryptography package maintainers is on a memory-safe language crusade. Interesting to see how that crusade runs into conflict with the anti-static linking crusade that distro packagers are on. I find both goals admirable from a security perspective. This stuff is hard.
Drew DeVault's take on rewriting everything in rust
I am not going to go through a swarm of idiotic comments in this issue but I loved this comment: https://github.com/pyca/cryptography/issues/5771#issuecomment-775119338
I know. That's why I linked in the bug report when that hit. Here: https://github.com/pyca/cryptography/issues/5771 . Notice that Drew is in that thread. I thought the thread was insightful as to developer vs. packager interaction ... and is probably the motivation for Drew's article.
I'm partial to: https://github.com/pyca/cryptography/issues/5771#issuecomment-775269245
It's not a hard requirement yet. Soon. Look here: https://github.com/pyca/cryptography/issues/5771
Read their comments ffs.
That's unrelated, the version that introduced Rust was 3.4 - eleased on Feb. 7th: https://github.com/pyca/cryptography/commit/2c11ad53c07179e03ea2f60813cb52d83f766292#diff-2c623f3c6a917be56c59d43279244996836262cb1e12d9d0786c9c49eef6b43c
These people seem to be mistaken, as in the end, it appears that only really obsolete architectures can't run the rust blob.
This is not a minor version. Until the next version (35.0.0), their versioning scheme is a weird one, where in X.Y.Z, both X and Y can be breaking.
This was the project https://github.com/pyca/cryptography/
news.ycombinator.com | 2021-02-18
> This also means that very long-lived platforms will probably be forced to upgrade that library every half year or so in line with the development of rust.
As a security library... you goddamn better be updating it every half year of so.
This has nothing to do with rust though. Rust maintains full backwards compatibility, so even if you upgrade the compiler (which is unlikely on long lived platforms) and not the library nothing breaks.
Nor is it necessarily the case that upgrading the library will require updating rust (though this isn't what you appear to be complaining about). Not only is it a build time dependency (that you don't even need to install if you are on common platforms which ave prebuilt binaries), but they are explicitly testing against a particular fixed old version of rust as well as recent ones: https://github.com/pyca/cryptography/blob/main/.github/workf...
> I'd say such an initiative needs a long-term supported version of rust, similar to C99 or so.
This describes every version of rust since 1.0. Rust is fully backwards compatible, unlike new C standards.
> Do we have anyone committed to providing a stable rust environment for these cases?
Yes, the entire rust team...
Experiences with Macbook M1?
reddit.com/r/devops | 2021-02-17
Here's the link to the same issue I had: https://github.com/pyca/cryptography/issues/5742
"system packaging is actually the wrong approach to getting software onto computers." - Rustacean upon discovering that Rust's packaging methods are causing problems for OpenWRT
Bonus jerk found by following issue links:
It is when you push out 2 or 3 versions a day.
Or you could open the changelog
pyca/cryptography is an open source project licensed under GNU General Public License v3.0 or later which is an OSI approved license.