ylyn

You assert that ECC RAM being necessary for ZFS is just a myth but provide no justification for why that is untrue.

Is it not the case that if you don't have ECC memory, ZFS could end up writing a checksum that does not match the data if you get a bitflip in just the right (wrong) spot?

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.

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.

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.

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

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

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

I just received mine. It's indeed great!

Wait till you forget your password one day.

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

> They're the ones who have normalised constant churn and thus needing to keep drivers for hardware, sometimes many years old, up to date year after year or even month after month.

That's exactly why you should mainline your code. Then people refactoring other subsystems will fix your code for you.

I can't believe people are trying to extrapolate this situation into how someone would act as a manager in a company.

Can't you see that the kernel has its own conventions and practices that are entirely different from typical corporate practices?

> A patch is a patch and the author should be credited as such.

But the patch was not taken. The maintainer fixed it a different way. So credit is given for reporting the issue and suggesting a fix, and that is what is represented by the Reported-By. Is that so hard to understand?

No, that's not what "Reported-By" means. The kernel community has different conventions.

This entire HN comment section is ridiculous with everyone acting as if the author wrote an entire subsystem and someone else took attribution.

The author here figured out a bug and suggested a fix. It happens that they conmunicated their fix in the form of a patch, but that happens very regularly in kernel land.

In the end the author got a Reported-By, which is entirely appropriate for what happened. If the maintainer accepted the author's patch as-is or with minimal modification then yes, they should get Author attribution. But the patch that was taken was substantially different.

Then write your own wrapper on top of Git.

As someone who partly works on the Linux kernel for a living I still don't really know what your point is.

Isn't this just how mounts work? If you have a something mounted to /apex/whatever and each app has a separate mount namespace, then mounting over /apex/whatever in your namespace wouldn't change anything in any other mount namespace. You'd need to either just alter the filesystem directly, or enter the other apps' mount namespaces and mount your tmpfs there too.

Shared mounts might be useful here. Not sure. I'd need to take a closer look at what is going on here.

But I would say this result is probably a byproduct of whatever namespacing/containerisation Google is doing, rather than an intentional effort to prevent users from changing the root CAs even as root.

Why?

As someone who's lived here for more than 20 years, I really don't know what you mean.

cgroups aren't even the main thing. The main thing is the mount namespace.

No, I don't think they can really fork it. How are they going to get support for new hardware in their fork?

Then Debian is the wrong distro for you.

Debian is for people who want to configure a server once and have it stay running and secure.

"Stability" in Debian's context means _version_ stability, not that it doesn't crash. I think most Linux distros aim to not crash.

The reason for this is that in Windows the DE is part of the system so it knows what to keep in memory.

On Linux the DE and shell and htop is just another program so when the system is under high memory pressure those things also get swapped out and back in when they need to run. Thrashing.

If you run something like memlockd to keep vital binaries from being swapped out I'm sure you will see that behaviour improve.

Definitely not elegant. https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp...

I rather have a kernel-level filesystem remapper.

I interviewed at Canonical, doing all of the written stuff, and got an offer. But in the end I turned them down because their compensation wasn't competitive.

Meh, this problem is super, super common. I have many random electric devices that charge using USB-C that don't have the pulldown on CC.

Maybe I should get/make a shim for this.. a USB-C female-to-male thing that just passes through everything but has a pulldown on CC.

You can't really have branches, commits and merges _while offline_ without a distributed repository.

Let me add to that: history and blame too.

You can render JSX at build-time. So it's just a templating language, as the parent comment said.

I don't see why you are so surprised by code that indexes using SIGxxx. The signal numbers are well-defined and known to be mostly consecutive and start from 1.