I don't think this is realistic in the default npm ecosystem where projects can have 1000s of dependencies (with the majority being transitive with fuzzy versions).
Though pnpm does have a setting to help with this too: https://pnpm.io/settings#resolutionmode time-based, which effectively pins subdependencies based on the published time of the direct dependency.
Thousands of dependencies is exactly why you need to do this. It's fragile and dangerous to have thousands of possible changes in your software every time you `pnpm install`.
There was an NPM RFC for this feature (though not as focused on supply chain attacks) in 2022, but the main response mirrored some of the other comments in here.
"waiting a length of time doesn’t increase security, and if such a practice became common then it would just delay discovery of vulnerabilities until after that time anyways"
The linked source this article was using states: "You might ask, maybe Hertz was charging Lee for having to top the Model 3's battery upon its return? According to the final receipt, the customer gave the Model 3 back to Hertz with the battery 96% full, the exact same state of charge it was picked up with. And, even if Lee hadn't done that, the maximum fee should've been $35"
> This customer actually returned the car with a 96% charge, the same as they’d picked it up at.
96% is not 98%. Agreed the fee is ridiculous, and it does appear it should have been a max of $35, and the update states Hertz corrected the overcharge.
Somehow the author is confused and thinks these charge levels are equal when they are clearly not.
Arguing 98% and 96% are materially different for the purposes of rental car fuel levels is extremely pedantic, as should be clear by how feasible it is to achieve a match to that resolution. And why stop at whole percentage points?
Not only that, that unrealistically strict standard is 10x stricter than gas cars.
on gas gauges the resolution is like 10%ish chunks that aren’t even equal width. My cars top bar lasts about 50% longer than the rest and no I don’t top up.
This is my experience as well. Low quality junk is often not present, and if it does show up, it's two mouse clicks to never see that domain again.
Also the ability to promote high quality domains helps even more with this (though i have found one needs to be careful with pinning domains, as it can lead to irrelevant results being shown first because they have some if the same keywords).
I tried to restore a ~200 GB file (stored remotely on a Hetzner Storage Box), and it failed (or at least did not finish after being left for ~20 hours; there was also no progress indicator or status I could find in the UI).
I also tried to restore a folder with about ~32 GB of data in it, and that also failed (the UI did report an error, but I don't recall it being useful).
Also, in general use, the UI would get disconnected from the repository every few days, and sometimes the backup overview list would show folders as being size 0 (which maybe indicated they failed; they showed up with an "incomplete" [or similar] tag in the UI).
yeah, I had some weirdness with the UI and disconnects as well. My takeaway from trying it was that I wouldn't want to use it for something if I need peace of mind for my data.
Just for fun, since I still had it installed and haven't gotten around to cleaning up the remote data, I updated to latest (v0.14.1) and tried the restore tasks again.
Both the single file restore and the folder restore worked, though the single file restore still didn't have any progress indicator I could see.
Looking through the changelog, nothing really stood out to me as something which would have fixed this. Not really sure what went wrong the first time around, perhaps it was network issues with Hetzner?
What's the point in being "hungry"? To fill the pockets of some soulless corporation and hope they'll pass down some scraps while making record profits?
I have worked at the same place for 5 years; worked hard, continuously received great/exelecent reviews, several promotions, but I have only just kept up with inflation the past few years (and am probably net negative accounting for the timing of the rases), and before that it was 2% effective (for top marks). Plus "post-COVID" forced RTO, with all the costs associated with that.
All in all, I am paid around the market rate (for the area) for my prior role, despite having performed at my current role for 2+ years now (with continued high marks).
I still put in an honest 8 hours of work, but no more (mostly). Sometimes I wish I could be like those who work a little as possible and likely get paid almost as much (or more if they joined after), but that's not who I am.
Because the initial "hi" forces a context switch which the recipient (after reading and replying) has to either: Sit idle while the sender writes their actual question, or try to context switch back for a tiny amount of time.
10:30:01 [Coworker] hi
10:30:12 [Me] hi
10:30:35 [Coworker] do you have time for a call?
10:30:39 [Me] sure
Versus:
10:30:01 [Coworker] hi, do you have time for a call?
10:30:16 [Me] sure
This example isn't really that bad, but it is showing basically the best case with a simple question. It gets a lot worse if the sender actually has to type out a long message, or if there's a gap between each response because the other person was busy at the time.
JP Morgan is not a local lawn care service, they have the funds to not make mistakes like this. Larger companies should be held to a higher standard because their actions have a wider impact.
> Larger companies should be held to a higher standard because their actions have a wider impact
Sure. My point is this has nothing to do with too big to fail.
Also, what is the impact of these records being deleted? If you have a claim that reasonably involves them, it is basically cashable due to the error. If nobody can show damages, it’s hard to argue this mistake had a wide impact.
Though pnpm does have a setting to help with this too: https://pnpm.io/settings#resolutionmode time-based, which effectively pins subdependencies based on the published time of the direct dependency.