Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from bunnie's blog
The Ware for August 2026 is the “IC unit” from a Lafayette 150-in-1 “IC Electronic Project Kit”, part number 99-35107. Above is a contextual photo of how the unit looked mounted in the kit. And above are a couple examples of projects you can build with the “IC” as part of the kit. Answering Hales’ […]
The structure in question for last month’s ware are a pair of NPN transistors that form the core of a bandgap voltage reference circuit. As its name implies, a bandgap voltage reference generates a near-constant voltage for use inside chips. The voltage is intended to be fairly constant over process variations, temperature variations, and power […]
The Ware for June 2026 is an SGI RM6-64 raster manager, from a KONA/InfiniteReality graphics system. Congrats to Christian for naming it! email me for your prize. This gem of a board was gifted to me by someone at SGI back when I worked there in…I want to say 1998? I even still have the […]
The Ware for May 2026 is, in FETguy’s words: “one of many large pc boards of a Rodgers Instrument Co church organ. The core memory was used to store and recall settings of the organ’s “stops”. There were 5 core memory boards in this instrument which differ in how many words were implemented. I photographed […]
Seems like I overestimated people’s interest in looking at silicon images! Congrats to k8 for attempting the challenge, I appreciate the participation. email me for your prize! Recall that the list of possible memory dimensions is limited to a list of 28 possible types of memories. Given that, here’s the mapping of macros to memory […]
More in programming
In this video, we look at why fork() needs copy-on-write, how it works inside the kernel, and a memory usage problem that Instagram encountered with Python.
Comments require commitment, but they’re worth it.
In his Rails World keynote, David Heinemeier Hansson (DHH) declared the end for writing code by hand for professional work – at 37signals at least. Is this change now unstoppable?
My last official contribution to GitHub was something I’ve wanted for a long time: Writing the code to display an ACCESSIBILITY.md file’s contents on the repository landing page. This content lives in the same tab component that the README, License, Code of Conduct, Security, and important information is surfaced. For example, I’m using an ACESSIBILITY.md file located in ./github to communicate my accessibility statement on my a11y-webring.club repository. Here’s an image of it in action: The file only appears if it is supplied, so it is not a required part of creating or maintaining a repository. However, it is my hope that the act of providing one becomes more commonplace the same way providing those other special kinds of files are. Another broader hope I have is that this promotion of content helps to normalize accessibility as a consideration and practice in some small way—something that helps to send a signal of a mature software project. I’m excited to see how people use this new addition to the platform. I would also like to extend a huge thank you to Jan Maarten and Maria Lamardo for their help getting this effort across the finish line.
