Note that N=1 for the memory safety vulnerabilities they had with Rust, so the error of the estimated average number of vulnerabilities per LOC is quite large.
Your best guess is that the true rate is 20x higher than the observed rate? This seems unlikely to me given the number of samples (outside of systematic biases towards certain types of memory safety bugs that probably apply to C++ code too). 10 per hundred MLOC is closer to what I would have guessed too, but that is because I've historically been very conservative with my assumptions about the memory unsafety rate per unsafe LOC being similar to that of C++. The evidence here suggests that the true rate is probably much lower than that.
I'm making a conservative guess, which is why I said 10 or less (10 or fewer??). So the improvement is at least a hundredfold. I might say 5 or less instead. I think the exact rate is not so important; either way, it's clear that Rust is a boon.
That you should be very careful about what you install. Cut&pasting some line from a website is the exact opposite of it. This is mostly about psychology and not technology. But there are also other issues with this, e.g. many independent failure points at different levels, no transparency, no audit chain, etc.
The counter model we tried to teach people in the past is that people select a linux distribution, independently verify fingerprints of the installation media, and then only install packages from the curated a list of packages. A lot of effort went into making this safe and close the remaining issues.
Be careful who you trust when installing software is a fine thing to teach. But that doesn't mean the only people you can trust are Linux distro packagers.
I think it has a lot to do with "curl|bash". Cut&paste a curl|bash command-line disables all inherent mechanisms and stumbling blocks that would ensure properly ensuring trust. It was basically invented to make it easy to install software by circumventing all protection a Linux distribution would traditionally provide. It also eliminates all possibility for independent verification about what was installed or done on the machine.
Downloading a deb via a package manager is more secure. Downloading a deb, comparing the hash (or at least noting down the hash) would also already be more secure.
But yes, that the run arbitrary scripts is also a known issue, but this is not the main point as most code you download will be run at some point (and ideally this needs sandboxing of applications to fix).
> Downloading a deb via a package manager is more secure.
Not what I meant. Getting software into 5 different distros and waiting years for it to be available to users is not really viable for most software authors.
Well, distros haven't really put any effort into making it viable as far as I know. They really should! Why isn't there a standard Linux package format that all distros support? Flatpak is fine for user GUI apps but I don't think it would be feasible to e.g. distribute Rust via a Flatpak.
(And when I say fine, I haven't actually used it successfully yet.)
I think distros don't want this though. They all want everyone to use their format, and spend time uploading software into their repo. Which just means that people don't.
Kinetic theory stuff for one, like deposition, growth, sandpile type things. Complex networks and lots of dynamics stuff falls under statistical physics umbrella but not statistical mechanics. Stat mech's amazingly wide applicability makes it easy to think it's THE approach to approaching things statistically, but it's not. The broad encompassing approach has a name, statistical physics.
There is a distinction. Usually statistical mechanics means the ensemble theory and partition functions that connects microscopic systems to macroscopic ones from material point of views. However, statistical physics is a bit more generic, for example complex networks may not use ensemble theory or partition functions and could use only statistics on the network, such as average neighbourhood or similar.
What I'm getting from this discussion is that we use Statistical Physics to refer to anything covered by Statistical Physics AND Statistical Mechanics, while we use Statistical Mechanics in a narrower context, but it is also possible that some use SM loosely.
That's a good question! Especially after Frank McSherry's COST paper [1], it's hard to imagine where the sweet spot for Spark is. I guess for Databricks it makes sense to push Spark, since they are the ones who created it. In a way, it's their competitive advantage.
I know some people who do trunk-based development with pair programming: You write the code together, and once you are satisfied, you merge it to the main branch, from where it is deployed to production if the tests pass. It works well for them.
It would require a lot more memory, because you have to remember every generated UUID. And how would you do the partial match? You are not going to observe any collisions.
