Programming Tutorials

  If you recently unboxed a Raspberry Pi 5, flashed Raspberry Pi OS Bookworm, and attempted to run your trusty Python scripts, you likely hit a wall. Scripts that have run reliably on the Pi 3 and 4 for years are suddenly throwing   RuntimeError: No access to /dev/mem ,   ModuleNotFoundError , or worse—running silently without actually toggling any pins. The industry-standard library  RPi.GPIO  is dead on the Raspberry Pi 5. Here is the architectural reason why, and the code-complete paths to get you back up and running. The Root Cause: The RP1 Southbridge To understand why your code broke, you have to look at the silicon. On Raspberry Pi models 1 through 4, the GPIO pins were controlled directly by the main Broadcom System-on-Chip (SoC). Libraries like  RPi.GPIO  worked by memory-mapping ( mmap ) specific physical addresses on the SoC to toggle bits directly. This was fast, but it was a "dirty" hack that bypassed the Linux kernel's subsystems. The Ras...

  You have likely encountered   SQLITE_BUSY   (or   OperationalError: database is locked ) just as your application scales beyond a single user. It is the most common reason developers abandon SQLite for Postgres or MySQL prematurely. The error occurs not because SQLite is incapable of concurrency, but because its default configuration prioritizes safety and backward compatibility over concurrent performance. By understanding SQLite's locking mechanism and adjusting two specific settings—Journal Mode and Busy Timeout—you can handle high-throughput concurrent workloads in Node.js and Python without migration. The Root Cause: Rollback Journals and Exclusive Locking To understand the fix, you must understand the locking model. By default, SQLite uses a  Rollback Journal  (specifically  DELETE  mode). When a connection needs to write to the database: It acquires a  SHARED  lock to read data. It acquires a  RESERVED  lock to signal ...