@boredsquirrel, no.
1 Like
We, the Fedora KDE SIG, are working on the software. That is what this proposal is about and for. This proposal is not about hardware, other than saying we will only be creating images for x86_64 and aarch64.
If Fedora runs on your hardware, great, give this a try. If it doesn’t, then don’t ask us to get it running for you, that is NOT what the proposal is for.
Here is an example of what it will look like
it is possible that some Fedora people might do that. I certainly am not speaking for everyone related to Fedora, but I haven’t heard of anyone trying to do that.
But that is not what the KDE SIG has planned. That is not what this proposal is about.
And yes, I am affiliated with this proposal.
3 Likes
… and with reference to Troy’s comprehensible summary of what this proposal is about and what not, I would like to ask everyone to stay on topic. However, since this is a F41 change proposal topic, I am not sure if there is much more to say about it. You might consider to open new topics.
1 Like
KDE Plasma Mobile Spin
It somehow is waking wrong expectations. A clarification and renaming of the spin would definitely contribute to a better understanding about what it is. Especially after watching the video above I also think
KDE - Mousless / KDE Touch would much better explain what it is for now.
The “mobile” in the name is the culprit of the confusion 
1 Like
Yeah this also confuses me a lot.
Will this simply be a UEFI Fedora version with the correct packages? This could then be consumed by downstreams and made into images that actually work, likely affecting major parts like the boot process a lot.
So it is kinda unclear what the purpose of such a system will be. Test the software on touch computers with normal UEFI? Create an unusable base image purely to enable downstream use (like uBlue, secureblue, wayblue with atomic, and Nobara, Ultramarine with regular)
Did you watch the Video?
@boredsquirrel, yes.
That is its purpose. My LINX 1010B – touch-input, and came with Windows 10 by default, so it’s EFI-based – is an example (or would be, if Fedora actually supported 32-bit EFIs).
I’ve finally managed to brute-force my way through virt-manager-5.0.0-1.fc41’s numerous hurdles, [1] [2] and tried f41 kde-plasma mobile.
Although dnf5 expectedly doesn’t come preinstalled (because it’s an atomic edition), rpm-ostree doesn’t either. In despertion, I actually ran pkcon (I know, I apologise) but that failed to even enumerate available packages via search:
Fatal error: cannot process files of this type
Is my knowledge outdated? How does one perform package management via the CLI on this?
I’m a moron. I was still using the .ISO. Literally forgot to install the OS. 
2 Likes
Live is hard sometimes 
2 Likes
Although pkcon and dnf5 work now (and, of course, plasma-discover --local-filename does too, with appstream:// URIs), [1] rpm-ostree is still at least not in $Env:PATH, despite this image supposedly being based upon Kinoite. What is the preferred CLI package manager for this OS? Is it indeed dnf?
This is an F41 change proposal, it was accepted in July 2024, and we are already at the F41 release. So there is not much more to discuss about it. Please open a new topic.
1 Like