No. The ‘Official’ modified KDE release layout was designed for myself and my father out of personal preference. GNOME and KDE are additionally shipped to appease most major users, and all 3 are shipped because they support VRR — variable refresh rate (aka freesync) on wayland, which is a long term goal for gaming on linux. Other DEs at this time do not support VRR.
No. Our branding changes affect packages that other DEs pull in or require, and we will not be changing those packages to accommodate for DEs we don’t ship as ISOs. Additionally there are too many individual DE quirks/bugs/differences between them and we cannot support debugging all of them.
No. There are no plans to create a minimal and/or network install.
No. We currently update the ISO way too often (sometimes multiple times in the same week) for a long-term torrent to be available.
No. We have completely swapped SELinux in favor of AppArmor (this is what Ubuntu and OpenSUSE use). We find AppArmor to be more user friendly, less intrusive, and easier to manage and write policies for. You will still see some SELinux packages installed which are required to keep Fedora compatibility and not break package dependencies, but SELinux is otherwise disabled.
No. Nobara ships with a kernel that has been custom patched and is built and hosted on COPR. Packages hosted on COPR repositories have no simple way of signing the kernel after it’s been built. Additionally The boot shim has to be signed by Microsoft, whom have several stipulations that need to be met including the fee: https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916. We are a hobby distribution that uses a custom kernel. We have no plans what so ever to work towards meeting the shim signing requirements, let alone any additional custom kernel requirements.
NO. This is a big large huge NO. The Nobara install ISOs have a ton of packages that get installed which are specific to Nobara, and not installed on Fedora on fresh install. When you try to upgrade from Fedora to Nobara by just using the Nobara repos none of those extra packages get installed. Additionally Nobara changes a lot of Fedora’s base packages and branding. Things WILL break. Fedora installations updated to Nobara using the Nobara repos are -NOT- supported. A clean installation is required.
Delayed. In general I personally waited about 2 weeks after Fedora releases for any release bugs to be ironed out. Add that to the time it will take to convert Nobara packages to version 42 and you can expect about a month delay.
Depends. We generally try to follow stable linux kernel versions with our patches added to it. If a patch provider hasn't updated their patches to accomodate for the newest kernel version, it might get slightly delayed. We try to not fall back and are usually in line with the latest stable Fedora kernel release even if it is from the newer Fedora release in the case where we haven't updated to it yet.
Heavily. Nobara is working with "snapshots" of the Fedora repos that are usually synced once or twice a month depending on if we need a newer dependency or if for example a major CVE was made public. This allows us to control versioning if for example a problematic package was found and needs to be reverted etc. Packages shipped from Nobara's copr, like mesa, kernel or other modified ones, are updated ASAP and outside of Fedora ones.
As long as I am alive and using linux this project will continue. It started because I needed something both myself and my father could easily use from clean install without time consuming troubleshooting or extra package and repo installation. As stated in the project goal — while some of us -do- have the technical adept to resolve issues, sometimes we just don’t have the time. Part of the goal is to keep those issues to a minimum.