![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://lemdro.id/pictrs/image/6d56629c-a7b1-465d-8b58-ad77926e3a41.png)
The iPhone 15 is 147.6 height x 71.6 width x 7.8 depth (mm).
The Pixel 8 is 150.5 height x 70.8 width x 8.9 depth (mm)
I would call that pretty much the same size.
The iPhone 15 is 147.6 height x 71.6 width x 7.8 depth (mm).
The Pixel 8 is 150.5 height x 70.8 width x 8.9 depth (mm)
I would call that pretty much the same size.
No they don’t? The iPhone 12 mini and iPhone 13 mini were the worst performing phones out of their lineup. Small phones are dead because hardly anyone buys them.
Texas does have anti-SLAPP laws passed and they are among the strongest in the nation. Unfortunately, the courts have ruled that they cannot be used in federal courts.
No. Modern SSDs are quite sophisticated in how they handle wear leveling and are, for the most part, black boxes.
SSDs maintain a mapping of logical blocks (what your OS sees) to physical blocks (where the data is physically stored on the flash chips). For instance, when your computer writes to the logical block address 100, the SSD might map that to a physical block address of 200 (this is a very simplified). If you overwrite logical block address 100 again, the SSD might write to physical block address 300 and remap it, while not touching the data at physical block address 200. This let’s you avoid wearing out a particular part of the flash memory and instead spread the load out. It also means that someone could potentially rip the flash chips off the SSD, read them directly, and see data you thought was overwritten.
You can’t just overwrite the entire SSD either because most SSDs overprovision, e.g. physically have more storage than they report. This is for wear leveling and increased life span of the SSD. If you overwrite the entire SSD, there may be physical flash that was not being overwritten. You can try overwriting the drive multiple times, but because SSDs are black boxes, you can’t be 100% sure how it handles wear leveling and that all the data was actually overwritten.
It’s been a while since I took statistics, but yes, I guess that is a binomial distribution. It does not influence the results in the way you are implying it does, though. The calculator does actually account for it (the Population Proportion input), and the sample size actually decreases the lower/higher your proportion is. My point was that a question like, “Do you watch anime weekly,” is not like a question like, “How many hours of anime do you watch in a week,” where you certainly couldn’t assume a normal distribution for the number of hours watched.
Normal distribution with regards to what? “Do you watch anime weekly” is a binary question. There really isn’t a distribution associated with that.
You don’t need a massive sample size for surveys to give meaningful information. Play around with this sample size calculator if you want to see what the margins of error are: https://www.calculator.net/sample-size-calculator.html?type=2&cl2=95&ss2=4000&pc2=5&ps2=500000000&x=Calculate
the timer has no idea if it was triggered during last boot. It only has the context of “this” boot, so it will do it right after a reboot and set a timer to start the service again after a week of uptime.
This is not correct. Persistent=true
saves the last time the timer was run on disk. From the systemd.timer
man page:
Takes a boolean argument. If true, the time when the service unit was last triggered is stored on disk. When the timer is activated, the service unit is triggered immediately if it would have been triggered at least once during the time when the timer was inactive.
OP needs to remove Requires=backup.service
from the [
section so it stops running it when it start the timer on boot. ]
You have the timer requiring backup.service, so it will run that service every time the timer starts on boot. Remove Requires=backup.service
, and that will fix the issue.
Well, for one, it’s network attached storage. If it’s not present in the network for one reason or another, guess what, your OS doesn’t boot… or it errors during boot, depending on how the kernel was compiled and what switches your bootloader sends to the kernel during boot.
Just use nofail
in the fstab.
Second, this is an easy way for malware to spread, especially if it’s set to run after user logon.
If your fileshare is accessible to you, it is also accessible to malware running as your user. Mounting the share via a filemanager doesn’t change this.
Then which Apple phone are you talking about? The iPhone 15 is pretty much the same size as the Pixel 8. The iPhone SE is the only small phone Apple seems to make, and from what I can tell from a quick search, they aren’t selling a lot of them.