In tough job markets, submitting 100 résumés before getting hired is not uncommon. Of possible interest is my Creating Catchy Cover Letters blog post, which uses my Markdown editor, KeenWrite (https://keenwrite.com), to create PDF files styled to match a company's branding:

https://keenwrite.com/blog/2025/10/15/creating-catchy-cover-...

A handful of prospective managers told me that my cover letter stood out among hundreds of applicants.

Here's the full shell script I used to build cover letters (you'll need to point "theme dir" to the directory where the cover letter theme---aspiros---is found). With this script, creating a cover letter went from about 20 minutes down to 5. If you have any troubles getting it to work, contact me via https://whitemagicsoftware.com/.

    #!/usr/bin/env bash

    # This script builds a cover letter based on a company's branding. The
    # parameters include:
    #
    # $1 -- The company name as a directory, containing colours and logo.
    # $2 -- The company name (normal case).
    # $3 -- The company role (job title).
    # $4 -- The relative path to the cover letter to typeset.
    #
    # Example:
    #
    # ./build.sh corp Corporation 'Job Title' template/cover-letter.md

    readonly SCRIPT_SRC="$(dirname "${BASH_SOURCE[${#BASH_SOURCE[@]} - 1]}")"
    readonly SCRIPT_DIR="$(cd "${SCRIPT_SRC}" >/dev/null 2>&1 && pwd)"

    readonly COMPANY_DIR="${1:-template}"
    readonly COMPANY_NAME="${2:-Template}"
    readonly COMPANY_ROLE="${3:-Job Title}"
    readonly PATH_COVER_LETTER="${4:-climate/cover-letter.md}"
    readonly EMPLOYEE_NAME="${5:-Your Name}"
    readonly EMPLOYEE_ROLE="${6:-Your Role}"

    read -r COLOUR_FG COLOUR_BG COLOUR_AC < "$COMPANY_DIR/colours.txt"
    readonly COLOUR_FG COLOUR_BG COLOUR_AC

    magick \
      signature-black.png \
      -alpha extract \
      -background "#${COLOUR_AC}" \
      -alpha shape \
      -define png:color-type=6 \
      signature.png

    rm -f ${HOME}/.local/share/keenwrite/logo_svg_*.pdf

    keenwrite.bin \
      -i "${PATH_COVER_LETTER}" \
      -o cover-letter.pdf \
      --set=employer.company.name="${COMPANY_NAME}" \
      --set=employer.position.role="${COMPANY_ROLE}" \
      --set=employee.name="${EMPLOYEE_NAME}" \
      --set=employee.role="${EMPLOYEE_ROLE}" \
      --set=employee.contact.phone="555-1212" \
      --set=employee.contact.email="email@hostname" \
      --set=employee.portfolio.url="gitlab.com/YourName" \
      --set=employee.address.line.1="address 1" \
      --set=employee.address.line.2="city, province" \
      --set=employee.address.line.3="postal code" \
      --metadata="foreground=${COLOUR_FG}" \
      --metadata="background=${COLOUR_BG}" \
      --metadata="accent=${COLOUR_AC}" \
      --image-dir="${SCRIPT_DIR}/${COMPANY_DIR}" \
      --theme-dir="${HOME}/dev/java/keenwrite/themes/aspiros"

    exiftool \
      -overwrite_original_in_place \
      -Title="${EMPLOYEE_NAME}" \
      -Author="${EMPLOYEE_NAME}" \
      cover-letter.pdf

This saved me about 19 hours of work; hopefully it will save you time, as well. See also: https://xkcd.com/1205/

I made a tool to track ldap like that [0]. LDAP is a treasure chest of info and great for stalking. for some reason i find it fascinating to see people leaving, and if possible, see how long they worked there for. seeing friends get fired via LDAP before they even knew about it was certainly interesting, too.

I noted in the readme..

    Know what's going on in your LDAP directory on-demand with Slack webhook integration.
    See new hires, leavers, and promotions as they appear in LDAP.
    Monitor when and what HR is doing.
    Detect unauthorized changes in LDAP.
    Monitor for accidentally leaked data.
    Detect when users are logging in and out of LDAP.

There's also LDAPmonitor[1] which is designed for Microsoft and Active Directory which does effectively the same thing.

[0]https://github.com/MegaManSec/LDAP-Monitoring-Watchdog

[1]https://github.com/p0dalirius/LDAPmonitor

What I really want to see is a music programming language that does not require elementary knowledge of trig. In fact, I don't want it to use any numbers at all.

They all do: Faust, Impromptu, ChuCK, csound, SuperCollider, etc., etc. I suppose that by itself should convince me that there's no other way (there are things like Orca, but I'm thinking of things that look more like conventional programming languages).

I seldom think about numbers when I'm programming a synthesizer -- I just turn this knob more this way or this slider down a bit. Why can't a music programming language be more . . . gestural? Not sure what the right word is. I want the benefits of a textual programming language, but I don't really want to have to start thinking about sound waves in terms of literal numeric frequencies, particular since I really don't do that while doing sound design.

I don't meant to pick on your project in particular; it looks really cool. But since you're writing one of these, perhaps you can answer my question. Why do these languages ask synth programmers to think in terms of precise numbers when programming an "actual" synth isn't really like that at all?

A lot of Linux based command line whois clients still use "whois-servers.net" to look up up the appropriate whois server for a TLD, which is long dead (it still responds but is no longer maintained).

Many years ago I built a replacement whoisservers.org, and tried contacting a few maintainers, but nobody seemed to really care.

If you want to make use of it, you can run "whois -h com.whoisservers.org exmaple.com" (or substitute -h with the appropriate flag for your client to specify a server)

> Genuine question: does hashing with algorithm B an existing hash computed with algorithm A solve anything at all ?

Absolutely. It solves by far the #1 threat against password hashes when they get leaked.

Algorithm A here is SHA-1, which is very fast to hash, which makes it completely terrible for password hashing -- when an attacker gets their hands on the hashes and salts, with a halfway decent GPU they can dictionary attack and recover even very long passwords in just a few hours, and then merrily use the same password get into the email account, because to a first approximation everyone is terrible about password re-use.

Algorithm B here is BCrypt, which is very very insanely slow to hash, so the same attacker would need years/decades to recover the passwords from the hashes.

HashAlgorithmB(HashAlgorithmA(input)) is dominated by Algorithm B's runtime, so it is equally very very insanely slow to dictionary attack the hashes.

> I mean, A’s hash collision issues will just be applicable as well into B’s space, right?

Sure. But the threat here isn't collision generation at all -- that's more of a PKI infrastructure concern.

Nobody is worried that the guys who have these SHA-1 hashes are going to sit around generating collisions -- that would be slow and stupid, the collision would only apply to other SHA-1-using websites that use the same salt. For this reason, nobody cares about password collisions for leaked password hashes.

They're just going to throw dictionaries + listed salts into a GPU and generate SHA-1s at a rate upwards of 68 billion per second on a cheap GeForce 1080, and quickly reverse the entire table. That gets them into every site the same password was used for, no matter the hash function.

This is how all of those leaked password DBs get generated, and this is why people say “don’t use SHA-1, use BCrypt for passwords” in the first place. It’s all about speed being bad, not collisions.

This is the threat BCrypting SHA-1s guards against.

> And I would go for rehashing at next login, and, after a while, identify and disable (no login possible) the legacy accounts with their deprecated hash, forcing users to change password at their next login (if it comes one day, that is).

You're still keeping easily-reversible hashes around for some period of time that cost users control of passwords if-and-when they leak before you wipe them. You can do better with zero downside. Get rid of them all immediately.