• 1 Post
  • 175 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle




  • Hilarious to have to look this low for it, but who want to stand up and declare themselves mainstream.

    Polished, reliable, and solid, and snaps are not a big deal or an insidious evil, and neither is Canonical. They make missteps for sure. But with containers etc stability is more important than immediate updates and it’s excellent about kernel updates for new hardware. It’s slick Debian, and if the fuckery ever gets real switching to Debian is easy.


  • I’m still on i3 as it’s been convenient, but this:

    this has all become very specialized over the past decade

    resonates. I keep incrementally adding personal tweaks and hotkeys to my setup, and I have all my dotfiles in a repo so it’s persistent across installations.

    One example was I made my headphone button pause/play videos with i3’s config:

    bindsym XF86AudioPlay exec playerctl play-pause
    

    But then I adopted a script to toggle mic mute on work Zoom meetings, so I combined it with the above - if I’m in a meeting it toggles mute, otherwise it play-pauses any current video. The script, for now:

    #!/bin/bash
    #
    # Handler script for hitting mute on the headphone.
    #
    
    CURRENT_WINDOW=$(xdotool getwindowfocus)
    
    # convoluted command to find the intersection of two searches
    ZOOM_WINDOW=$(comm -12 \
      <(xdotool search --name  'Meeting' | sort) \
      <(xdotool search --class 'zoom'    | sort))
    
    if [[ -n "$ZOOM_WINDOW" ]]; then
        # if zoom is active, toggle mic mute
        xdotool windowactivate --sync ${ZOOM_WINDOW}
        xdotool key --clearmodifiers "alt+a"
        xdotool windowactivate --sync ${CURRENT_WINDOW}
    else
        # otherwise do play/pause
        playerctl play-pause # will fail if no player found
    fi
    

    and of course I altered the i3 config to launch that script rather than playerctl directly.

    [EDIT: Updated script as Zoom updated its window identities]










  • I naively thought it I may as well take a job using Go, as learning a new language is broadening, and some people like it, so lets find out first hand… I knew it was a questionable choice, looking at how Go adoption tailed off a while ago.

    Turns out I hate Go. Sure it’s better than C but that’s a very low bar, and C was never a good alternative choice for the use cases I’m encountering. I’m probably suffering from a codebase of bad Go, but holy shit it’s painful. So much silent propagation of errors up the stack so you never know where the origin of the error was. So very much boilerplate to expand simple activities into long unreadable functions. Various Go problems I’ve hit can be ameliorated if you “don’t do it like that”, but in the real world people “do it like that” all the time.

    I’m really starting to feel like there are a lot of people in the company I’ve joined who like to keep their world obtuse and convoluted for job security.