Meetup summary

2026-05-29 - The Palinax SRS scheduler

If you haven’t read them already, the resources from last time.

Additionally, try to read my SRS scheduler manifesto. This is still a work in progress and I hope to get feedback (and help) from you all while refining and implementing it! Apologies in advance—I’ve been tacking onto and editing it over 4 weeks and there’s likely duplicate text, forward references that no longer exist, and sketchy math (actually definitely sketchy math; I learned much of the random walk stuff while trying to pin down aggregate load under failure). The appendix is mostly implementation notes for myself and can be skipped.

Agenda:

  • Discuss the most salient problems with existing SRS schedulers (with a focus on Anki and SuperMemo):
    • Schedulers are highly overparameterized. With many notes and only a few reviews over a lifetime (by design!) you don’t have nearly enough signal to form a robust per-card memory model.
    • “Ease hell” in Anki/SM. What this is and why it’s a problem.
    • Not easily portable (despite some systems being open source).
  • Design goals for a new scheduler system.
    • Addressing both overparameterization and ease hell at once.
    • Making it easier to model and understand cumulative review load over time.
    • Minimize knobs (i.e., footguns) available to the user.
  • Introduce my current draft design (Palinax)
  • Drill into deployment and implementation intent: distribute as an Obsidian1 plugin and define notes within the main Markdown content of your corpus. Review your cards within Obsidian (in a custom view) and use and edit the SRS and PKG bits of the system orthogonally.

Footnotes

  1. We won’t drill into the specifics (or even really the motivations) of Obsidian today. I’ve only recently started using it with the intent of unifying my current framework of SRS-as-implicit-PKG and personal wiki. I’m still refining the flow and haven’t yet implemented the SRS half, so I expect to have more to say on this later. ↩

tags: