Tinderbox Meetup, Sat. 26Apr25 (Video): Collaboration (social, workflow, technical, social) and Dynamic Glossaries and Indexing
| Level | Intermediate |
| Published Date | 4/26/25 |
| Type | Meetup |
| Tags | Becker’s 5Cs of Knowledge Management, Collaboration, Glossary, Humility, Index, Memory Safe Programming, Modern Computer Literacy, Standards, Tinderbox ROI, 5CKM, 5Cs of Knowledge Management, Eastgate, Identity Praxis, Inc., Mark Berstein, Michael Becker, Tinderbox |
| Video Length | 01:43:50 |
| Video URL | https://youtu.be/r1a9gODdncQ |
| Chat File | TBX Meetup 26APR25_Chat.txt (5.8 KB) |
| TBX Version | 10 |
| Host | Michael Becker |
In this Tinderbox Meetup, we engaged in a conversation around collaboration—what it is, who we do it with (our future self and others), and how do we do it (in general and within Tinderbox, etc). The discussion brought up much food for thought on the state of technology and social systems, not to mention how and why we use Tinderbox (its ROI). We also discussed the need for “memory safe programming”—what is it, and why does it matter? Near the end, Becker (@satikusala) presented an early look into his 5Cs TBX Publishing Module “Glossaries, Indexing, and Media Numbering with Tinderbox.” He demonstrated how one can work on multiple projects (e.g., articles and books) in Tinderbox, have a common repository of curated notes (e.g., resources, atomic notes, zettles), and then, using agents, present dynamic glossaries and indexes formatted as lists, tables, or alphabetized.
Resources
- Tana
- Mellel
- Nisus
- OpenDocument Text (ODT) Format
- LibreOffice
- nroff
- Rust
- Swift
- GNU Project
- Memory-safe coding, means writing code that prevents common memory errors like buffer overflows, dangling pointers, use-after-free bugs, and null pointer dereferences. In memory-safe systems, the language or runtime automatically ensures that memory is accessed safely, either by managing memory for the programmer, checking bounds at runtime, or enforcing strict rules at compile time. This leads to fewer crashes, fewer security vulnerabilities, and safer concurrent programs. Languages that are considered memory-safe (either fully or mostly) include Rust, Swift, Java, Python, C#, Kotlin, Go, Ruby, Haskell, and JavaScript.
- “The enormous pain of rewriting vast amounts of code (primarily written in C) into memory safe languages (like Rust) is still not as painful as continuing to deal with the consequences of inherently insecure code libraries that underlie the technical structure of our modern world.”
- It Is Time to Standardize Principles and Practices for Software Memory Safety
- It Is Time to Standardize Principles and Practices for Software Memory Safety (PDF)
- Inside Risks It Is Time to Standardize Principles and Practices for Software Memory Safety
- What is memory safety and why does it matter?
- 5CS TBX Publishing With Pandoc And To PDF: Libraries And Templates