When I become more active, I also become more hungry due to the extra energy consumption. The net effect is little weight loss and more often than not weight gain. While being physically active is beneficial to health in many ways, it does little for losing or maintaining weight, at least for me.
Exercise also stimulates digestion and triggers a hunger response in many people. This is why exercise without diet often fails to result in weight loss.
Exercise typically doesn’t cause people to eat because they are confused about estimating caloric expenditure, it causes them to eat by inducing hunger.
Even people who track their calories perfectly often eat when hungry because it is the most basic of human instincts and our brains and bodies are wired to respond accordingly.
Higher physical activity does not always boost hunger, it can have hunger suppressing effect too.
>Even people who track their calories perfectly often eat when hungry because it is the most basic of human instincts and our brains and bodies are wired to respond accordingly.
Many people can track calories, hardly any of them are tracking calorie burn and no the ones from your watches or displayed on cardio devices aren't correct.
Many times the eating more issue you are seeing is because average guy may estimate that 1 lifting session burns 800-1000kcal. How do i know? i've asked random people in gym this question.
Obesity also doesn’t affect everyone. But within that group, we’re typically talking about the people who do tend to have more eating triggers than people who are not obese.
It is hard to accurately calculate the calories burned in a lifting session but the ability to count calories has little to do with the causes of obesity. Even if a person could count them perfectly that doesn’t mean they are capable of manipulating the numbers to meet their goals.
I've swinged between Go and Rust for my personal projects multiple times. For work, it is decided by the management so not my problem.
The biggest gripe I have with Go is the lack of *any* compile time check for mutex. Even C++ has extensions like ABSL_GUARDED_BY. For a language so proud on concurrency, it is strange not to have any guardrails.
Channels are not for everything. Plenty of mutex cases cannot be rewritten as channels, or will be very unwieldy so. In fact, every large Go project I have seen uses mutex here or there.
Theoretically you can use channels to simulate a mutex, but I agree with you there are use cases where a mutex makes more sense. They are even used in the standard library, for instance to implement sync.Once.
But generally I would agree that if you need to code parallel execution, channels are a good way to do it, because you can avoid race conditions if you share data only over channels. The biggest problem is that a lot of people don't understand, that channels with a buffer larger than 1 are a sign of problems in the architecture.
There is a type of parallel programming with workers for specific functions, that always leads to performance issues. The problem is you need to right-guess the distribution of work, when you have to define the amount of workers for a specific function. At least one go routine for one request is a much better approach than function-specific workers.
You are assuming that LPE only applies to the user that holds all the sensitive stuff. But it also applies to users created specifically for isolation. Without LPE they would not have access to anything important even if they were compromised.
It doesn't matter which "user" this goes through. If an attacker can get hold of a users control to the point where they can execute arbitrary scripts, you have already lost.
If the goal is just preventing full root privileges, a CapabilityBoundingSet in a systemd unit will do.
However copy fail can be used in many other ways not contained by containers or the above settings. For example it can modify the /etc/ssl/certs to prepare for MitM attacks. If you have multiple containers based on the same image then one compromised CA set affects another.
I could be wrong, but I’m not sure those settings are enough to mitigate Copy Fail.
If your distro offers a patched kernel, it’s best to upgrade to that one and reboot.
You can also disable the vulnerable module (how to do it depends on what distro you’re using). But if you stay on an old unpatched kernel you might be exposed to other vulnerabilites.
You are misinterpreting my goal here. I have patched my kernel against copy fail but I am thinking of ways to harden my setup against future CVEs in the kernel.
So the question is, before I learned about copy fail, what could I have done that would have limited the possible damage this vulnerability could do to me? CapabilityBoundingSet is one answer and rootless podman as mentioned in this article is another. They don’t prevent all but at least `su` is useless.
If so, I would look into applying a decent seccomp profile.
Other hardening solutions could be to run the workloads inside of a VM such as Firecracker, or gVisor. But that might be more work to implement compared to seccomp.
reply