| Term | Description | Examples |
|---|---|---|
| Hardware Platform | A common/generic hardware design, based on a particular architecture design. Uses a common set of standards. | ARM AArch64 x86 x86_64 |
| Hardware Model | A specific version of a device/board/small computer, based on one of the Hardware Platforms. |
Banana Pi Banana Pi Pro Orange Pi PC Orange Pi Plus 2E Raspberry Pi 1 Raspberry Pi 2 Raspberry Pi 3 Raspberry Pi 4, xxGB RAM version Raspberry Pi 4, yyGB RAM version Trimslice Pro RockPro64 PineBook Pro |
Note the variety of sub-versions of Hardware Models. This is because each model usually requires a separate Device Tree configuration as the map of the board layout changes in lock step with the hardware specification.
Slackware is both an Open Source Project that is freely distributed, and it is a commercial product, for which the developers encourage donations and funding - not only as a token of recognition of value, but because it costs money that comes directly from the pockets of the developers. Hardware needs to be purchased and maintained, and electricity to power them, etc.
In order to maintain the consistency and accountability, all assets (Slackware packages and other stand-alone binaries) that comprise the distribution of the Slackware project are built within the official Slackware environments. The Slackware build infrastructure is not publicly available, nor does it need to be for the user base to contribute to the project: the entire distribution is open source and the build scripts are available and can be used within your own environment to entirely re-create the Operating System.
The support forum also provides the platform for feedback, bug fixes and suggestions from the user base, many of which are incorporated into the project. If you are interested in contributing packages to the project at large, one of the best ways is to join the SlackBuilds.org community and work with the developers there. Packages from there often migrated into the mainline Slackware distribution.Slackware ARM / AArch64 is developed and maintained by one of the Slackware core team: Stuart Winter (MoZes@slackware).
Stuart has maintained and developed Slackware for ARM for almost twenty years and has developed a build system that automates most of the package building and maintenance tasks. However, one of the key differences between the x86/64 and the ARM/AArch64 worlds is that whilst there is a generic Linux Kernel that can support all devices, each Hardware Model requires individual attention not only at the initial integration, but each device becomes a maintenance burthen (documentation, testing, Kernel patches (hopefully not!), firmware, boot loader, etc.); where as in the x86 world, the developers need not concern themselves to such a degree with the needs of individual Hardware Models.
As such, the Slackware ARM / AArch64 development uses the Hardware Model Custodian development and maintenance model (this author is aware that it's a sexy name and surely encourages people to want to get involved). A Hardware Model Custodian is an individual (or an individual who coordinates the efforts of others) who develops the initial work required to light up Slackware ARM / AArch64 on the new platform, and continues to manage it going forwards.
Upon studying the Hardware Model Direct Integration documentation, you'll observe that it is a simple plugin system at its heart. Hardware Model Custodians can use the live configuration files and scripts as templates, and a guide to the standards.
The documentation also gives potential Hardware Model Custodians an idea of the range of domains that they must master and maintain. Additionally, Custodians need to keep pace with the Kernel developments and where possible, testing Kernel builds ahead of time so that any changes can be merged into the Slackware Kernel build. If the Hardware Model that a Custodian supports becomes popular, Custodians may also want to help with the user base (or fan base, if you prefer thinking within those constructs) on the support forum.
This simplistic approach allows the Hardware Model Custodians to maintain and manage support in which ever way they prefer (directly email patches to the list, or maintain the support within their own github repository), and simply send a notification email to the mailing list that an update for their Hardware Model is ready.
This approach also enables the flexibility for Hardware Model Custodians to use their preferred tool set and workflows to perhaps centrally manage contributions from the user base of their Hardware Model.
The updated assets are downloaded by the Slackware ARM developer, merged into the ARM source tree and will be rebuilt.
Note:We're not developing the Slackware Operating System here (suggestions need to be made through the
support forum), so as a general rule the the mailing list traffic will typically revolve around
Hardware Model support.
However, if there are bugs in the Slackware ARM build system, or ARM/AArch64-specific improvements that can
be made without affecting the Slackware experience, these will be considered.
An example of would be to enable the hand-optimised ARM assembler code paths in the OpenSSL package for 32bit ARM.
Some vendors do not readily enable support for community-developed projects (including but not limited to Slackware, Debian, Fedora, ArchLinux, Gentoo) in critical areas of the stack - most often the Linux Kernel (typically hardware support). Unfortunately, this means that the developers of these community distributions have to work much harder to enable their OS distribution on such Hardware Models.
In such cases the hardware vendor provides their own 'spin' of one of the major vendors (such as Debian, Ubuntu) and prefers that the user base use their distribution. From a business and support perspective, this makes perfect sense and this author would do the same. However, from the perspective of this author working within the Open Source Community, it's far easier and more rewarding to work with vendors who work to have their hardware supported by the mainline Linux Kernel (which is also maintained and developed in part by volunteers (and with many working for commercial vendors also)).
For this reason, such Hardware Models can run distributions such as Slackware but require more effort or diverge significantly from the industry standards, that the effort involved in direct integration (supporting those devices directly within the distribution so that it works "out of the box") isn't worth it, as it continues to be a development burthen.
Compare and contrast with the simple process of ingesting a mainline Kernel that supports all of the devices, and once every now and then over the course of a year, that Kernel will fail on one of the supported hardware models, but for the balance of the time, Kernel upgrades work flawlessly.
This author encourages any such vendors to make efforts to have your hardware supported upstream: you may yet sell more hardware units.Until such vendors change their tac, there are some community projects that whilst are not directly integrated into the Slackware ARM/AArch64 project, do function correctly and are actively developed and maintained. The caveat is that the Kernel management usually isn't integrated with the 'slackpkg' package management tool, and the Kernel configuration options may not present or enable the same or consistent user-land experience as for hardware models that are directly integrated.