My concept for a fully integrated KDE Plasma operating system

Brainstorm
, ,
1

Hi everyone,

I’ve been developing a conceptual architecture for a deeply integrated Linux system base centered around KDE Plasma. My goal was to think about how to optimize the boot stack, centralize configurations, and solve packaging overhead specifically for the Plasma environment. I’d love to share this specification layout with the community and get your feedback.

Here is the concept document:

My concept for a fully integrated KDE Plasma operating system

KDE Linux Operating System

This Linux-based operating system features full integration with KDE Plasma. Its philosophy focuses on user accessibility and broad hardware compatibility across diverse computing platforms.

Kinit (System Init - Service and System Manager)

Kinit manages system services and interfaces with the OS package manager. The boot process is designed for seamless transitions: it begins with the UEFI manufacturer logo (splash screen), followed by a fade transition to the KDE loading spinner (the characteristic gear icon) accompanied by the text “Plasma, created by KDE [KDE icon]” in the bottom right. Once the initialization is complete, a final fade transition occurs, revealing the cursor to signal the desktop environment is ready.

KPM (KDE Package Manager)

KPM serves as the primary package and application manager for KDE Linux, utilizing the .kpi (KDE Package Installer) format. The manager supports both privileged (sudo) and non-privileged execution depending on the target installation path:

  • User-level Installation: Applications can be installed in a user-specific sandbox (e.g., ~/.local/kpm/sandbox). This provides a virtualized root filesystem where packages cannot make permanent changes to the host system. To optimize disk space and avoid the overhead of Snap or Flatpak, the sandbox is shared among all user-installed applications to leverage existing dependencies.
  • System-level Installation (sudo): Packages are installed globally, enabling universal access for all users and permitting permanent system modifications.

KPM features intelligent dependency resolution: if a dependency is currently installed in a user sandbox but is required for a global installation, KPM will migrate the dependency to the system base to ensure global availability.

.kpi (KDE Package Installer) Internal Structure

  • Metadata (metadata.krc): A lightweight configuration file that specifies required permissions, application name, icon, and dependencies for kinit and KPM.
  • Binaries and Resources: The executable binaries and associated assets of the application.

Emergency Mode

To ensure an indestructible system base, KPM includes an atomic rollback mechanism. If a global installation via sudo corrupts a system library, the change can be reverted to the previous stable state using a single command or via the Discover software center.

KDE System Preferences

The system provides centralized management of nearly all core components through the Preferences application, including boot configuration, comprehensive driver management, hardware diagnostics, system maintenance, and sudo administration, delivered via a clean and lightweight interface.

Kash (Terminal Prompt)

Kash is a fork of the fish shell, deeply integrated into the OS. It implements safety guards to prevent accidental system corruption; for instance, critical commands like rm targeting the system root or essential files are blocked by default. These protections can be managed through KDE System Settings.

Pre-configured Linux Kernel

The Linux kernel is pre-modified and optimized for tighter integration with the boot stack and kinit, ensuring more efficient driver and module management.

Enhanced Desktop Environment

While based on KDE Plasma, the environment is further refined and integrated for deeper system cohesion.

Live ISO and Installation

KDE Linux utilizes a modified Calamares installer, optimized for immediate bootability post-installation. Upon first boot, a KDE Welcome screen guides the user through account creation (username/password) and initial system preferences.

The rest is up to the KDE team. It is highly recommended that the Linux system be a rolling release with user repositories to minimize headaches for many users. I hope this idea is taken seriously and that they can move forward with it.

2

Indeed, I wonder why they didn’t think of this before.

3

What you describing look like in certain points to KDE Linux.

As for the remaining points there is some explaination to it :

Your tied init system, package manager and shell concepts looks good on paper but there are not ideal if we want peoples to enjoy KDE on other Distros. Doing this also dupplicate what allready works and will certainly take lots of times and effort to get something nearly as good as the mainstream alternative. I think we should rather improve and nudge things (systemd, flatpak, zsh…) to have the things we want than creating yet another alterative and make Linux as an platforme more complicated that it is.

In the other hand I like some of the proposals :

Being able to recover from brocken update/system operation seem to be more than welcome.

Having a user proof shell could be great and could be achieved with a config file.

Update : reliable system rollback is something being worked on KDE Linux

3 Likes
4

Personally, I experienced cognitive dissonance when reading it…

For example:

Enhanced Desktop Environment
While based on KDE Plasma, the environment is further refined and integrated for deeper system cohesion.

This reads like pure, meaningless, AI ‘visionary’ stuff… it sucks harder than the millions of daily slop uploads to Youtube.

  • Deeply integrated

  • seamless transitions

  • enhanced for tighter cohesion

  • It thinks ‘kinit’ - our NEW INIT system handles a boot splash (UEFI) and a spinner - that’s what Plymouth did before I installed it (to improve my system).

  • How can you have a “Shared Sandbox”

  • You CANNOT allow a USER to permanently alter the immutable root filesystem…

Also, the fact that this user specifically signed up to the forum to post this - I’m wondering if there really is anyone there at all!

1 Like
5

Thanks for the input. Just to clear a few things up:

This was meant as a ‘flagship OS’ concept, not a plan to break Plasma’s modularity on other distros.

For KPM, the ‘shared sandbox’ actually uses hardlinks to a central cache, so the system base stays completely immutable while saving space. And about kinit, the idea was handling the transitions at the lowest level possible to avoid the typical screen flickering you get with standard user-space tools.

In the end, I just wanted to share these ideas for an OS that can be used quickly and efficiently. Even though I respect KDE’s philosophy, I want them to build the future and help the people who need it. Glad to hear the official KDE Linux is working on atomic rollbacks though, that’s awesome.

6

The thing is, I’m not an AI.

Look, 2 + 2 is 5.

See? XD

7

Ok, it seems you’re running KDE Plasma under different circumstances to me - I have no experience of ‘typical screen flickering’.

8

Totally agree with this, exept for one thing: I believe fish is a much better choice as default shell. I’ve been using zsh for … maybe 18 years or so? Then I switched to fish and am really happy with it. Mostly because it comes with good defaults and doesn’t require me to study manpages for 12 hours to change something in it’s config. Also I’m not sure if we even need to alter fish itself for KDE-Integration - reconfiguring it might be enough.

9

I’m not eating enought of terminal commands to agree or disagree with you :sweat_smile:

10

You don’t have to.

Fish isn’t a posix shell, it breaks many things.

Previously I used bash, then zsh - and ended up with a very nice zsh config…

Now I have fish in my terminal, but it’s not the default for the session because a lot of things just don’t work.

This is something that only more advanced users can deal with, but the idea for this ‘AI Slop Dream’ is not only to use fish, but also to FORK it to make it idiot proof.

Honestly, that’s a bit of a joke… and demonstrates that the writer of the whole idea hasn’t got a clue what the Fork they’re talking about.

11

What does it break? I mean… sure, scripts need to be rewritten, but in those you can always use a shebang for compatibility.

12

It’s not reasonable to say ‘rewrite’ - this means you must supply patched forks of every package that touches /etc/profile.d/ - a perpetual and unbounded maintenance task.

You must then force the entire open-source ecosystem to do the same…

Documentation, install guides, troubleshooting steps always assume POSIX, usually bash or sh.

By all means set your default terminal to use Fish, but FFS don’t suggest the entire system shell be some weird fork of fish.

fish is a much better choice as default shell from someone who has used zsh for maybe 18 years or so.

My spidey senses again twitching here.

  • I used zsh for 18 years is not an argument for Fish being a better default. It’s a point scoring comment - a kind of show of power, like people who suggest they must be clever because ‘I use Arch btw’. I personally know people who used Linux for less than half the time than I did, who know more than ten times more about almost every aspect.

I remember using ZSH for a few years, understanding that a LOT of infrastructure depends on POSIX/Bash semantics.

But as with many arguments in here, many arguments are based only on very narrow personal use-cases… conflating “better for my personal interactive typing” with “a better shell for every user in every context”.

You don’t choose a default shell for autocomplete, or syntax highlighting, those are extras, niceties (and why I use fish in my Kitty terminal).

A truly experienced user starts using ZSH probably goes through an ‘oh my zsh’ phase, then removes that and implements those things manually… refines zsh.

In the end, ZSH can easily provide 90% of the nice features of FISH.

You can’t rewrite /etc/profile/.d/* because that’s not yours to rewrite.

13

I don’t think coming up with ideas is the main bottleneck in building the future. Developer time to implement ideas and see what works and what doesn’t is more of a bottleneck. Wanting other people to do things is not as effective as actually doing things.

3 Likes
14

You can completely reduce this idea to a few lines in a more human-sounding way. Either this was parsed through an LLM or it is deliberately buzzwordy. Avoid expressions like “fully/deeply/tightly integrated”, “refined”, “deeper system cohesion”, they don’t actually mean anything by themselves.

I’m thinking of a KDE OS focused on accessibility and hardware compatibility. It must include:

  • a custom KDE init for branding purposes
  • a sandboxed package manager that can install to rootspace or userspace and be moved from one to the other
  • uses .kpi package format and must include metadata and application-related files
  • an emergency mode
  • KDE system settings
  • a default shell forked from fish to hinder users from shooting themselves in the foot
  • an optimized kernel
  • custom modifications for usability
  • live ISO using custom-modified Calamares
  • welcome screen

What do you think?

If you remove the meaningless fluff it gets much shorter:

I’m thinking of a KDE OS focused on accessibility and hardware compatibility (that’s already the case). It must include:

  • a custom KDE init for branding purposes (XKCD 927, you don’t need a new init to do that)
  • a sandboxed package manager that can install to rootspace or userspace and be moved from one to the other
  • uses .kpi binary package format and must include metadata and application-related files (that’s literally how every binary package works)
  • an emergency mode (already exists)
  • KDE system settings (already exists)
  • a default shell forked from fish to hinder users from shooting themselves in the foot (you can do all that without a custom shell)
  • an optimized kernel (without answering “for?” it’s not useful)
  • custom modifications for usability (doesn’t mean anything unless you specify actually constructive beneficial modifications instead of buzzwords, even so improvements should just go upstream first)
  • live ISO using custom-modified Calamares (calamares is already configurable by default, and why would you not have a live ISO unless you’re still in alpha and haven’t made it yet)
  • welcome screen (already exists)

What do you think?

You want to make a distro with your own sandboxed packaging format, pretty much.

5 Likes
15

Nix on KDE Linux might be worth looking at.

16

Live ISO is available as of yesterday! :smiley:

(In practice, the previous .raw file was also easy enough to write onto a USB stick to make a live/installer device.)

1 Like
17

Intergrated cohesion, yes.

A user can change their own fish shell; what they are talking about is warp, or something like it. Most of those things are in the labs or not widely known.

The custom package format would be great for saving setting/“rciing”.

The post was very likely written by someone who does not code or is not familiar with the “codebase”.

1 Like
18

zsh isn’t, either. It probably breaks fewer, but still does. Your distro needs to ship separate profile.d files for bash and zsh.

That said, I don’t think we need fish as the default shell. Anyone cares enough should be able to change the default by himself.

1 Like
19

Neither Microsoft nor Apple has been good on this in recent years. So I doubt KDE, with much less resource, should waste time on all these little details instead of making it more useful.

The brutal fact is that Chrome, Firefox or Steam will never be very “integrated” to the desktop environment. To most users, they are more important than the DE. They will look and work however they want.

(Of course, anyone can spend his own time improving on anything he cares.)

20

Ok… I see your point about rewriting stuff in /etc/profile.d/. Right now I have several scripts there and I don’t think any of them are incompatible with fish (it is partially POSIX compatible after all..), but it’s clearly possible there could be problems with some packages when using fish. I’m not sure whether this is a serious problem though, but that may be due to a lack of understanding of all the components involved.

My spidey senses again twitching here. (about 18 years of using zsh)

And rightfully so! :wink:

I only wanted to speak from personal experience. The actual reason why I believe that fish is a better default is that it has better defaults and is far easier to customize. I also find the syntax less unintuitive.

Documentation, install guides, troubleshooting steps always assume POSIX, usually bash or sh.

true, but the vast majority are just commands, possibly with pipes, which should still work with fish. The rest are scripts which should contain a shebang and therefore use a different shell.

To me, keeping zsh as default for new users because it is POSIX compatible feels like the typewriter/keyboard trap all over again, where something clearly better is available, but the old stuff is practically forced on all new users because the world has gotten accustomed to it :frowning:

Although… now that I think about it, maybe the long-term right thing to do would be to skip fish and make something like nushell the new default…