- mirashiiI’d be curious about sentiment analysis applied to these. I expect two of the listed to have very positive sentiment, and one generally negative in 2025.
- Unless the CD comes with a root kit that interferes with that copying. https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk...
- > Do library authors have to test against every type checker to ensure maximum compatibility?
Yes, but in practice, the ecosystem mostly tests against mypy. pyright has been making some inroads, mostly because it backs the diagnostics of the default VS Code Python extension.
> Do application developers need to limit their use of libraries to ones that support their particular choice of type checker?
You can provide your own type stubs instead of using the library's built-in types or existing stubs.
- This is a network carrier setting, the issue is that T-Mobile (and maybe others) pushes a profile that does this as part of their network configuration.
- > Odds are, you’re not going to get any contributions even if you do want them. So they could just upload regardless.
This is not my personal experience nor the experience of a number of folks that I know personally. I think it's pretty hard to generalize about this.
> The vast majority of stuff on GitHub goes unnoticed by the vast majority of people. And only a very small minority of people ever interact with the few projects they do pull from GH.
So what? It's probably not going to impact you, so it's okay and we just have to deal with it? I reject that logic entirely.
- Unfortunately, and I think to great overall harm, GitHub does not let you disable many of the collaboration features. I was just having a discussion today with someone who would be fine open sourcing their code, but is uninterested in any contributions, questions, or community interaction. Since GitHub won’t allow that, their options are to host it somewhere themselves where nobody will see it, or just don’t publish it, which is ultimately what happened.
- You don't need to MITM docker for this, you can just configure your containerd or equivalent backend properly.
- In practice you don't actually need kernel code on a bunch of platforms for this, e.g. NETransparentProxyManager on MacOS. This is not necessarily an endorsement, just worth not mixing in unrelated issues.
- > -fno-strict-aliasing doesn't suddenly make pointer aliasing defined behavior.
No, it just protects you from a valid but unexpected optimization to your incorrect code. It's even spelled out clearly in the docs: https://www.gnu.org/software/c-intro-and-ref/manual/html_nod...
"Code that misbehaves when optimized following these rules is, by definition, incorrect C code."
> We have compiler behavior for incorrect code, and it's refusing to compile the code in the first place
This isn't and will never be true in C because whether code is correct can be a runtime property. That add function defined above isn't incorrect on its own, but when combined with code that at runtime calls it with values that overflows, is incorrect.
- > All addition operations over ints are potentially invoking UB.
Potentially invoking and invoking are not the same.
- > If Microsoft makes a guarantee in their documentation about some behavior of UB C code
But do they? Where?
More likely, you mean that a particular compiler may say "while the standard says this is UB, it is not UB in this compiler". That's something wholly different, because you're no longer invoking UB.
- > But from my own experience, UB just means "consult your compiler to see what it does here because this question is beyond our pay grade."
People are taught it’s very bad because otherwise they do exactly this, which is the problem. What does your compiler do here may change from invocation to invocation, due to seemingly unrelated flags, small perturbations in unrelated code, or many other things. This approach encourages accepting UB in your program. Code that invokes UB is incorrect, full stop.
- I’m not sure there’s anything clever that resolved the issues, they just settled on slow execution times by accepting a dynamic dispatch on generics.
- This comment from a dupe thread is worth considering: https://www.hackerneue.com/item?id=46137352
- I agree, and I personally wouldn't call golang memory safe for that reason. Thomas's semi-definition includes the word "vulnerability", which narrows the scope so much that golang fits under the bar, since the common data race that causes memory corruption hasn't been shown to be exploitable without being contrived.
My personal definition of memory safety for a language like golang would specify that you can't cause this sort of memory corruption without an explicit call to unsafe, but there's no real definition to fall back on.
- > What are the chances of that, though?
The whole premise of the article is that they’re substantially lower, because some time for the ecosystem of dependency scanners and users to detect and report is better than none.
- The check frequency isn't the problem, it's the latency between release and update. If a package was released 5 minutes before dependabot runs and you still update to it, your lower frequency hasn't really done anything.
- It feels like perhaps you’ve conflated the issue in this thread, which is about using Rust in apt, which is much, much later in the distribution bringup than this bootstrapping, and using Rust in something like the Linux kernel, which is more relevant to those types of bootstrapping discussions you posted.
apt is so late in the process that these bootstrapping discussions aren’t quite so relevant. My point was that at the same layer of the OS, there are many, many components that don't meet the same criteria posted, including perl.