Jump to page content



If, from reading these notes, you conclude that I am off my rocker, you won’t be the first, and you may even be right.

No doubt there is a dozen and one reasons why none of this would ever work, but perhaps somewhere deep down there is a tiny fragment that could be used for something.



As with every other facility, logging is centralised and handled by the Log Manager. The application can issue log entries directly by sending messages to the Log Manager. Applications using the legacy event model (see at events) that are run non-interactively will also have all STDERR and STDOUT entries written to the application’s log. Log entry formatting is handled automatically. Each application has its own log file, similar to the macOS approach.

Unlike the Windows event log, there are no general-purpose logs such as “Application” and “System”, as these classifications have proved meaningless. Each system component and application will have its own log. Combinations of logs, such as viewing the logs for all system components, are simply a matter of specifying the appropriate query.

Each log entry contains the time, date, user ID, user session, process ID and log details. Users may retrieve all log entries for their own sessions and for all unprivileged system activity. With administrative privileges, users may also query the log entries for other users and all privileged system logs. The log levels (e.g. information, warning, error, debug) are system-defined. The maximum log level is set within the Log Manager itself; language runtime may choose to not send log levels below that specified for the application, but the Log Manager will discard any entries at too high a level. The log level can be changed with a request to the Log Manager, made either by the application itself or by the user, e.g. from within the Log Viewer application.

The log database is maintained by the Log Manager and can be queried using standard message passing. Comprehensive search and filtering is to be available.

Entry format

Log entries in plain text are supported, if only for the legacy event model and programs that only write to STDERR and STDOUT (utilities ported from Linux and UNIX).

Log entries are likely to have named placeholders, e.g.

{ message: "User $username successfully logged on from computer $computer.", username: "Trogdor", computer: "COMPY386" }

This arrangement allows users to more accurately query for log entries. However, the log storage arrangement is not specifically determined.

Log entries could also save the messages in string tables just like in Windows, to save on log storage. The log message definitions would likely have their own MDFS dimension for ready access.


The Log Manager supports the following events and messages: