• 0 Posts
  • 68 Comments
Joined 2 years ago
cake
Cake day: November 7th, 2023

help-circle
  • Sorry, but that’s simply not good advice. Nobody is born with perfect parenting skills and is granted all the answers. In fact, many parents are not fit to raise kids at all, others are simply overwhelmed and need help.

    It’s very easy to have a kid, not particularly easy to raise one. The idea that all your decisions are magically correct and sound just because it’s your own kid and that every parent knows best is simply wrong. It’s healthy to doubt yourself and to ask for advice.

    Also, parenting science is not quackery. This is an actively researched area and there are real scientific efforts to better understand child development with respect to biology, psychology and neuroscience. These efforts do lead to a better understanding of how kids can be raised and how certain parental decisions might affect a child.

    Personally, I’m happy each time parents try to inform themselves and seek the advice of others. That doesn’t necessarily mean relying on the answers a bunch of strangers give on social media, but I hope the Fediverse as a whole can do better.

    Right now, I can’t make the claims you did in your post initially.

    You’re not causing permanent damage to a child by letting them sleep in your bed.

    I wouldn’t know that. Intuitively, I do believe that co-sleeping would have a lot of benefits up to a certain age, after the infant stage and dangers of SIDS have passed. However, I could easily imagine that there might be adverse effects after a certain age. Would it be likely to occur after a handful of times? Probably not. Are there any indications on the threshold maybe? Anything to look out for, given the kid might have anything else going on? Maybe. All information I would have on that subject would indeed be anecdotal though, and so in turn pretty useless. Why the dismissal of an honest attempt at getting educated?

    I would indeed argue for getting an overview of what science has to say on the matter and then making an individual, informedndecision based on all the additional context I’d have as a parent that I could never cram into a couple of posts on the internet.

    Having access to scientific publications, I’ll see if I can provide some material later.








  • I don’t know what your previous setup was, but given that running resolved fixes your DNS issues, run:

    ln -sf ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

    This will point programs that use /etc/resolved.conf during DNS resolution to the local DNS server provided by systemd-resolved.

    Then, enable resolved so that it is started when you reboot:

    systemctl enable systemd-resolved.service

    Finally, start the service so that it is available immediately:

    systemctl start systemd-resolved.service

    You will want it run those with the required permissions, e. g. via sudo.







  • An interrupt is an input that can be triggered to interrupt normal execution. It is used for e. g. hardware devices to signal the processor something has happened that requires timely processing, so that real-time behavior can be achieved (for variable definitions of real-time). Interrupts can also be triggered by software, and this explanation is a gross oversimplification, but that information is what is most likely relevant and interesting for your case at this point.

    The commands you posted will sort the interrupts and output the one with the highest count (via head -1), thereby determining the interrupt that gets triggered the most. It will then disable that interrupt via the user-space interface to the ACPI interrupts.

    One of the goals of ACPI is to provide a kind of general hardware abstraction without knowing the particular details about each and every hardware device. This is facilitated by offering (among other things), general purpose interrupts - GPEs. One of these GPEs is being triggered a lot, and the processing of that interrupt is what causes your CPU spikes.

    The changes you made will not persist after a reboot.

    Since this is handled by kworker, you could try and investigate further via the workqueue tools: https://github.com/torvalds/linux/tree/master/tools/workqueue

    In general, Linux will detect if excessive GPEs are generated (look for the term “GPE storm” in your kernel log) and stop handling the interrupts by switching to polling. If that happens, or if the interrupts are manually disabled, the system might not react to certain events in a timely manner. What that means for each particular case depends on what the interrupts are being responsible for - hard to tell without additional details.