ahnick

What's the process for resolving conflicts?

Anyone who needs storage space for pictures cares about backup, they just may not be aware that they care about it or they may just conflate the two needs.

What's the cons of the ZFS approach?

I would assemble your own using FreeNAS/TrueNAS or buy a TrueNAS system that is already built for you. Having a full FreeBSD based system with modern ZFS is much more robust and does not come with any restrictions.

> I found a hole in the fifty year tornado map

What was your source for this information?

The difficulties mentioned in the article with passing secrets on the command line is one of the reasons why we wrote encpass.sh (https://github.com/plyint/encpass.sh). We had a similar need for a lightweight solution for managing secrets for simple shell scripts on our local workstations and in restricted environments. Bonus, it can be easily customized with extension scripts to adapt functions for your own specific needs. See our keybase extension for an example -> https://github.com/plyint/encpass.sh/blob/master/extensions/...

Not having integrations is a deal breaker for me. All of my financial information lives in other systems that I need to be able to import it into a single view that I can manage. There is no way I'm going back and manually entering all of that info. A privacy centric solution would store credentials for systems like plaid, bank accounts, etc. in the client on the OS keychain and open source that part of the code to be audited. The data then would be stored preferably on a self-hosted server or your cloud provider of choice. There is some sweet spot here at the intersection of the personal cloud server movement and local client credential storage that none of the current finance apps have yet addressed. Once someone does I think they may have a real hit on their hands.

We made an extension for encpass.sh (similar in some ways to pass) that stores secrets in Keybase (https://github.com/plyint/encpass.sh/blob/master/extensions/...) if that sort of thing is of interest to you. Outside of personal secrets, it can be used as a sort of low cost stand in for shared secrets that you might use something like Vault for in a team environment.

It's the HN hug of death now. :)

For the same reason that people don't just leave all their money tied up in ETFs or indexed mutual funds. If you really want or really need something, then you are willing to give up on the opportunity cost of your asset appreciating.

In a pure BTC environment, the borrower is employed and being paid a salary in BTC. Loans would work just like in an inflationary environment, except now the overall deflation rate of BTC would be taken into account during loan origination.

Bitcoin is not a good asset to do loans in right now as it has high volatility, but as ownership of Bitcoin becomes more and more dispersed, then the volatility will reduce. Once the volatility of the asset is stabilized, then the depreciation rate could be factored into loans.

https://bitcoin.stackexchange.com/questions/1899/if-the-econ...

The interest rate on the loan was 3.5%. Long term capital gains in the US are typically 15% (short term 30%), so using a CDP can save a lot of money depending on the tax laws that apply to you.

He avoids capital gains in the article by using a MakerDAO CDP. This is a loan that is collateralized by his Ethereum holdings. (IIRC 1.5 ETH to the amount of DAI you want)

It's only avoided b/c in traditional economies there is no way to subdivide units of a denomination. (e.g. There is no way to split a penny into thousandths) Cryptocurrencies are purely digital and do not have this limitation. The only limitations are self-imposed by the algorithms themselves.

If Bitcoins were the dominate and only currency, people would continue to buy food, clothing, luxury goods etc. b/c they need or really want those things and will be willing to trade bitcoins in exchange for those goods. Practically, Bitcoin is unlikely to be the dominate currency allowed in countries to participate in transactions without incurring significant taxes, so likely people will store wealth in Bitcoins(or other cryptocurrencies) and then convert to fiat currencies as they need to make their purchases.

If BTC is the only currency and everyone is transacting in BTC, then people are incentivized to hold BTC. Now that everyone is holding BTC, the value of their holdings are increasing alongside everyone else holding BTC. If you go into the store to buy items you will notice that the price in BTC terms will be decreasing b/c more BTC can't be "printed". (Each BTC is worth a lot now and continually increasing, but at a predictable rate) Each person will continue to pay with less and less BTC over time all the way until the lower unit bound, which is a satoshi (0.00000001 BTC), is reached. If we ever reach that point in our lifetime the code will need to be forked to upgrade the protocol to handle further subdivisions.

I think it's probably not that clear cut. What happens in a cascading blackout scenario? If you are part of a larger pool are you more exposed to have a service disruption now when there is a problem in another part of the grid of the pool that you don't directly control?

> The LiveView function almost doesn't work but a third party app allows me to display the tablet on the desktop for Zoom meetings.

What's the third party app?

Yes, exactly. If you lose it or it's stolen, then you'd want to rotate to a new key quickly. Some of these devices have a pin too, so the attacker needs to crack the pin before they can actually use the device. This should hopefully buy you enough time to bring up a new device and switch over accounts. That's why it's probably a good idea to buy your second device when you buy your first one and store it in a separate, reasonably secure, but more importantly, quickly accessible, location.

Some devices derive their keys from a recovery seed that you can store offline in paper form. The benefit of this approach is that you can recreate the key on a backup device using the recovery seed, should you lose your primary.

Most people can't put >$20,000 on their credit card and large money transfers over traditional financial institutions (wires/ACH) at best take many hours or days.

I think it's easier to understand in the analogy of signed vs unsigned baseball cards. The images on the baseball cards are identical, but the only difference is the baseball player's signature is on one and not the other. This is just the digital equivalent.

The Apache projects page literally lists "Apache" in front of each of the projects you just mentioned. If I go to the apache streams github page it's url is https://github.com/apache/streams not https://github.com/streams/streams.

Contrast that when I go to the Docker distribution github page the url is https://github.com/distribution/distribution. You don't see anything wrong with that nomenclature? I'm the only one?

I suppose as long as everyone knows the etymology of this "distribution" and remembers to use the word docker before it, then it should be fine. Probably a conversation best had 10 years from now. :)

it's not about "catchiness", it's about being able to have a unique moniker, so whoever is searching for it can find it. "Distribution" immediately is going to clash with the multitude of linux distributions. They could have named it "image-distribution", "container-image-distribution", "cidistribution", whatever.. just something that makes it easier to find via search.

Based on your experience then, do you feel something like Fedora Silverblue will ultimately be more successful than a NixOS approach?

If you are against traditional package management, what is the argument for this approach over something like NixOS? This doesn't seem to do anything for trying to roll back to a previous known working state, which is probably my biggest issue with the way most mainstream linux distributions package management works today.

Your current approach sounds fine from the perspective of bitrot. The hole in your approach right now is protecting from incorrect updates made either by yourself or by an application to your data that you don't notice immediately.

For example, say you are using a financial application like GnuCash on your desktop and it has bug in the software that gets triggered causing a bad write to the file. (power goes out, OOM, whatever..) syncthing will happily propagate that changed file that contains the bad write to your server and when you copy to the 3rd disk you will also propagate that changed file. You deleted what was on the third disk, so now you no longer have a "good copy" of the file.

If you add some sort of snapshotting into your backup routine, then you would be protected from this, because even though you would still propagate the change to the most recent backups, you could still go back to an older snapshot (maybe a week or a month ago or whatever) and pull back a working version of the file.

Fim is interesting, but I think most people (including myself here) don't worry about this because we rely on snapshots of backups. If a file was updated incorrectly then you just go back to the last known snapshot that worked.

Of course this is only as good as the interval you use for your snapshots. Fim seems like it would be a lot of extra work to do for every file/folder, but I could potentially see using Fim though for important files (e.g. tax records?, password vault?)

When you say you "copy all my files to a 3rd disk as a cold backup", do you mean you are overwriting any existing files on the 3rd disk? If so, I would recommend considering using something like Duplicacy (https://github.com/gilbertchen/duplicacy) to perform your backups with snapshots.

The reason being is you can decide how long to keep older copies of files, just in case something changes on a file, but you don't happen to realize the incorrect update for a couple of months and want to go back to an earlier version.

To give you an idea of what is possible, here is the snapshot configuration I use: Keep no snapshots older than 450 days Keep 1 snapshot every 90 day(s) if older than 180 day(s) Keep 1 snapshot every 30 day(s) if older than 30 day(s) Keep 1 snapshot every 1 day(s) if older than 1 day(s)

What happens if the checksum file created by ccheck experiences bitrot?

Yes, that's why it is important to make sure you have scrubbing set up on a regular recurring interval.