They're full time developers exclusively for git? How long have they been doing this? What is the set of their contributions to date? Of the total set of developers how many of them want this?
Is their set of desires anything more than "lets use Rust?" Is there a specific set of new functionality that would depend on it? New use cases that could be served with it? Is there even a long term plan for "new new C code" at some date?
I sense disaster fomented by poorly articulated goals.
> Also, there's already a separate from-scratch re-implementation of git in Rust (gitoxide).
Sounds perfect. Then each project can maintain the focus on their core language and not potentially take several steps backwards by hacking two incompatible pieces together with no roadmap.
The people who are trying to commercialize the product? It's interesting that with all this money all they do is send "their developers" into the mailing list to push the product and everyone else in their own direction.
You asked who is pushing this. The answer is people who are paid full time to work on Git. These are Git developers. Their names are mentioned in the article, it is not hard to look up what these people have done, what they are doing now, and who they work for.
What are you trying to get at? It's not a conspiracy theory, it's people who just want to be able to be more effective at getting things done.
Obviously. But I was responding to "what is sinister about a GET request". To put it a slightly different way, it does not matter so much whether the request is a read or a write. For example DNS amplfication attacks work by asking a DNS server (read) for a much larger record than the request packet requires, and faking the request IP to match the victim. That's not even a connection the victim initiated, but that packet still travels along the network path. In fact, if it crashes a switch or something along the way, that's just as good from the point of view of the attacker, maybe even better as it will have more impact.
I am absolutely not a fan of all these "are you human?" checks at all, doubly so when ad-blockers trigger them. I think there are very legitimate reasons for wanting to access certain sites without being tracked - anything related to health is an example.
Maybe I should have made a more substantive comment, but I don't believe this is as simple a problem as reducing it to request types.
sometimes you just must have a new full backup every N days/weeks. it a more "smooth" way to deal with potential corruption in repo that might be undetected (without dealing with all suggested workarounds) and in some cases compliance/certification requires it
It is the Rust compiler, the article describes how the (Rust) compiler is first compiled without the Rust code in it and then used to bootstrap the final version which does have the Rust code in it
The reserved values can be used as tags in outer enum types. For example `Option<bool>` might encode `None` as 2. If you did `Some(transmute::<bool>(2))` it'd turn into `None`.
They say that OpenWrt 19.07 and 21.02 are affected, but as far as I can tell, official builds of OpenWrt only use the mt76 driver and not the Mediatek SDK.
> The only gripe I have with Rust's unsafe is that I can't mark methods with preconditions as unsafe while still requiring `unsafe` clauses within the function body.
This is being fixed in the 2024 edition. Or now, with `#[warn(unsafe_op_in_unsafe_fn)]`.
Its return type is generic, and here it's inferred from the left hand side. It's implemented using the `FromStr` trait, and you can equivalently write `Timestamp::from_str(t)`.
You're thinking of the "extension trait" pattern for using traits to add methods to existing types when the trait in scope, but that's not what's going on here. Jiff's `ToSpan` mentioned above is an example of that pattern, though: https://docs.rs/jiff/latest/jiff/trait.ToSpan.html
It says it encrypts the SPI flash with a PIN provided over USB on every boot...but if you can trust the host to store/handle the PIN, why can't the host do the rest of the cryptography too?
Also, there's already a separate from-scratch re-implementation of git in Rust (gitoxide).