Forums » Suggestions
Alternative Linux Package: Lightweight Launcher Method (Save Bandwidth)
Hey everyone,
If you've ever tried packaging or installing Vendetta Online on Linux, you've likely run into a bit of a friction point. The standard official Linux installer weighs in at around 653 MB. While it works, downloading a massive binary bundle doesn't really align with clean packaging guidelines or efficient distribution models for modern package managers.
More importantly, it’s entirely unnecessary.
How It Works
Under the hood, all you actually need to bootstrap the game is a single core executable file (update.rlb), renamed to vendetta and placed in /usr/bin/vendetta (or your preferred binary path).
That tiny ~2.6 MB vendetta executable is fully self-sufficient. When launched, it handles everything else:
- It automatically provisions the ~/.vendetta local user directory if it doesn't already exist.
- It connects, checks for updates, and downloads/updates the full game assets natively on demand.
(Note: Manually creating the empty ~/.vendetta directory ahead of time is also a handy trick if you use the traditional archive, preventing the updater from falsely assuming nothing is installed and re-fetching the entire 653 MB archive unnecessarily).
For the ArchLinux/KaOS/Manjaro/etc Linux package, we can bypass the heavy monolithic installer entirely to save time, disk space, and bandwidth.
Instead of downloading half a gigabyte, the PKGBUILD only needs to:
- Fetch the lightweight 2.6 MB vendetta updater binary.
- Install a standard application .desktop entry.
- Include a clean application icon.
- Include a License file.
Why This Matters
- Bandwidth friendly: Cuts initial installation downloads down from ~653 MB to just a few megabytes.
- Compliant: Fits nicely within clean distro packaging standards.
- Always up-to-date: Lets the native updater fetch the latest assets directly on first launch.
If you maintain packages for other distributions or want a cleaner way to handle deployments, shifting to the direct binary bootstrapping method is well worth it.
See you out in space!
If you've ever tried packaging or installing Vendetta Online on Linux, you've likely run into a bit of a friction point. The standard official Linux installer weighs in at around 653 MB. While it works, downloading a massive binary bundle doesn't really align with clean packaging guidelines or efficient distribution models for modern package managers.
More importantly, it’s entirely unnecessary.
How It Works
Under the hood, all you actually need to bootstrap the game is a single core executable file (update.rlb), renamed to vendetta and placed in /usr/bin/vendetta (or your preferred binary path).
That tiny ~2.6 MB vendetta executable is fully self-sufficient. When launched, it handles everything else:
- It automatically provisions the ~/.vendetta local user directory if it doesn't already exist.
- It connects, checks for updates, and downloads/updates the full game assets natively on demand.
(Note: Manually creating the empty ~/.vendetta directory ahead of time is also a handy trick if you use the traditional archive, preventing the updater from falsely assuming nothing is installed and re-fetching the entire 653 MB archive unnecessarily).
For the ArchLinux/KaOS/Manjaro/etc Linux package, we can bypass the heavy monolithic installer entirely to save time, disk space, and bandwidth.
Instead of downloading half a gigabyte, the PKGBUILD only needs to:
- Fetch the lightweight 2.6 MB vendetta updater binary.
- Install a standard application .desktop entry.
- Include a clean application icon.
- Include a License file.
Why This Matters
- Bandwidth friendly: Cuts initial installation downloads down from ~653 MB to just a few megabytes.
- Compliant: Fits nicely within clean distro packaging standards.
- Always up-to-date: Lets the native updater fetch the latest assets directly on first launch.
If you maintain packages for other distributions or want a cleaner way to handle deployments, shifting to the direct binary bootstrapping method is well worth it.
See you out in space!
The problem is, this pushes the entire game through our update servers, which is not at all desirable. They're only intended for small delta patching, and they don't really have the greatest bandwidth.
They can also only sustain a limited number of connections per server before they start to "queue", this is not a modern CDN-style situation (the architecture predates the existence of CDNs).
This is why we ship the game installs pre-loaded with a "reasonably recent" set of game data files and binaries: So the delta-patch on first runtime is relatively light.
If you maintain packages for other distributions or want a cleaner way to handle deployments, shifting to the direct binary bootstrapping method is well worth it.
Yeah, we definitely don't want distributions doing this. That would be undesirable. Especially because the entire current-spec "Updater" system is likely to be deprecated in the coming months for a completely different system that uses a fundamentally new architecture. So the number of servers for the old "Update" mechanism will likely be cut back, as they'll only exist to support legacy installs from people who have the game installed, but haven't run it in years.
They can also only sustain a limited number of connections per server before they start to "queue", this is not a modern CDN-style situation (the architecture predates the existence of CDNs).
This is why we ship the game installs pre-loaded with a "reasonably recent" set of game data files and binaries: So the delta-patch on first runtime is relatively light.
If you maintain packages for other distributions or want a cleaner way to handle deployments, shifting to the direct binary bootstrapping method is well worth it.
Yeah, we definitely don't want distributions doing this. That would be undesirable. Especially because the entire current-spec "Updater" system is likely to be deprecated in the coming months for a completely different system that uses a fundamentally new architecture. So the number of servers for the old "Update" mechanism will likely be cut back, as they'll only exist to support legacy installs from people who have the game installed, but haven't run it in years.
I see...
Thank you so much for the explanation. Now I have clear the situation.
Thank you so much for the explanation. Now I have clear the situation.