PiKISS and the menu of shell scripts behind a Raspberry Pi install

A menu in front of a directory of scripts

PiKISS is a bunch of scripts with a menu to make your life easier, and the repository layout is the clearest description of how it works. At the top level there is piKiss.sh as the entry point, a scripts/ directory holding the individual installers, a bin/ directory, a res/ directory for resources, icons/, screenshots/, a CHANGELOG file, and a .shellcheckrc, which is the configuration for ShellCheck and tells you the scripts are linted.

The menu is organised by category, and the categories are visible in the changelog entries. There is Games, with ports and commercial titles such as OpenMW for Elder Scrolls Morrowind, OpenRCT2, OpenJK for Jedi Academy, Hexen2, Hurrican, OpenBOR, CatacombGL, Heroes of Might And Magic II, and Space Cadet Pinball. There is Emulators, with Dolphin for Wii and GameCube, RetroArch at version 1.20.0 with SNES9x, Genesis Plus GX, mGBA, Nestopia and DeSmuME cores, and AetherSX2 until it was removed because no source code was available. There is Devs, with OpenCode, and an AI section with gemini-cli, litert-lm and opencode, added in June 2026 and already trimmed in September 2026.

There is Info, with tools like Webmin and the Lynis auditing tool, and Others, with utilities such as Hangover, a Wine front end at version 11.0, and UXPlay for AirPlay mirroring. A Config section manages system settings, and there is a Vulkan detection improvement for the emulators that need it.

The primary language is Shell and the topics cover Raspberry OS, Odroid and games as well as scripts. The audience is a hobbyist with a spare Pi, a RetroPie-adjacent setup, or a small home server, who wants the software rather than the setup work.

The installer pipes a remote script into bash

The TL;DR section of the README is one line, and it is the whole installation:

curl -sSL https://git.io/JfAPE | bash

This deserves a careful reading rather than a reflexive one. The command downloads a script over the network and hands it to the shell directly, with no checksum, no signature and no review step. Whatever that script does, it does with the privileges of the user who typed the command, and on a Raspberry Pi that user is usually pi, whose password is famously known.

There is a second, smaller problem. The URL uses git.io, a GitHub URL shortener, and the README also links to the author's own blog and a Discord server rather than to a release artefact. The project has no GitHub releases, so the short link is not pointing at a tagged, versioned installation script. For a collection of shell scripts that install software with root privileges, that is a supply chain shape that deserves a second thought.

None of this makes the project bad. Piping an installer into a shell is common practice in this corner of the ecosystem, and the scripts are the visible artefact of an open repository that anyone can read, with ShellCheck configuration in the tree. But the correct posture for a reader is to treat the one-liner as a convenience, and to fetch the repository and read the script before running it, which is a five minute exercise that removes the entire problem.

The changelog is the documentation

PiKISS does not have a manual. What it has is a dated changelog in the README, and reading it tells you more about the project than a feature list would.

The entries are structured as adds, improvements and removals, each with a date in day, month, year format. On 03/09/26 the Dolphin Wii and GameCube emulator was improved and gemini-cli was removed from the AI section. On 07/06/26 the AI section was added with gemini-cli, litert-lm and opencode, and Diablo II was removed from Games. On 18/04/26 OpenCode was added under Devs. On 25/04/26 Webmin and the Lynis auditing tool were improved and fixed, and two Info entries were removed, Check image updates, described as obsolete, and the Web monitor.

The removals are the most informative part, because they show the project tracking the platform rather than just accumulating options. AetherSX2 was removed with the reason given in the entry itself, that no source code was available. The Check image updates option was removed as obsolete. Several entries that did not work on the newer Raspberry Pi OS were removed outright rather than left to fail.

The rhythm is roughly one to three entries a month through 2025 and 2026, which is the pace of a one person project keeping a catalogue current against a moving base image. For a user, that rhythm is a signal: the entries are small and frequent, so a script that was fine last month may have been rewritten this month, and the changelog is where you find out what changed.

Sixty four bit is arriving entry by entry

A recurring theme in the changelog is the move from 32-bit armhf to 64-bit aarch64, and the project is working through the catalogue one entry at a time.

The 64-bit additions are dated and specific. CatacombGL for aarch64 in January 2026, OpenJK for aarch64 in December 2025, OpenRCT2 for aarch64 in January 2026, OpenMW v0.51 for aarch64 in November 2025, Hurrican for aarch64 in November 2025, JFDuke3D replacing Eduke32 for aarch64 in November 2025, and Space Cabinet which had its binary URLs moved in December 2025. The February 2026 entry records the removal of armhf support for Hangover, the Wine front end, at version 11.0 for aarch64.

That last one is the shape of the whole migration. A 32-bit build was the default for years on Raspberry Pi hardware, and the 64-bit transition is not a single flag but a long tail of per entry work, with binary availability, not code, being the limiting factor. AetherSX2 was removed entirely because no source code was available, which is a different failure mode again, a project whose binaries cannot be redistributed and cannot be built from source by the maintainer.

The practical consequence for a user is that the entry list is not uniform across architectures, and the changelog is the only map of which entries work where. A 64-bit Pi with a modern Raspberry Pi OS is the well trodden path, and everything else is a per entry question.

The OS edition matters more than the Pi model

One line in the README deserves emphasis, because it is the kind of constraint that decides whether the project is useful to you. The next at the moment, it is exclusively working for Raspberry Pi OS Booksworm Edition, and then a list of entries is removed with the note that the next is currently only working for Booksworm.

The October 2025 entry is the clearest case. OpenFodder was added, and Crispy-Doom was fixed, and then a block of removals followed with the note that the next is at the moment exclusively working for Raspberry Pi OS Booksworm Edition. Heroes of Might And Magic III, Hermes as obsolete, a Vulkan 25.2.4 configuration entry, 2Ship2Harkinian, Alien Versus Predator, Diablo 2 with Wine, GTA and GemRB were all removed in that block.

The reason is stated separately: if you find any issue with the latest RPi OS Trixie, please open an issue at GitHub Issues. So the project is mid migration between two operating system releases, and the answer to the question of what works is: the Booksworm entries, and the Trixie entries are being reported as issues one at a time.

That is a fair way to run a catalogue, and it is also a real limitation for anyone evaluating. A script that worked on Bookworm may fail on Trixie for reasons that have nothing to do with the script, and the fix is an issue and a wait. Anyone adopting this on a machine they care about should check the operating system edition first and match it to the changelog.

Donation funded, community maintained, one author

The README documents the economics of the project with unusual detail, and it is a good indicator of how it is run.

There is an estimated 1356 hours of work so far, and a total donated by users and sponsors of $2.805,13 in the European decimal notation, that is 2,805.13. The funding routes are PayPal, Ko-fi, Patreon and Coinbase, and the README thanks individual contributors, patreons and past patreons by name, including a Patreon Legend. The screenshots come from TwisterOS, which tells you the author runs the tool on a themed Raspberry Pi OS image.

The project is also present on a blog, misapuntesde.com, in English and Spanish, with a YouTube playlist showing what PiKISS can do, a Discord for suggestions and support hosted with the help of Pi Labs, and a Mewe group for Spanish speakers. A contributors section lists five named contributors and credits the logo to grayduck.

What the picture describes is a single maintainer with a large volunteer base, funded by donations and spending a very large number of hours on it. The top level contains a .github/ directory, a .shellcheckrc and a .vscode/ directory, so the mechanics of contribution are in place even though the work is concentrated in one person.

MIT, no releases, and a changelog instead of a version

The licence is MIT, with a LICENSE.md file at the root of the repository. One detail is worth flagging for anyone who looks at the badges: the licence badge in the README points at the LICENSE file of a different repository, jmcerrejon/neighborhood-games, rather than at this one. The repository does have its own LICENSE.md, so the licence is unambiguous, but the badge is not pointing at it.

There are no GitHub releases, and the version is carried by the CHANGELOG file and the dated entries in the README rather than by a tag. The repository is not archived, and the last push was on 2026-10-03, with the most recent changelog entry dated 03/09/26.

For a user that means there is no version to pin and no upgrade path in the usual sense. You do not update PiKISS the way you update a package, you re-run the installation, and the menu is rebuilt from the scripts directory in the branch. That is fine for the intended use, a script that installs a game on a machine you are setting up, and it is not fine for anything that needs reproducible state, because the contents of the menu and the behaviour of each entry can change between one run and the next without a version marker.

The judgement for an adopter is simple. It is a well maintained, generously documented, donation funded collection of install scripts with a candid changelog, and it should be used on a machine you can rebuild, with the script you are about to run read first.

Editorial conclusion

Adopt PiKISS if you want a fast, menu driven way to get games, emulators and developer tooling onto a spare Raspberry Pi without hand assembling dependencies, and if you are the kind of user who reads a script before running it. Do not adopt it on a machine whose contents you cannot lose, since the menu installs binaries from third party sources with root privileges and the project publishes no per item audit trail. Verify three things first: that the Raspberry Pi OS edition you run is the one the current scripts target, that the architecture of your board matches the entry, since 64-bit aarch64 is being added entry by entry and 32-bit support is being dropped, and that the script you are about to run does what you expect, because the README is a list of intentions rather than a specification. The last push was on 2026-10-03 and the repository has no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. jmcerrejon/PiKISS on GitHub
3. License: MIT
4. Project website
5. README