Welcome to SUSE's ISV Development and Compatibility Resources

This page provides resources to help you certify, develop, and maintain your applications on SUSE Linux Enterprise Server (SLES) 16. Whether you’re ensuring compatibility with SLES or integrating SUSE-specific features alongside support for other Linux distributions, we are here to assist you.

Why Choose SUSE Linux Enterprise Server (SLES) 16?

SLES is a powerful, flexible platform that helps ISVs deliver reliable and innovative solutions to their customers. Key benefits in the SLES 16 release cycle include:

Stability and Longevity: SLES 16 extends the general support period for each minor release to 24 months. This provides ISVs and customers with significantly more time to validate and adopt new versions, minimizing upgrade frequency and ensuring undisrupted business continuity. SUSE rigorously tests for library and ABI compatibility during Quality Assurance.

Enterprise-Ready: SLES offers a robust ecosystem of tools, modules, and certifications to meet modern enterprise demands.

Forward-Looking Development: SLES 16 removes legacy components and embraces modern standards, enabling ISVs to build applications ready for the future.

Our Commitment to Compatibility

Userspace

At SUSE, we prioritize “userspace application compatibility” to ensure a stable and predictable environment for ISVs. Our engineering policy guarantees no userspace application compatibility breaks across minor releases or maintenance updates within a major release cycle.

Kernel-Level Changes

While userspace compatibility is preserved, kernel-level changes introduced in some service packs may impact ISVs that depend on or develop kernel modules. For this reason, ISVs with kernel dependencies must validate and recertify their applications for each minor release.

If your applications rely on kernel modules, our ISV team is available to support your migration or recertification efforts. For more information about building Kernel Modules or kernel ABI (kABI) compatibility please visit our Solid Driver Program

Key Features and Considerations in SLES 16

SLES 16 introduces several significant updates and changes compared to SLES 15, which ISVs should consider during migration and development.

Release and Lifecycle

  • Versioning: SLES 16 uses minor releases (e.g., 16.0, 16.1) for annual updates, replacing the Service Pack (SP) naming convention used in SLES 15.
  • Support: Each SLES 16 minor release has 24 months of general support. The last minor release (16.6) will have 48 months of general support to complete a 10-year lifecycle. Additional Long Term Support (LTS) is available for 3 years. SUSE Linux Enterprise Server for SAP applications 16 includes five years of support, consisting of general support for 2 years plus 3 years Long Term Support, for 16.6 this will be 4 years of general support plus 1 year of LTS.. Please visit our Product Lifecycle and Product Lifecycle Policies pages to learn more.

System Management and Installation

  • Installation: The YaST installer has been replaced by Agama. Agama focuses solely on system installation and is accessible via a Web-based front-end, command-line interface, and HTTP API. While Agama maintains a high degree of compatibility with AutoYaST profiles, some adjustments are expected, and a new profile schema based on JSON/Jsonnet is also available.
  • Management: YaST is no longer shipped as a general management tool in SLES 16. For 1:1 management tasks, Cockpit is available with a Web-based interface. For automation, SLES 16 supports Ansible and SUSE Multi-Linux Manager (which uses Salt internally). Salt packages are not included in SLES 16 itself, they are part of SUSE Multi-Linux Manager.
  • Init System: SLES 16 completes the transition from SysV init, using systemd native units exclusively. LSB-compliant init scripts were supported in SLES 15 and earlier but are removed in SLES 16.

Supported Hardware Architecture

Intel / AMD (x86-64)IBM Power (ppc64le)Arm(aarch64)IBM Z (s390x)
SLE 16Using x86-64-v2, prepare to run x86-64-v3*Power9**Armv8.0-Az14
SLES for SAP 16Using x86-64-v2, prepare to run x86-64-v3*Power9**Not SupportedNot Supported

* On x86-64, SLES 16 delivers v3 optimized versions of some shared libraries (naming scheme: libfoo-x86_64_v3). These will be installed and used automatically on systems supporting v3.
** On IBM Power, SUSE enables execution on Power9 but supports only Power10 and above.

Security and Architecture

  • Security framework: SLES 16 defaults to SELinux in enforcing mode and ships with policies for over 400 modules, confining almost the whole system. SLES 15 used AppArmor by default that was removed in SLES 16.
  • 32-bit support removed: The 32-bit runtime for x86 applications is no longer supported in SLES 16. ISVs should plan a migration to 64-bit platforms.
  • Network: The wicked network configuration tool is removed in SLES 16 in favor of NetworkManager. NIS is no longer used - choose LDAP instead.
  • Firewall: Iptables is replaced by NFTables. The system defaults to the modern NFTables packet filtering framework. ISVs with custom firewall rules using raw iptables commands need to migrate these rules, potentially using translation tools, or rely on firewalld integration which now uses NFTables as its backend.
  • In-Memory Store: Redis is replaced by Valkey. Due to licensing changes in the upstream project, SLES 16 includes Valkey as the drop-in replacement for Redis. Applications relying on Redis must ensure compatibility with Valkey APIs, although it is designed to be highly compatible.
  • DHCP Server: ISC DHCP server is replaced by Kea DHCP. The ISC DHCP server has been removed in favor of the more modern Kea DHCP server. Custom configurations (dhcpd.conf format) for DHCP services must be migrated to the Kea configuration format (JSON-based).

Base System Changes

  • Configuration Files: SUSE continues to move default configuration files from /etc to /usr to allow users to maintain custom settings in /etc without fear of maintenance updates overwriting them. ISVs should note that a custom copy in /etc/frob.conf will take precedence and cause the /usr/etc/frob.conf file to be ignored. Alternatively, drop-in files can be placed in /etc/frob.d. Beware this change is not available for all packages.
  • /tmp No Longer Persistent: The /tmp directory is no longer persistent between reboots in SLES 16, as it uses the tmpfs file system. Applications that write persistent data to /tmp should be updated to use a different location such as /var/cache or /var/tmp.
  • Package Management: SLES 16 removes the modular design seen in SLES 15 (e.g., Legacy Module, Web and Scripting Module) and no longer uses separate channels for pool and updates. This simplifies package management and is expected to result in better performance for updates.
  • File Systems: The following file systems have been dropped in SLES 16: reiserfs, hfsplus, UFS, quota v1, and ocfs2. Btrfs remains the default, and gfs2 is now fully supported (read and write) but is only available on SLE High Availability extension.
  • Root Filesystem in Public Cloud Images: The root filesystem in the public cloud images of SLES and SLES for SAP applications 16 is Btrfs. It was xfs in SLES and SLES for SAP Applications 15 public cloud images.

Desktop and Virtualization

  • Desktop Environment: The desktop product has been discontinued. SLES 16 is available with a minimal desktop based on GNOME 48.
    • Display Server: X11 is no longer shipped; desktop sessions now use Wayland.
    • X11 applications are still supported transparently, thanks to XWayland.
    • Remote Access: The VNC server is no longer shipped; remote desktop and sharing are provided using RDP.
    • Widget Libraries: The GTK2, Qt5, and wxWidgets widget libraries have been dropped.
  • Virtualization: SLE 16 continues to support KVM. Support for Xen has been dropped.
  • Windows Subsystem for Linux: Support for WSL1 was removed in favor of WSL2, offering a full Linux kernel with complete system call compatibility.
Best Practices for ISV Development on SLES 16

To ensure a smooth migration and certification process to SLES 16, ISVs should follow these best practices:

  • Mandatory 64-bit Porting: Ensure all application binaries are fully built for 64-bit architectures.
  • API Compatibility: Validate that applications using Redis features work seamlessly with the new Valkey API, and adjust configuration files for the Kea DHCP server if necessary.
  • Firewall Logic Review: Review any low-level firewall interaction, especially if iptables commands are hard-coded, and plan for migration to the NFTables syntax or the recommended firewalld service interface.
  • New Defaults: Be sure to test against the new system defaults for SELinux, the tmpfs-based /tmp, and the move of default configuration files to /usr.
  • Updated Toolchain: Test applications using the latest tools and runtime environments available in SLES 16 minor releases.
  • Containerization: Leverage SUSE Linux base container images (BCIs) for application deployment. Containers help abstract kernel and system changes, simplifying deployment across different SLES versions and enabling cloud-native architectures.
  • Init Scripts and RPMs: Ensure compatibility with both SUSE Linux and other distributions (e.g., Red Hat) for init scripts (only use systemd services) and RPMs.
Achieving SUSE Ready Certification

The SUSE Ready program enables ISVs to self-certify their applications for compatibility with SUSE Linux Enterprise. This non-prescriptive process requires the ISV to determine adequate testing for compatibility.

Key steps for certification include:

  • Testing and Validation: Perform thorough compatibility tests across SLES versions and minor releases.
  • Verification of Dependencies: Ensure all required libraries and tools are compatible with the target SLES environment.
  • Customer Assurance: Declare commercial support for your application on SLES to build customer trust.

For more details, reach out to our INNOVATE Partner Team.