That's just like your opinion man.
patatahooligan
Of course they're not "three laws safe". They're black boxes that spit out text. We don't have enough understanding and control over how they work to force them to comply with the three laws of robotics, and the LLMs themselves do not have the reasoning capability or the consistency to enforce them even if we prompt them to.
I'm sure many people don't even think about that. Having to reinstall all your packages from scratch is not something they do frequently.
And for the people who are looking to optimize the initial setup, there are many ways to do it without a declarative package manager. You can:
- Write a script for your initial setup that includes installing packages
- Use a tool like ansible
- Use meta-packages
- Export your currently installed packages to a file and pass that to the package manager on the new installation
Many times these keys are obtained illegitimately and they end up being refunded. In other cases the key is bought from another region so the devs do get some money, but far less than they would from a regular purchase.
I'm not sure exactly how the illegitimate keys are obtained, though. Maybe in trying to not pay the publisher you end up rewarding someone who steals peoples' credit cards or something.
NVMEs are claiming sequential write speeds of several GBps (capital B as in byte). The article talks about 10Gbps (lowercase b as in bits), so 1.25GBps. Even with raw storage writes the NVME might not be the bottleneck in this scenario.
And then there's the fact that disk writes are buffered in RAM. These motherboards are not available yet so we're talking about future PC builds. It is safe to say that many of them will be used in systems with 32GB RAM. If you're idling/doing light activity while waiting for a download to finish you'll have most of your RAM free and you would be able to get 25-30GB before storage speed becomes a factor.
So the SSD is hiding extra, inaccessible, cells. How does
blkdiscard
help? Either the blocks are accessible, or they aren't. How are you getting a the hidden cells withblkdiscard
?
The idea is that blkdiscard
will tell the SSD's own controller to zero out everything. The controller can actually access all blocks regardless of what it exposes to your OS. But will it do it? Who knows?
I feel that, unless you know the SDD supports secure trim, or you always use
-z
,dd
is safer, sinceblkdiscard
can give you a false sense of security, and TRIM adds no assurances about wiping those hidden cells.
After reading all of this I would just do both... Each method fails in different ways so their sum might be better than either in isolation.
But the actual solution is to always encrypt all of your storage. Then you don't have to worry about this mess.
I don't see how attempting to over-write would help. The additional blocks are not addressable on the OS side. dd
will exit because it reached the end of the visible device space but blocks will remain untouched internally.
The Arch wiki says
blkdiscard -z
is equivalent to runningdd if=/dev/zero
.
Where does it say that? Here it seems to support the opposite. The linked paper says that two passes worked "in most cases", but the results are unreliable. On one drive they found 1GB of data to have survived 20 passes.
Sign the petition even if it's surpassed 1mil signatures by the time you read this! The signatures will be verified after the petition is complete. This could lead to removal of any number of them. We don't want to barely make it. Let's go as high as possible!