When reflexes acquired in your job are invading your daily life.

-When i was an intern in a retail, i had to fight against the urge to store the shelves during my own shopping sessions.

      • Domi@lemmy.secnd.me
        14·
        1 day ago

        This is Lemmy. “Linux” doesn’t cut it here.

        We want to know exactly which distro, which tweaks, what hardware and how you broke it this time.

        • runiq@feddit.org
          10·
          19 hours ago

          Right, if you insist: Fedora Kinoite, Thinkpad X1 Carbon 4th Gen, some sysctl tweaks for low-latency audio.

          Yesterday I realized my password database (which I sync between computers/phones via Syncthing) was broken, because I had failed to regularly manage upgrades for my Syncthing container, and Syncthing had recently released a v2.0. My monitoring was insufficient and so I hadn’t noticed the Syncthing container on my laptop hadn’t been running since ~September. When I got Syncthing running again, I had already made changes to my password database on all three synced devices, so Syncthing generated a number of password.sync-conflict-<date>-<time>.kdbx files. Normally that’s not a big deal because my password manager has the ability to merge two password databases together, but this time around 400 entries showed issues when merging.

          So, armed with a big ol’ mug of mulled wine, I bit the bullet and started checking entries manually. After a trip to the KeePassXC bug tracker and the merger code, it turned out that the entries only differred in a few seconds in the _LAST_MODIFIED attribute, which can happen when my laptop is a) on battery, which causes the system clock to go a little off when the voltage drops and b) disconnected from the internet so the NTP client doesn’t have a change to sync time. Both happened a lot during the months the time my password database had failed to sync – we had gone to Paris (lovely place, can wholly recommend a visit) and my GF’s daughter is in the habit of watching shows on the computer without plugging in the power.

          So I shrugged, merged anyway, ignored the error messages, deleted the sync-conflict files, and called it a day. Maybe the wine played a role in that decision, maybe not.

          Thank you for coming to my TED‌ talk.

          • statler_waldorf@sopuli.xyzEnglish
            2·
            15 hours ago

            Gotta love the shrug "fuck it, I’m mostly sure nothing will go wrong, and if it does, maybe it won’t matter”. We’ve all done it and most of the time we’re right. But when we’re not…oof.

            • runiq@feddit.org
              1·
              19 hours ago

              Sure. The following are the bits that I’m pretty sure are universal. The rest – mostly configuring my audio interface – is IMO fairly specific to my system and can be found in my dotfiles.

              • Limits for Pipewire:
                # /etc/security/limits.d/25-pw-rlimits.conf
@pipewire   - rtprio  95
@pipewire   - nice    -19
@pipewire   - memlock 4194304
              • Add the realtime group and grant it access to /dev/cpu_dma_latency so Ardour can prevent the system from going into idle:
                # /etc/udev/rules.d/40-realtime-privileges.rules
KERNEL=="cpu_dma_latency", GROUP="realtime"
              • Add threadirqs and preempt=full to the kernel commandline
              • Disable VM swap readahead since Kinoite uses ZRAM anyways:
                # /etc/sysctl.d/50-audio.conf
vm.page-cluster = 0
              • Set IO scheduler to None for SSDs and NVMe:
                # /etc/udev/rules.d/60-block-scheduler.rules
ACTION=="add|change", SUBSYSTEM=="block", ATTR{queue/rotational}=="0", KERNEL=="nvme?n?", ATTR{queue/scheduler}="none"
ACTION=="add|change", SUBSYSTEM=="block", ATTR{queue/rotational}=="0", KERNEL=="sd?", ATTR{queue/scheduler}="none"

              I’m not using a preempt kernel or anything like that; I’ve only gotten into audio when Pipewire had already hit the scene and I’ve found it to be good enough with these settings.