That's not a tax, that's the expense ratio, which is basically describing fees captured by the fund manager. Funds accessible to Dutch investors involve similar ERs. It's not an alternative.
DALI (IMO: 9697428) is a Container Ship and is sailing under the flag of Singapore. Her length overall (LOA) is 299.92 meters and her width is 48.2 meters [1].
Based on the track, it appears the ship changed course slightly and slowed as it approached the bridge [2].
For a long while I've trusted and used various KeePass ports/forks on my phone and laptops and stored the password file in cloud storage.
With the recent LastPass exposure, the supply-chain attack on PyTorch, needing to be vigilent and avoid granting apps access to my cloud drive, I've actually just been reviewing my setup and workflow.
Here's what I'm planning to change...
Phone: Switching from MiniKeePass to KeePassium. I've found it's not too difficult to build KeePassium from source and install without needing an Apple Developer subscription. This means I can properly audit the code and control/verify all updates.
Laptops: Start building KeePassXC from source. In the short term, I'll be more diligent in obtaining updated versions from trusted sources and using PGP to verify the package.
File sync: Start storing the password file on a self-hosted file server. Having recently setup Tailscale on all my devices, it's now convenient to manage Samba and remove cloud storage from the system. In case the SMB share is inaccessible, I'll fallback to the backups kept by KeePassium and use cron+rsync to maintain an secondary copy on my laptop.
Backups: I'm planning to periodically backup to a hardware keypad encrypted USB drive. In comparison to a regular USB / external drive, the hardware encryption makes it harder for somebody to quickly make a copy of the password file and take it away to be brute-forced.
Would welcome any pointers on things I may not be considering or suggestions for improvement!
As explained in another thread, nothing went wrong with the tooling and namespacing. The PyTorch devs misused a feature intended for a different use-case.
I took a look and the vulnerability that was exploited is warned about and described in the documentation.
> Warning
> Using this option to search for packages which are not in the main repository (such as private packages) is unsafe, per a security vulnerability called dependency confusion: an attacker can claim the package on the public repository in a way that will ensure it gets chosen over the private package.
> This coffee is still good. It was roasted in June and July 2022 with a one year best buy date.
Still good but hardly fresh for a specialty.
Anyway. There’s a 6x number in here that somebody (or somebodies) completely missed…
Seems like what they thought was a fair-to-good deal was actually a such a terrible deal that, given their incorrect definition of a unit, the numbers in their model lined up.
That might be something the consultant could have spotted, since they’d seen the numbers around previous deals. I’m not sure it’s their duty/obligation to.
Can you elaborate with some examples of workflows that it is incapable of?
So far I’ve not found any limitations or issues using Ubuntu runners on my OSX dev machine. A couple examples from my workflows:
- building docker images
- provisioning VMs with the Digital Ocean cli / http api
- hardening VMs with ansible
- creating/managing k3s clusters with k3sup
- deploying apps with helm
I like your suggested approach of using tmate to access the worker mid-way through a run. This should make it faster to develop/debug the steps that make up the workflow. Though this doesn’t address the cycle time of push-to-GitHub/queue-workflow/watch-for-result.
I’m actually going to try combining the two techniques - use tmate to develop inside a local act runner.