This seems to store the zfs send stream. That's a bad idea.

> Incremental ZFS send streams do not have any of these properties and full ZFS send streams only have a few of them. Neither full nor incremental streams have any resilience against damage to the stream; a stream is either entirely intact or it's useless. Neither has selective restores or readily available indexes. Incremental streams are completely useless without everything they're based on. All of these issues will sooner or later cause you pain if you use ZFS streams as a backup format.

https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSSendNotA...

Patchwork is used by the Linux kernel: https://patchwork.kernel.org/

When I saw your submission title I thought it was that Patchwork.

> Hualien was 5.1 at 15.9 km

That's just an aftershock.

The main quake was three days ago. M 7.4 according to USGS: https://earthquake.usgs.gov/earthquakes/eventpage/us7000m9g4...

So for an earthquake that's almost 1000x as strong, you'd think it'd be talked about more.

Thank you! Yeah, a 7.4 is humongous. I did wonder about this because my wife's family reported quite intensive shaking and I've been in a 6-something before and that was quite disruptive. I can't imagine a 5.1 being that much.

One pitfall of this is that the decompressed contents of your initramfs must fit within half of your physical RAM since Linux decompresses it into a tmpfs.

Or if you set rootfstype=ramfs, then you can take up to all of physical RAM, but ramfs isn't swappable.

Wait I'm not following, why must the decompressed contents of the initramfs fit within half of physical ram?

Initramfs (and tmpfs) are swappable right? As you say, ramfs is the one that isn't swappable. So if your initramfs is "to big" can't it just be swapped out?

> Wait I'm not following, why must the decompressed contents of the initramfs fit within half of physical ram?

It makes sense if you replace "initramfs" with "initrd":

> One pitfall of this is that the decompressed contents of your ~initramfs~ _initrd_ must fit within half of your physical RAM since Linux decompresses it into a tmpfs. > Or if you set rootfstype=ramfs, then you can take up to all of physical RAM

I'm very confused by your comment. The grandparent comment talks about using the gitrevisions syntax in a GitHub URL to search the reflog stored on GitHub. Nothing to do with your local clone of a repository.

Yes, I refer to the reflog on GitHub’s git file servers which tracks the historical state of refs there.

I'm sorry, I was on mobile and for some strange reason didn't check the whole link. I guess I was tired.

Incredible, I didn't know about it.

Last I checked it didn't even have a notion of currency, let alone multiple currencies.

Yep. The Transaction type has just an amount field: https://github.com/actualbudget/actual/blob/master/packages%...

That's not a reasonable requirement at all. A common recommendation nowadays is to have passphrases..

You're right; if the pass phrase has twenty random words, some of which are select or insert, then that's a bad diagnostic.

I just received mine. It's indeed great!

Wait till you forget your password one day.

That's easy, their password is TrustNo1! ;-)

Seriously, all the people of my parents generation have a physical book with account names and passwords in it. You keep it in a safe place, and nobody can hack it remotely.

Plus, should your heirs or caretakers need to access it, it's all there in plain text for them.

[waves hand] That would be me.

Other than a few web forums, I don't use my phone for anything that requires a password. Certainly not for email, banking, or anything that involves personal data, money, or business. A lot of stuff, I don't do on my desktop either.

Anything connected to the internet is insecure. No, it's not as convenient to do things by phone or paper mail, but I value security more than convenience.

Firefox has way too many components to be "just one repo you can fork".

All the code you need to build Firefox for Linux, macOS, or Windows is in one Mercurial repo: https://hg.mozilla.org/mozilla-central/

The repo is also mirrored on GitHub for convenience, though PRs are not accepted through GitHub: https://github.com/mozilla/gecko-dev

The build instructions start with a script (“mach bootstrap”) that will download and install all the blessed tools and SDKs needed to build: https://firefox-source-docs.mozilla.org/setup/index.html

Depending on your network and computer, it can be possible to download the source and compile and run your own Firefox build in less than 20 minutes.