HN user

ylyn

602 karma
Posts0
Comments166
View on HN
No posts found.

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...

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.

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.

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.

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.

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.