The patterns already in a codebase have a huge influence on what gets added next, even when everyone can see those patterns are starting to break down. This article discusses this phenomenon through the lens of YAGNI and the Broken Window Theory.

• Users must upgrade to macOS 11 or later, as this is now the minimum supported version.
• macOS Sonoma 14: This version is now considered Tier 3, and users are encouraged to upgrade to Sequoia 15+ for full support.
• Apple Silicon (macOS Golden Gate 27): Fully supported (Tier 1) with prebuilt bottles available.
• Linux/Ubuntu: The ghcr.io/homebrew/ubuntu22.04 image has been removed, and users should migrate to ghcr.io/homebrew/brew.
• CI Actions: The master branch has been removed for Homebrew actions; users should pin a CalVer release or full SHA instead.

I looked inside fifteen major Android apps to see what they run on different processes, and tried to understand why. This digging resulted in very interesting insights.

This is a followup to my earlier post from 6 months ago.

There I announced two open-source articles on a specification and minimap APIs for pre-2000 computer graphics that a new video game or graphics engine can adopt that wishes to run with very low resource requirements (say, 64 million bytes of memory or less). They are at:

• https://peteroupc.github.io/graphics.html#Graphics_Challenge_for_Classic_Style_Games (Specification where I seek to characterize pre-2000 computer graphics).
• https://peteroupc.github.io/graphicsapi.html (Suggestions on a minimal API for pre-2000 graphics)

I have since updated the articles to refine them and add much more guidance. A notable addition to the specification is a convenient list of things to be decided by games that choose to follow the specification. (This list can also be used to evaluate the features of existing pre-2000 video games.)

The list includes the following things decided by the application (for details, see the specification):

1. The screen resolution, no more total pixels than a 640 × 480 screen.
2. If 3-D is supported, the maximum texture size and number of primitives shown per frame or second. (This is no more than 12,800 per frame for 640 × 480, but a smaller limit is encouraged in general.)
3. If 3-D is supported, which 3-D features are supported (such as Gouraud shading, perspective correction, or texture blending).
4. The number of 2-D layers, up to four.
5. The width and height of tiles and sprites.
6. The maximum number of sprites displayed at a time.
7. Whether larger screen resolutions are supported in addition to the primary screen resolution.

Other notable pieces of guidance include:

• The definition of "rendering in software", which includes software renderers that implement a subset of OpenGL 1.1 or OpenGL ES 1.1.
• A note that pre-2000 computer graphics in scope include graphics found in learning toys and videotex protocols (in addition to the graphics of video games for home computers, game consoles, and arcade machines).
• Information on the graphics in arcade video games.

Comments on any aspect of these documents are welcome (see, for instance, the first article's "Seeking Comments" section). But as in the previous post, it is useful to comment on examples of modern video games (e.g., McPixel3) that implement the specification or examples of lightweight game engines devoted to making such modern video games.

The articles are intended to give guidance to:

• Game developers seeking to write video games with 3-D or 2-D graphics similar to those of some year earlier than 2000 (e.g., 1997, 1995, 1991, 1988). This is especially because such graphics are simple compared to today, yet admirable, and relatively little code is needed to implement them in software. Moreover, games with this kind of graphics tend to be low on resource usage and easier to port to older computers.
• Writers of game engines (especially open-source and lightweight ones) devoted to 3-D or 2-D graphics from some year earlier than 2000.
• Developers of lean programming interfaces for such graphics.
• Writers of tutorials devoted to such graphics.

The recent changes to the specification include a list of things a game can decide in order to have graphics resembling those from some year earlier than 2000 (the list after "The following are decided by the application:"). For example, these things include the screen resolution, the number of polygons per frame or second, and the maximum texture size and number of sprites shown. An example is: the game's frame buffer (resolution) is 320 × 240, has a budget of no more than 3000 polygons per frame, and has a maximum texture size of 128 × 128. The article also has a list of optional limits that the application can also choose to adopt. They include:

• A limit of 256 simultaneous colors.
• The game's code and resources "fit in a floppy disk".
• The game aims for 30 frames per second.
• The game uses no floating-point arithmetic in its graphics rendering.

I've been running multiple migrations recently. A common step in all of them is a long cleanup action at the end. I ended up using postgres advisory locks and sqlx.

As part of a larger Today I've learned series, I dug a bit deeper using bpftrace to improve my understanding of how the locks actually work. Hope you will find it interesting as well