Why Xi Software
What Xi-Batch, Xi-Exec and Xi-Text add to cron, ssh and lp - and the three other answers a buyer asks for: who owns the system, how it is tested, and who already runs it.
Most organisations run scheduled, unattended work. Some of it is the overnight cycle; some of it runs hourly, on a file arriving, or at the end of a shift. The shape is the same. Work is scheduled, it executes across a number of servers, and it produces output that has to reach a printer, a file or a person. It is the least glamorous part of the estate and the part that must not fail.
Every operating system ships something for each stage, and for a single machine running a handful of jobs they are the right answer. Production estates ask for more: dependencies that span hosts, output that has to arrive, and work that reaches other machines without handing out shell accounts.
Each page below takes one stage, says plainly where the standard tool is sufficient, and sets out what Xi Software adds when it stops being.
The three comparisons
| Stage | What ships with the system | Where it stops | What Xi Software adds |
|---|---|---|---|
| Scheduling | cron |
No job-to-job dependencies, no coordination across hosts, no display, no intervention once a job has started | Xi-Batch |
| Remote execution | ssh and a shared key |
Shell access on every target, key distribution and rotation, no per-operation control, incomplete audit | Xi-Exec |
| Output | lp and CUPS |
No routing by form type, no restart at the point of failure, no per-user or per-group control of printers | Xi-Text |
Each row is a page. Each page says where the standard tool is the right answer before it says anything else.
Scheduling
cron starts commands at times. It cannot express that one job depends on another,
cannot coordinate across hosts, shows nothing about what is running, and hands
back control the moment a job starts.
Remote execution
Scheduled work has to reach other machines. The usual arrangements - a shared key, a service account with a shell, an SSH command that became an interface - all amount to granting the ability to run arbitrary commands somewhere else.
Output
lp and CUPS are fine for a desktop. They cannot restart a failed
sixty-thousand-page run at the point of failure, route by the form loaded rather
than the printer named, or stop most of the organisation reaching the cheque
printer.
Why one supplier for all three
These are not three unrelated problems. They are three stages of the same operational cycle, they fail together, and they are usually run by the same team.
The scheduling vendors do not sell print management. The print vendors do not sell schedulers. Almost nobody sells the execution layer as a product at all.
We build all three, and they are designed to work together.
The rest of the question
Comparing features settles what the software does. Three things settle whether to run it.
Who owns the system
Everything runs on your machines, and nothing in the operating path depends on us. No licence server to reach, no cloud to be available, no telemetry.
How it is tested
Nine stages between a line of code and a package you can download, independent verification of every package on every platform, and fuzzing that refuses a release until its record is clean.
Who already runs it
What customers actually run, recorded from them rather than written for them.