One thing that doesn't factor into this argument is the professional nature of the hit — how he managed the gun, the silencer, the messages on the bullets, the getaway, and the precise reconnaissance that allowed him to know exactly where his target would be at that exact moment.
That doesn't align with the characteristics of a typical personal vendetta.
At the rate insurance companies hurt people, it's likely they've hurt professional assassins, special forces people, etc. It doesn't have to be a hired hit to be professional in execution.
I knew a person who went on a personal vendetta against his old boss. The set up he did was very elaborate, including making it look like he went on a hiking trip the weekend he murdered the ex-boss. Unfortunately for him he was a prime suspect because their well-known beef.
Don't underestimate the amount of thought someone truly resentful will put to this kind of action.
The video shows the gun malfunctioning repeatedly and the shooter having to clear those malfunctions by racking the slide. That's likely caused by a poorly-installed silencer. Hardly professional.
If the ISOs are untouched (so it won't work for the posted "Delta Edition"), you can search the SHA hash of the version from MSDN. Relevant search keywords are "Microsoft SHA1 Hash Archive" :D
If you’re not actively writing to the database you can cp or commit it safely. SQLite uses a journal or a write ahead log (WAL) file to process transactions.
If you cp a database mid transaction you will loose the transaction as it is processed in the separate journal or WAL file until commit. If you copy mid commit then you will have incomplete data in the main database file and possibly data corruption.
Anything that only uses the file system copying mechanics is not safe (which includes a git check-in). I wrote a more detailed comment here: https://news.ycombinator.com/item?id=31387447
The Windows clipboard manager doesn't support search. Ditto does. As soon as you open it you can just type a subset of some thing you recall copying the other day and it will immediately filter to that entry (or those entries). Biggest reason.
Ditto also rearranges the items so the last pasted is at the top rather than the last copied. This is also helpful because if I'm pasting something regularly, it's nice for it to be at or near the top.
You can configure how much history you want Ditto to store, by days or number of entries.
The Ditto clipboard entries are not as visually bulky as the Windows clipboard history entries.
The Ditto window can be resized, the Windows clipboard manager cannot be.
Those are the main reasons for me. Ditto also has a bunch of more advanced features but I've never used them.
If I'm not wrong you can configure KeepassXC to only store credentials in the clipboard for a selected timespan (like 5, 10 or 30sec). You can also eliminate it entirely IIRC by using the autotype feature when entering credentials.
You can, but AFAIK the way it does that is by overwriting the clipboard with null data. If you have a clipboard manager, it may save your credentials before it is overwritten so that it can retrieved later, and in this case, it is not something you want. Some clipboard managers can be clever and detect a null overwrite and interpret it as a request not to save the overwritten content.
Autotype do not suffer this problem and is generally considered safer. Some password managers have an even safer "mixed" mode where part of the password is in the clipboard and another part is auto-typed, meaning you have to monitor both the keyboard and the clipboard to grab the password
At least one possible fix would be a clipboard management standard such that an application can both set and clear or overwrite a specific clibpoard entry's data.
(I'd prefer the clear/overwrite myself.)
Another option would be specific IPC such that clipped content is available to one and only one other application or process. There was a recent HN submission on the Unix password manager utility "pass", including the ability to supply passwords to a command via shell expansion rather than as a command-line parameter. The former doesn't reveal the password in either process listings or shell history, the latter does.
That's a relatively primitive option, a more robust standard might also be provided.
That doesn't align with the characteristics of a typical personal vendetta.