Perhaps down the road, after experimental is lifted. For now I've generally been telling distros to slow down.
For anything this big staging the release is important, we don't need or want to be in every distro right away (the Fedora people were also _extremely_ gung ho in the past and I told them the same thing).
Until every outstanding critical bug report is fixed (and there are still a few), I want power users testing it who know how to deal with things breaking, I don't want unsuspecting users getting bit.
Devil's advocate: You may find that it better achieves your goal to provide packages and say "For power users testing only". You might also be able to petition Debian to have it removed if it's leading to people foot-gunning.
If I can help with deb/rpm packaging, let me know. I'm a power user here, excited about bcachefs, but haven't tried it because I don't have the time to give it a worthy test (remembering how much time I put into getting ZFS stable on Linux). Thanks for your hard work on it!
It seems honestly odd to me not to just vendor what you need as standalone packages if your dependencies are that specific and you're a filesystem i.e. you use the bcachefs-errno package, not errno.
Debian tends to put their principles above pragmatism (for better or worse), so would they even agree with such vendoring when it's entirely meant as a way to bypass their vision/requirements/process for how dependencies should be handled?
That particular principle is bourne of pragmatism; Debian long ago learned the lesson that other distros are determined to relearn ( https://thenewstack.io/vendoring-why-you-still-have-overlook...) - vendoring is not good for security. In fact, I have come to view Debian's commitment to principles as almost always a practical matter, because those principles (almost?) always trade short-term pain for long-term quality and stability.
It's also effectively what the big cloud vendors do with their monorepos. This makes sense when you have upstreams which are slow at upgrading (e.g. it looks like Debian is upgrading packages packages using older bootstrap to bootstrap v5 across the board, and such fixes get pushed upstream; there's also tooling to watch new releases, so Debian's tooling effectively acts like a system-wide dependabot).
This isn't a Debian problem though, that's the point: if bcachefs-tools has such specific dependencies, then why doesn't it vendor it's own dependencies so it's clear they are packaged and used independently?
A bunch of the packages in the release at hand were actually upgraded, not downgraded, for example.
A counterargument would be that Rust+Cargo pins specific versions already. If you’re writing Rust, you should rarely need to vendor anything unless you’re maintaining a patched version or something.
Vendoring also bypasses the package cache and build cache. If 2 apps depend on foo-1.2.3, they can normally share the cached package and its build artifacts.
Basically, Cargo goes a long way toward ensuring you rarely need to bother with adding someone else’s code to your repo.
Oh, guess it does. I've been using sccache so long that I'd forgotten that.
Do you know off-hand why it doesn't, though? If 2 packages use foo 1.2 with the same features and, say, the default build settings, why not share them by default?
I think at the time Cargo was made it was just far simpler to implement. It's not just that, it's also rustc version, sometimes environment variables... much less likely to cause problems by keeping it per project. Of course that stuff still needs to be kept track of, but like, "to get a clean build, kill this directory" seems easier. Not sure if there is an explicit justification written down anywhere from 11 years ago.
I don't understand the connection between censorship and congestion control. Surely there's a good quadrant where everyone plays nice in terms of congestion control, even though there are bad actors doing censorship in other ways? Surely censorship isn't generally performed by making the network artificially congested so that you may access the censored material but a bit more slowly?
That's actually part of the situation in China --- degraded network situation to certain part of the Internet. You may be able to establish connections e.g. Github, and even okay to download release from S3, but usually speed is stable around 2-3kb/s, which is effectively useless.
I am not certain this is due to the censorship, but this issue is sitting there for at least a decade.
Big Corps in China usually setup their own VPN/Private Line to workaround this situation.
Okay, say it's part of the censorship, and parts of the Internet are intentionally "soft-blocked" in the way you describe.
If the degraded performance some kind of artificial throttling, then I have a hard time understanding how an antisocial congestion control algorithm would help. If there's some middle box tasked with providing every IP address no more than 2kbit/s, then it should be able to do that job just fine even if you keep throwing lots of packets at it, right?
If the degraded performance is simply due to intentionally terrible infrastructure and there's real congestion going on due to many Chinese people trying to access the Internet at the same time, then using an antisocial congestion control algorithm might give you faster transfers, at the cost of everyone else. If everyone started using these antisocial congestion control algorithms, the end result would simply be that nobody would get to communicate with those "soft-blocked" parts of the Internet, not even at those 2 kbit/s.
In short, I don't understand how this could even in principle be an effective tool for fighting censorship. I'm happy to reconsider if anyone describes such a use case in technical detail though.
Here is the opinion from the author, unfortunately it only has Chinese version but here is the relevant part translated using deepl:
> And if you insist on sending packets, even though the other traffic does not give way, since your packets are taken more proportion of the traffic, they would more likely to be selected. Whether it's "ethical" to "grab" bandwidth in this way is a subjective question, but the objective root cause is the urgent need to expand the operator's equipment with insufficient bandwidth. Operators should not expect users to be "sympathetic" to the lack of backbone capacity - the operator has contracted a rate with the user and the user is not cracking that limit, just using the bandwidth that the operator has committed to them, which is reasonable behavior.
Personally I don't think it is a good idea, but I was in that situation during my high school, and it was terrible. I get the idea why this project would exist sooner or later and just trying to present some context for discussion.
the intentionally terrible speeds are decided by software heuristics, so antisocial limits are fought with antisocial techniques, with continued brutality being enough to skip the slow deep packet inspection path via force
it's your first scenario. the infrastructure is fine, but there's a middlebox in the way, doing whatever it can to fuck with your connection. the middlebox will drop packets. this middlebox will invent RST packets and spam them at you to make you think the connections been dropped. using the antisocial congestion control manages to get you more than 2Kbps with the middlebox still doing its thing.
