It's a very conservative warning. The application does not perform writes, so the application doesn't actually wear your SSD at all. The rest is just application-independent general hygiene.
You still have a core misunderstanding. Only one layer of weights is required in memory at a time. A forward pass can be over-simplified as a matrix multiplication of each layer, one at a time.
There is no swapping of working RAM. We're just talking about loading the weights read-only data into RAM on-demand for each layer. It is only as slow as your storage interface.
Both sentences are likely wrong. It's a written lifespan (technically an "erased" one), not a read lifespan. The weights are only needed from disk read-only. And Mac NVMe interfaces are surprisingly fast.
Edit: Oh, I think you maybe thought I meant swapping working RAM off disk? I didn't. I meant swapping weights off disk into RAM on-demand.
I've got access to a 192GB RAM Mac Studio, which is below the stated minimum RAM. Can swapping off fast disk be used to make it work out, especially since it's MoE?
ChatGPT reconstructing idiomatic Python source code from Python bytecode was definitely up there. That is not something humans have written a great deal about online. It requires simulating the Python VM.
I remember also having a massive wtf reaction to realizing that original ChatGPT was pretty good at decoding long random/unique base64 strings.
> If it detected any harmonics it would be too high.
I think it's not that simple. A tuner is "hearing" the fundamental and all of the harmonic overtones combined. It has to guess at which frequency is the fundamental, even if the overtones are actually stronger than it amplitude-wise, and it does that by looking at the nature of the repeating overtone pattern and extrapolating back to the fundamental.
I think you can end up an octave too low (half the actual frequency) if the waveform repeats in a way that implies a different overtone repetition pattern, for example if there's an every-other-cycle artifact to the waveform.
Inference (not training) is bottlenecked by memory access speed, not compute. Having special hardware wouldn't make it faster unless you somehow found a faster memory controller than the GPU has.
But my argument isn't that freedom of speech could be used as an excuse for something that would otherwise be illegal -- my argument is that publishing and discussing exploit code is a constitutionally-protected activity. The CFAA statutes can be violated by gaining unauthorized access to a protected computer system, but that did not happen in the process of authoring and publishing the exploit code. The attacker was authorized to release new versions of the software, and they did. Their choice of what to make their software actually do is not regulated by the government, any more than a musician's choice of which lyrics to include in their song.
If an attacker then actually uses the backdoor created by someone else's decision to deploy the new release into their own environment, to gain unauthorized access to a protected computer system, then obviously there's a CFAA violation there. The public facts don't contain documented examples of this having happened (yet), though it will be unsurprising if that changes.
So it is still not obvious, at least to me, that any crime under US law has occurred so far. I am not a lawyer, though I'm aware of how badly the government has lost the previous court cases that attempted to restrict what humans can put in source code.
OpenSSL's "notification of an upcoming critical release" is public, not private.
You do get to know that the vulnerability exists quickly, and you could choose to stop using OpenSSL altogether (among other mitigations) once that email goes out.
No, freedom of speech (as far as I know) protects even exploit code. The statutes being linked would cover using the backdoor to gain unauthorized entry to a system. I think the question of whether anything illegal has occurred from the public facts is unclear, at least to me, and interesting.
I think you are confusing non-state e.g. ransomware groups, which are usually not part of a government (although some exceptions like North Korea likely exist) with state-sponsored hackers who are often directly working under military command. Soldiers are not "dicks on the internet".
In this particular case, there is a strong reason to expect exploitation in the wild to already be occurring (because it's an intentional backdoor) and this would change the risk calculus around disclosure timelines.
But in the general case, it's normal for 90 days to be given for the coordinated patching of even very severe vulnerabilities -- you are giving time not just to the project maintainers, but to the users of the software to finish updating their systems to a new fixed release, before enough detail to easily weaponize the vulnerability is shared. Google Project Zero is an example of a team with many critical impact findings using a 90-day timeline.
This isn't usually done, because node_modules often contain machine specific (e.g. 32-bit vs 64-bit x86) or OS specific (e.g. Linux vs Mac) compiled native code.
I agree that the distributor having control over offering different artifacts to different individuals is very risky.
I was assuming that the sites that you might `curl | bash` from are third-party sites (i.e. not your Linux distribution) that you don't have an existing trust relationship with, which makes it impossible to avoid this capability. That's the situation people use curl | bash in.
So I think this ability to individualize artifacts would still be present if we were receiving a .deb or apt key instead from that site.
> you'll have a saved copy of the key afterward
Yes, though since dpkg post-install scripts can modify arbitrary files (right?), you can't trust that any files on your disk are the ones that existed before the compromise. So couldn't the malicious key verify the malicious package, which then overwrites the copy of the package and key on-disk with the good versions that were given to everyone else?
dpkg doesn't stop you overwriting system files in a post-install shell script, as far as I know? Which is the way that a malicious package would choose to do it. I don't think dpkg performs any meaningful security review in the way you describe.
I don't think there are very meaningful differences in the security properties -- I don't think it's more difficult to become compromised by one than by one of the others.
I mean, I guess I see them making a three-stage argument:
1) Distributing software via bash script is a bad idea
2) Sensible people review the bash scripts they downloaded before running them
3) But haha! Here is a clever trick that evades that review.
And I'm not persuaded by 3) being interesting because I already rejected 1) and 2), and I consider 3) to just be proving my point -- you (for all you!) are not competent to perform a very brief but somehow thorough security review of a shell script that probably has further dependencies you aren't even looking at, and the actual reasoning to apply when deciding to install software this or any way is purely "Do I trust the entity I have this TLS connection open with to run code on my machine?".
That's a way in which "curl | bash" distributed software is better than .deb/.dmg distributed software, right? Because you have the potential to inspect the script first, if you have some kind of ridiculous confidence in your ability to perform security review of an entire software product in the moments before you decide to install it.
But it's never presented in that way, as a feature. It's presented as a terrible way to distribute software.
Neat! But it's not obviously a bad idea. You have a TLS connection with the site you're downloading from. `curl | bash` is no worse than downloading a .dmg or .deb from the same server would be.
Previously: keybase.io, gittorrent.org at Recurse Center, VP of Engineering at FlightCar (YC W13), Linux kernel SD card subsystem maintainer.
https://printf.net/
[ my public key: https://keybase.io/cjb; my proof: https://keybase.io/cjb/sigs/r1jKbK2XHT3K67jMZN5eZydp5Y3bnwbrv7Eqkm1-wqU ]