The Future of Computer Memory Architecture

So on Quora there is an author named Franklin Veaux.  He writes answers and comments on a lot of different topics and generally seems to have a good head on his shoulders and knows what he is talking about. One such topic that came up was the future of computer architectures with regard to system memory and offline storage.  Today’s modern computer systems utilize smaller amounts of primary RAM for system storage, which is fast but volatile; and larger amounts of slow but persistent storage via magnetic rotational or solid state drives (i.e. hard drives).

As we make advancements in memory technologies, it is conceivable that we will eventually end up with a memory device that is dense (as in density, not intelligence), fast, robust, and persistent.   When this happens, the differentiation between system RAM and persistent storage may start to blur, or go away entirely.

Continue reading The Future of Computer Memory Architecture

Old School, But New Log Format

So I was thinking about a logging system I implemented almost 15 years ago to replace an existing one that lacked a standard way of presenting context and information.  I drew from how the VAX/VMS DCL interface returned status messages. Some examples:

%DECnet-W-ZEROLEN, length of file i zero -- SYS$SYSROOT:[SYSEXE]NET$CONFIG.DAT

%SMP-I-CPUTRN, CPU #1 has joined the active set.

%STARTUP-E-NOPAGFIL, No page files have been successfully installed.

But the first part was replaced with the app/service name, each line was prefixed with the current date and time: 2024-05-28 02:09:42, and the last token was a facility code.

Looking back, I think I should have followed the DCL format a little more closely, using a format more like: SUBSYSTEM-e-FACILITY, where “e” is a single character severity code (in increasing order of security): Debug, Info, Warning, Error, and Fatal, with the addition of an Always level.  This allows for filtering and configuring the verbosity level of the logging system with the exception that the Always level is always written to the log/console regardless of the configured logging level.  The time format would also be changed slightly to what’s log in UTC make it consistent with standard formats: 2024-05-28T02:09:42Z

This yields a format that can easily be scanned visually or parsed by a tool for offline analysis.