About this index

An index, kept current by hand

KobiSite CDN is a catalogue of full desktop software builds for Windows workstations. Every entry is a complete offline installer rather than a small downloader that pulls the real package later, and every entry carries the version string, the package size, the release type and the file details on the page before anything is started.

The index started as an internal list. A handful of people rebuilding machines for a small studio kept passing the same links around, got tired of the version confusion, and wrote the whole thing down properly. It stayed useful, so it stayed online, and the list has grown steadily since.

There is no account system and there never has been. Nothing here is gated, nothing asks for an address, and no page requires anything to be created before it can be read. That is a deliberate decision rather than a missing feature.

What happens before a title is listed

A title is checked before it appears. The package is extracted on a clean machine, the installer is run through to completion, the application is opened, and the version reported by the application is compared against the version claimed by the package. Anything that does not match is not listed.

Once a title is listed it is checked again on a refresh cycle. Mirrors go stale, transfer paths break, and a package that worked six months ago sometimes does not survive a change further up the chain. The refresh pass catches most of that before anyone else runs into it.

• The package is extracted and installed on a clean machine before listing
• The reported application version is checked against the claimed version
• Package size and file details are recorded from the actual file, not from a source listing
• Every listed title carries three transfer paths so one failing does not remove it
• Entries are rechecked on a refresh cycle and dead paths are rebuilt
• Titles that cannot be verified are removed rather than left listed

Why every entry has long notes on it

Most listings elsewhere give a title, a size and nothing else, which pushes the whole burden of working out whether a package is the right one onto whoever is downloading it. The notes here exist to answer that in advance: what the build actually contains, what changed in this version, what the machine needs to run it, and what commonly goes wrong during installation.

The installation steps in particular are written from what actually happens rather than from a generic template. The advice to pause protection software, to close background helpers, and to use a short extraction path all come from the same handful of failures repeating themselves.

Where a title has a known limitation it is written down on the page rather than left out. A build that needs a specific architecture, a plugin set that will not survive an upgrade, or a package that conflicts with an older release is worth knowing about beforehand.

Requests, corrections and takedowns

Missing titles and wrong versions go on the requests page, and the queue is worked through on each refresh. A request that names the exact version needed is far more likely to be filled than one that names only the application.

Corrections to an entry, broken transfer paths and anything else about the index itself go through the contact page. Rights holders should use the takedown page, which sets out exactly what a notice needs to contain and how quickly it is handled.