On mimicry

Although ARES often leans on established operating systems for concepts and terminology, resist the urge to take this too far. Since LSL scripts will never have the resources necessary to faithfully mimic UNIX or DOS programs in their behavior, imitating them by appropriating names for inferior programs will ultimately annoy the few geeks who are able to understand the intended reference. Only borrow names for the few clones that actually work like clones—for example, the old Spring Utilities for Companion included a crontab file that accepted the same input format as the venerable Nixie cron daemon.

However, the ARES alias @ls (which maps to fs match) is undocumented because it doesn't support any switches and would likely frustrate real power users!

On command-line formatting

When designing CLI programs, use reserved keywords as much as possible instead of switches; the effect should be like SQL, BASIC, or COBOL, where the resulting command is a sort of half-readable terse English sentence rather than a morass of symbols. power system off (ARES) is much easier to understand than shutdown -h -t 0 (POSIX, and also Companion(!)).

Doing it this way helps ease novices into the command-line interface, and it's also typically easier to parse strings on a word-by-word basis without having to worry about dissecting a bunch of switches glued together in a single token, which LSL struggles with, as it has neither character literals or square-bracket indexing for accessing characters in strings; nearly all NS software simply uses split(m, " ") (equivalent to llParseString2List(m, [" "], []) in pure LSL.)

It is worthwhile to remember that switches ultimately owe their heritage to the teletype (electric typewriter) keyboards that were used as terminals on mainframes in the 1960s, which were much stiffer than any mechanical keyboards we use today. Memory and keystrokes were both at a greater premium than they are for the average SL script/user interaction.

That being said, it is OK to use switches if confusion with freeform text input is likely; see in particular the ARES ai program, which uses single switches like -m and -k for configuration. Additionally, several programs, including ai, use - to indicate that they should read from the input stream instead of expecting a filename or text parameter.

On naming

When in doubt, give things boring, generic names, especially if it will assist in keeping commands readable. Although Companion's commands mostly had sensible and direct monikers, many scripts in Companion had esoteric, poetic names that greatly hindered troubleshooting and seldom did more than suggested the actual function. Thus, submission is now security, and arabesque is now exec. (These are not exact analogies, but you get the idea.) Associations that may be obvious to you might not be so transparent to your users—does sentinel zap viruses or unauthorized users? (Neither; it was named that because it triggers the MESH-2100 shield's barrier deployment.)

On timers

The more often a script executes the more of a drain it puts on a region's resources. We ideally want to avoid this.

Mono scripts typically receive a timeslice of something like 1 µs per event they need to handle. The simulator runs at 45 frames per second, which is 22222.2 µs per frame. This sounds like a lot of room, but does not actually mean that the simulator can handle a million events per second—most regions actually top out at around 4000 or 5000 eps, as the overwhelming majority of the simulator's time is spent on other tasks like physics and networking. (It seems that the SL simulator code is still painfully close to being single-threaded.)

Thus it is possible to tank a sim with fewer than a hundred maximum-resolution timers (that is, llSetTimerEvent(1.0/45.0)). If those timers are in a device pinging ARES for status updates, you have three events—the timer, the ping handler, and the pong handler (provided ARES doesn't have internal dispatches, which can add 6 or more events as the kernel must start and stop most programs to handle these signals.)

With this in mind, it should be apparent that even one-second timers in apps and devices can have serious impacts on a region's performance if multiple avatars have them equipped. For information display by devices, ARES will spontaneously send information whenever a significant change occurs (often if the value has drifted by more than 1% from the previous-reported value) for messages related to power, integrity, and (with Sexuality installed) arousal.

The fastest recurring timers in the ARES source code are:

• nav (0.5 sec): used for pathfinding and checking that the target hasn't moved; makes no external calls
• effector daemon (5 sec): used to check for RLVa (disables once found)
• interface daemon (0.125 sec): used to refresh HUD elements while in mouselook (slows to 2 sec following inactivity)
• repair daemon (2 sec): only while repairing; otherwise slows to 10 sec
• sexuality daemon (1 sec): only while aroused
• status daemon (0.25 sec): main power/heat calculation, usually only runs at 1 sec resolution
• ctrl hardware firmware (0.25 sec): only when !broken
• proc (5 sec): only during kernel reset process

All other recurring timers are at least 10 sec long.

Non-recurring timers: There are several programs that use like JavaScript-style timeouts to implement deadline schedules; they consult a list of pending tasks and process them if the target time has been reached, then set the next the timer event to the next task. There are also a few cases (stack escapes) where a timer is activated with a very short window simply to ensure a task is completed without having been called from another function; otherwise e.g. the script handler in exec would run out of memory as it attempted unoptimized tail recursion.

Many timers aren't implemented in the programs at all, but rather handled by the kernel as SIGNAL_TIMER events, allowing the programs themselves to sleep. This is an excellent API for timeouts, as individual processes may create as many as they wish, referenced by tags. However they only have a one-second resolution and will not perform well if triggered every single second, as waking a script requires time (around 500 ms to 1 sec).