Currently, on non-systemd systems the user is greeted with what looks like a broken Applications view ("$ is unsupported on your system"). Unless it is possible to support the non-systemd case, it would be better to disable the view entirely, because we do get the occasional question about it.
Seems reasonable; in this case we're just torturing the user.
It's not really technically feasible currently though, support is currently determined by the model used for the table, which is deep down in the page structure and isn't really accessible by other parts. Moreover, the page loading code lacks any form of conditional loading, it simply looks at which pages exist and shows those. We'd have to special case stuff for the applications page which gets ugly fast.
Created attachment 146944 [details] screen shot
Comment on attachment 146944 [details] screen shot Get this on a Rocky Linux (KVM/QEMU) VM too... Operating System: Rocky Linux 8.5 KDE Plasma Version: 5.23.3 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.2 Kernel Version: 4.18.0-348.12.2.el8_5.x86_64 (64-bit) Graphics Platform: X11 Processors: 4 × Intel Core Processor (Haswell, no TSX, IBRS) Memory: 7.6 GiB of RAM Graphics Processor: llvmpipe Host: Operating System: Rocky Linux 8.4 KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.5 Kernel Version: 4.18.0-305.25.1.el8_4.x86_64 OS Type: 64-bit Processors: 12 × Intel® Xeon® CPU E5-2620 v3 @ 2.40GHz Memory: 31.1 GiB of RAM
i.e. getting it on a systemd system.
(In reply to Arjen Hiemstra from comment #2) > It's not really technically feasible currently though, support is currently > determined by the model used for the table, which is deep down in the page > structure and isn't really accessible by other parts. Moreover, the page > loading code lacks any form of conditional loading, it simply looks at which > pages exist and shows those. We'd have to special case stuff for the > applications page which gets ugly fast. eh, we had a nice view of applications for 30 years or so, but now its not feasible? I do not mind support for new APIs but it does seem a bit harsh to simply throw out the previous implementation that did what it had to do.