TLXOS 5.0.0 and TMS 9.0.0 work is taking longer than expected, so we are squeezing a little more life out of TLXOS 4.x and TMS 8.x. It's still the plan that the final TLXOS 4.x release (currently 4.11.x, hopefully a 4.12.x will not be necessary) will become the new Long Term Stable (LTS) release - replacing TLXOS 4.8.x - when TLXOS 5.0.0 is released. We will consider releasing TLXOS 4.8.4 if customers really need this, although Debian Jessie is now very old indeed. We are now being severely hampered by TLXOS 4.x design limitations, in particular the inability to provide a Linux kernel later than 5.4 due to insufficient space in the /boot filesystem, and therefore intend to deliver TLXOS 5.0.0 under TMS 8.x, rather than delaying it until TMS 9.0.0 is ready. TLXOS 5.0.0 will still include the features that we guaranteed in our previous announcements, namely: - TLXOS 5.x releases will be based on Debian 11 (Bullseye), and will initially feature a 5.10 Linux kernel. - TLXOS will no longer have a separate Maintenance Mode partition (or Linux kernel). Maintenance Mode will be merged into the /boot filesystem, as an alternative initramfs that will use the same kernel as Normal Mode. - TLXOS installation will become more flexible with regard to filesystem sizes. Upgrades will be able to enlarge the base root filesystem (/actualroot) as needed, and if necessary will repartition to enlarge /boot also, although this will necessarily result in loss of midlayer (/config) data, i.e. reset to default settings. - TLXOS 5.x will no longer support ARMv6 (Raspberry Pi v1 or original Pi Zero) or 32-bit-only PCs. TLXOS RPi IoT, TLXOS SFF (NUC32/64), and 32-bit capable TLXOS RePC will only exist as 4.x LTS versions, until such time as a TLXOS 5.x LTS baseline is established. A means to transition from NUC32/ NUC64 to RePC will be provided. We intend to achieve the TMS 4.x-5.0 transition by means of a TLXOS 4.x update with a TLXOS 5.x-compatible Maintenance Mode image that, when booted, will apply an irreversible TLXOS 5.x layout conversion, i.e. it will merge the Boot and Maintenance Mode partitions. This will put your devices in a kind of "version 4.99" state, from which you can upgrade to 5.0.0, but not downgrade. We have delivered early, in TMS 8.4.0, two of the features that were originally listed as "likely" for inclusion in TMS 9.0.0: - Introduction of basic policy, i.e. association of saved profiles with TMS device groups, such that TMS will require any known client to conform to the saved profile linked to the device group of which they are a member, when they check in with TMS. - Overhaul of Digital Signage to use out-of-band rsync content synchronization (pull-based) instead of clumsy in-protocol content synchronization (push-based). This will be much more efficient, although clients will require direct access to the rsync service on the TMS server. The older scheme will still be available via a legacy option. We will probably also implement the following formerly-TMS9-likely features prior to TMS 9.0.0: - TLXOS licenses will be consolidated into a one-license-fits-all solution, i.e. you will be able to run any edition of TLXOS using a common entitlement. New licenses will be at the higher SFF/RePC cost (USD $15 per device); we will not retroactively compensate SFF/RePC owners with additional entitlements. - Improved VPN capabilities, including password-based OpenVPN and Wireguard. The following features currently remain deferred until TMS 9.0.0: - Encryption of updates (TLXOS firmware, tms_client, hotfixes) will be removed, and the firmware format will be simplified to be a zip file containing binary firmware object(s) and metadata file(s) in a format that ThinLinX will publicly document, along with optional GPG signature(s). This will allow customers to create their own hotfixes. TMS will check GPG signatures against an approved keyring and report whether or not the update passes signature checks. - Upgrade of boot[/TFM] and root filesystems will be completely separate, allowing upgrade to a newer Linux kernel (and Maintenance Mode image) while remaining at the same base firmware version. - Rewrite of TMS for internal client-server separation and multi-session capability, i.e. an "always on" background service/daemon component and one or more on-demand GUIs. TMS was not designed for this, so it is a very extensive and ambitious rewrite. TMS GUIs will be able to run on a different host than the service/daemon, and you will be be able to run two or more concurrently. - TMS 9.0.0 will introduce the concept of a "filestore" database, whereby downloaded updates, and files installed by the user, will be permanently stored in a hash tree such that clients can request download of such objects by hash rather than by name. This means that files installed using TMS' "File->Install File" option (e.g. SSH keys and CA certs) will be part of a saved profile, and client devices will automatically download these if they are missing.