There are reports that the DVD download of openSUSE - which is all of nearly 4.2 gig - does support secure boot and can boot up on hardware that is certified for Windows 8. Other reports say that the two live CDs, KDE and GNOME, cannot boot up on such hardware.
There is no clear indication in the literature supplied that secure boot is supported. "GRUB2 is the default bootloader laying the foundation for booting from LVM and btrfs partitions as well as support for UEFI Secure Boot," is what it says.
Whether that means it is just laying the foundation for supporting secure boot, or already does so, is open to interpretation. Comment has been sought from SUSE.
The release was put off from July and the obvious reason for that is the preparation for secure boot. Nothing else could have got in the way. For Novell, openSUSE is the testing ground, before changes go into the enterprise distributions, SLED and SLES.
Computers which are loaded with Windows 8 by OEMs will need to have a sticker certifying that they have a secure boot process enabled.
Such computers will have a replacement for the BIOS (basic input output system) called UEFI (United Extensible Firmware Interface).
In UEFI, it is possible to use cryptographic keys to check the operating system that is trying to boot on that machine.
The system firmware, in this case UEFI, can contain one or more signed keys and any executable that is not signed by these keys cannot boot on said system. Another set of keys - called Pkek - allows for communication between the operating system and the firmware.
An operating system with matching Pkek keys can add more keys to a whitelist - or a blacklist. In the latter case, any executable which has a key that is on the blacklist will not boot.
SUSE has come up with what is described as the best way of coping with secure boot. It starts with a shim, that is signed either by a SUSE key-exchange-key or a Microsoft key. This then loads the GRUB2 bootloader, after ascertaining that it can be trusted.
The shim will also allow the loading of keys that are specific to the machine in question, keys which can override the default SUSE key.
Once GRUB2 is loaded, it will communicate with the shim in order to verify the kernel that it is booting. The shim will check with the machine-specific keys and authorise the kernel being loaded.
openSUSE has a dual purpose; it offers an eminently usable desktop and also serves as a test-bed for the enterprise distribution. SUSE's priorities are different from those of Red Hat - which also has its own test-bed, the Fedora distribution. SUSE aims for both server and desktop, unlike Red Hat which has no interest in the desktop.
One can choose btrfs as the default filesystem - though it is interesting to note that when does this, a /boot partition is created and this is formatted as ext4. An indication, perhaps, that in the minds of the openSUSE developers, btrfs is less stable than ext4.
In truth, btrfs is a little "stickier" than ext4; the system does not seem as responsive. This is not based on any benchmarks, just my own observation after using btrfs as default for a KDE installation and ext4 as default for an installation from the GNOME live CD.
Both KDE and GNOME are polished, and quite a bit different from the default. KDE surprisingly has no PDF reader loaded as part of the default install. A command-line tool for installation, zypper, seems to work pretty well in this release. But the Apper update tool, formerly known as KPackageKit, is buggy and loops when one tries to update using it.
That apart, one can find little fault in the the release. It is slick, neat and very polished indeed. One can try out other desktop environments like XFCE and LXDE, (by downloading the DVD).