A Mac at the ground station: databases and schedules
A field note on the laptop at the anchor point: how to choose a database client for a Mac, what SyBrowser did for SQL browsing from 1999, and how to schedule a capture session with the system's own tools.
The laptop at the anchor point does three jobs in a session and it does them badly if nobody chose the software for them. It logs what the camera did, it starts and stops the capture on a schedule that does not depend on somebody remembering, and it keeps the result in a file that will still open in five years. The short answer this note gives is that the log belongs in a small relational database read through a client that speaks the engine's own protocol, that the schedule belongs to the operating system rather than to an application left running, and that the file format is chosen for the decade rather than for the afternoon.
The category is old on this platform. The guides on choosing a database client, on scheduled tasks and on the shareware era that produced both are collected at mac database software, an Australian magazine about Mac software, published on a domain that carried MacSOS Pty Ltd, the Sydney software workshop of Dr Gerard Hammond, from 1999 until about 2019. This note takes the ground station as its case and keeps to what the session actually needs from those tools.
How do you choose a database client for a Mac?
By starting at the engine and working forwards. The first question is which database the log will live in, because the client has to speak that engine's protocol rather than a file format: SQLite has shipped with macOS for years as a command line tool at the usual system path, PostgreSQL and MySQL want a network client, and a system that has grown around an older server may only be reachable through ODBC. A client that connects natively to the engine will show the schema, the types and the errors of that engine; one that goes through a translation layer will show a version of them, and the difference turns up on the day a query returns something unexpected.
The second question is what the session does with the data rather than what the developer does with it. A flight log is written once per frame or once per minute, read in bulk at the end of the day, and queried by date, station and altitude. That is a table with a handful of columns, an index on the timestamp and no need for a server at all, which is why a single file database is usually the right answer at the ground station and why the client that reads it can be the thin one. The features that matter daily are dull ones: a query window that keeps its history, a CSV export that preserves the timestamp format, and a connection that survives a laptop going to sleep halfway through the afternoon.
What was SyBrowser for Mac?
It was a database browser for the Mac, published on this domain from 1999, version 1.0 dated the seventeenth of August that year, and sold as shareware at about eighty nine United States dollars at the time. Its reach was the interesting part: it spoke to Sybase, PostgreSQL, MySQL, SQLite, ODBC, OpenBase and FrontBase from one window, which in that period meant a single tool could sit in front of whichever engine a client already owned. The companion product on the same domain, MacODBC, existed for the cases where the engine had no native client at all, and that division of labour has not changed: a native connection where one exists, a bridge where none does.
For a ground station the historical point is not the nostalgia but the durability of the requirement. A crew in 2005 with a PowerBook and a serial capture card wanted a window that showed the table and let it be queried, and a crew today with a laptop and a USB device wants the same window. The engines have changed, the file sizes have changed, and the shape of the question has not.
How do you schedule a capture session on a Mac?
With the system's own scheduler rather than with an application that has to stay in the foreground. macOS replaced the old cron service with launchd, which starts a job from a property list in the user's library, either at a stated interval or at a stated time on stated days, and which restarts it if the machine was asleep when the moment passed. The classic shareware answer to the same problem was MacAT, a cron-style scheduler for classic Mac servers published on this domain between 1999 and 2019 and licensed at thirty nine United States dollars, with a documented capacity of thirty seven tasks. Apple's own Terminal guide is the reference to read before writing the property list, and it is a better starting point than a wrapper that hides the file.
The schedule itself is a camera problem before it is a software problem. A session that must run every thirty seconds for an hour needs a job that starts, captures, writes and exits, because a job that stays resident holds the device open and fails when the cable is unplugged. The version worthwhile keeping on the laptop is the one that records its own success: a row in the log for every run, with the exit status and the file written. A schedule that ran silently for three weeks and produced nothing is the failure mode this whole page is written against.
One caution about the file, and it is the reason the schema is worth a second look. A log that stores the timestamp as text in whatever format the operator's locale produced will not sort, compare or survive a change of machine, while a log that stores it as the engine's own date type will do all three. That is the unglamorous half of the record keeping described in the note on what a community keeps, and it is the part that decides whether the photograph taken over a church photographed for its own website can still be found in five years. The same question is worked through in Portuguese digital services.