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.
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.
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 |
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
The three stages belong to one operational cycle. A failure in one shows up in the others, and the same team usually runs all of them.
Scheduling, remote execution and output are usually bought from different suppliers, where the execution layer is sold as a product at all. We build all three, and they are designed to work together.
The rest of the question
A feature comparison says what the software does. Buyers usually ask three further questions before running it: who owns the system, how the software is tested, and who already runs 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.