Excellent article. Cimbar codes can encode glyphs yielding about 10 kB/qrcode, stackable. Ref: https://github.com/sz3/cimbar

I'm using this in my .zshrc:

  function cd { builtin cd "$@" && [ -d .git ] && git pull || true; exa -all --group-directories-first; }

  alias acp='git add -u &&-c "git log --color --pretty=format:\"%s\" --abbrev-commit -- |>/tmp/git_log_sk && git commit --gpg-sign --edit -F /tmp/git_log_sk && rm /tmp/git_log_sk" && git push -u
 origin HEAD'

The cd automatically pulls if it's a git repo. The acp is shorthand for "add+commit+push" with sk as a fuzzy finder for a commit message editing (vim integrations).

Could that perhaps work better in .gitconfig than a shell function?

I know for me, I could not use "acp" as the alias because it would conflict with the oh-my-zsh aws plugin to load profile credentials.

In TDD, u-tests are called "spec". Pretty much sums it up.

So again, any inputs outside of those exemplified in unit tests are unspecified behaviour? How would this work for mathematical operators for example?

A part of this lives in the spec name, and a part in the assumption that the Devs are not psychos. As in, if you test that sum(a,b) returns a sum of your numbers, the name/description of the test says so. And the second part means that it should hold for all numbers and the exceptions would be tested explicitly - nobody added "if a=5 & b=3 return 'foobar'" to it.

Induction is a valid form of inference.

spec and documentation are things different though?

In TDD spec is converted to behaviours that can be ran as automated tests so if the logic of the code changes, it breaks the spec and in turn the tests

Whereas documentation can (inevitably) go stale with no feedback or build failures

I self-host paper-hn in a k3s cluster. Homepage here: https://github.com/wolfgang42/paper-hn

If you're fine with plain http on your local network, you can use https://github.com/mihaigalos/aim

Spoiler: I wrote it.

I'm using a Yubikey for both sudo and ssh 2FA:

# /etc/pam.d/sudo

    auth      optional  pam_faildelay.so delay=5000000
    auth      [success=1 default=ignore] pam_yubico.so authfile=/home/user/auth_file id=16 
    session   required  pam_env.so readenv=1 user_readenv=0
    session   required  pam_env.so readenv=1 envfile=/etc/default/locale user_readenv=0
    @include  common-auth
    @include  common-account
    @include  common-session-noninteractive

# /etc/pam.d/sshd

    auth     optional   pam_faildelay.so delay=5000000
    auth     requisite  pam_yubico.so authfile=/home/user/auth_file id=16 debug
    account  include    base-account
    auth     required   pam_env.so
    auth     required   pam_nologin.so successok

Sidenote: This requires internet access. I'm considering selfhosting a Yubikey auth server and disabling ssh on it.

Why does it require internet access? If you use a private key stored on your yubikey and a public key stored in your ssh configs, that shouldn't require internet access.

Because there is a Yubico server involved in the auth process. No internet access means you cannot authenticate.

Why is there a Yubico server involved? Why can't it use public and private keys? What does the Yubico server do?

Hopefully this isn't using Yubico OTP, which is phishable:

https://developers.yubico.com/OTP/

Two offline alternatives come immediately to mind.

1. Reconfigure pam_yubico to use local challenge-response auth instead of YubiCloud. The ykpamcfg(1) man page[1] explains how to do so.

2. Use pam_u2f to enable FIDO2/U2F auth. See, e.g.,

https://support.yubico.com/hc/en-us/articles/360016649099-Ub...

https://docs.fedoraproject.org/en-US/quick-docs/using-yubike...

Though on Fedora (and RHEL), I personally prefer authselect to hand-editing /etc/pam.d; in particular, authselect's "sssd" default profile includes optional U2F support:

    $ authselect show sssd | fgrep -C 2 u2f | sed -ne '/u2f/,$p'
    with-pam-u2f::
        Enable authentication via u2f dongle through *pam_u2f*.
    
    with-pam-u2f-2fa::
        Enable 2nd factor authentication via u2f dongle through *pam_u2f*.
    
    without-pam-u2f-nouserok::
        Module argument nouserok is omitted if also with-pam-u2f-2fa is used.
        *WARNING*: Omitting nouserok argument means that users without pam-u2f
        authentication configured will not be able to log in *INCLUDING* root.
        Make sure you are able to log in before losing root privileges.

[1] https://raw.githubusercontent.com/Yubico/yubico-pam/5719a2f8...

This is awesome, thanks. But would still like to keep the auth server separate to minimize the attack surface something like the now deprecated [1].

[1] https://github.com/scumjr/yubikeyedup

Amazing. Congrats.

I've used Swig to inherit from base classes in Java to implementations in C++. Swig generated the JNI and C++ bindings.

Fun times.

SWIG directors are awesome. It's so powerful having some functions implemented in C++ and some in Java in the same class, and able to call each other willy-nilly.

Swig is kind of clunky. But it is so much better than writing JNI yourself. JNI is gouge-your-eyeballs-out awful; SWIG is at least tolerable, and it works.

+1 or maybe +200. JNI OMG, now I will have nightmares tonight.

Yep! SWIG with Python may be a poor use-case, but it worked really well for me with Java/JNI. This was 10 years ago though!

At this point, I wouldn't be surprised if it comes to light that such research is funded by hedge funds owning the commercial real estate you "absolutely have to have for the poor young professionals."