Jump to content

KDE Linux/Obstsalat

From KDE Community Wiki
< KDE Linux
Revision as of 14:28, 8 October 2025 by Sitter (talk | contribs)

This is the Obstsalat (fruit salad 🍇🍈🍉🍊...). They are facets of the 🍌 experience; brainstorming ideas to take it to the next level. The OS is just part of the story.

Plasma Wayland Experience

( remote desktop story. easy sharing. convertible story)

  • remote desktop by token or by auto-connect-share-url
  • nearby sharing: via kdeconnect?
  • should sharing and remote desktop be the same thing from a UX perspective?
  • session restore. rebooting needs to be a breeze because users restart a lot for updates
  • detect when kwin is no longer responsive due to load and offer a way out of it
  • detect when memory is being hogged and offer a way out of it (notification "yo this is using lots of ram, how about we kill it")
  • "integrity" check for desktop environment components: detect when an important process (e.g. portals, kded, powerdevil, ksystemstats) is missing because of a crash, attempt to recover
  • backups: dolphin integration to roll back files
  • dolphin integration shebang for google and office365 and nextcloud --- ensure we have companies in the KDE surrounding that can make sure these things are well maintained (i.e. foster a healthy eco system of KDE adjacent companies)
  • make people see that their software product is of crucial importance and must be well maintained (bug triage, forum support, MR commenting)
  • input methods installed. fcitx, ibus, maliit, qvk

Atomic OS

  • binary diff sysupdates need creating -- zsync?
  • encryption: verity subvolume on btrfs?? figure out a good story that requires a single auth even with encryption
  • developer story using sysext needs figuring out and documenting. Check out https://gitlab.gnome.org/tchx84/sysext-utils Might just be what we need to make things more accessible
  • switching editions via updates kcm and maybe the sources list in discover

Adoption story

  • windows and osx story needs polishing
  • make sure isoimagewriter is a nice tool to use
  • explore having branded usb sticks to deliver to community members and in conferences
  • talk to hardware vendors
  • ARM/RISC-V images?

Sandbox

  • plasmoids: see to how to list them and spawn the process. Integrate it into the UI
  • apps: flatpak and snap
  • KIO: needs thinking. make a daemon let it spawn workers
  • anything else: sysext / toolbox for now, should minimize the rest
  • Explore systemd-homed

Quality

  • Automatic QA (openqa? Selenium? quicktest?)
  • Human QA tracking (test case management of some sort)
  • Health reporting into Sentry to identify bad releases
  • Support sending non-KDE crashes to Sentry
  • collect some sort of perf data on app start ups and stuff and evaluate that somewhere and somehow

Recoverability / "never dead"

  • a/b guards against some breakage
  • recovery mode for breakage outside a/b
  • recover user data mounts all stuff
  • backup list of installed apps
  • maybe do a full system backup by default
  • Plasma/SafeMode

Security

  • Secure Boot
  • CVE/security updates: there is an atom feed of fixes
  • firewall?
  • anti virus?

Compliance Certification

Developer Experience

  • centralized management story to keep in mind // monitoring: hook into systemd
  • eco system of companies to provide support -- ticketing system
  • apple: no. banana!
  • virt-manager flatpak -- maybe write a kirigami kvm client (there is https://invent.kde.org/arraybolt/karton)

Building it

  • Better kde-builder dependency definitions
  • kde-builder to build release tags

documentation story / access / reading

  • khelpcenter. is it any good?
  • khelpcenter. how to make it access flatpaks?
  • what do we need to ship?
  • are the docs any good at all?
  • we'd like online docs
  • but docs.kde.org is outdated and nonfunctional. fix it!

Data Migration

  • Types of data:
    • app data (email, contacts)
    • user data (documents, downloads)
    • config data
  • Needs to be top notch quality
  • have iso image writer inform the user how to migrate data, or where to get a useful device.

New Universal Packaging Format

All the supposed next-gen packaging offer some advantages over traditional distro packaging, but also have limitations:

Flatpak

Pros:

  • Developer-targetable runtimes make it an actual platform
  • Sandboxing for safety
  • Can safely install multiple versions of the same package, roll back, etc

Cons:

Snap

Pros:

  • Developer-targetable base runtimes ("base snaps") make it an actual platform
  • Can safely install multiple versions of the same package, roll back, etc
  • Sandboxing is optional; can use it purely as a packaging format and therefore package system software
  • Traditional short CLI binaries

Cons:

  • Tied to Canonical's snap store, which is not open-source
  • Sandboxing model requires AppArmor with custom patches that the kernel folks will never accept
  • Runtimes are a whole mini OS that duplicates what's on the base system

AppImage

Pros:

  • Clickable/double-clickable self-contained bundle; easy to move around and delete
  • Can safely install multiple versions of the same package, roll back, etc

Cons:

  • Anti-XDG opinions
  • No concept of explicit dependencies; actual system dependencies for each app are implicit and there's no way to ensure they're present
  • Targeting old tooling and library versions means AppImages can silently break on systems with newer tooling and library versions
  • No provision for being updated using any system services like Discover
  • Packages are a most of a mini OS that duplicates what's on the base system
  • No shared dependencies between each app

Something better

What would we want in something that's better than all of them?

  • Developer-targetable runtimes make it an actual platform
  • Can safely install multiple versions of the same package, roll back, etc
  • Sandboxing is decoupled and optional; can use it purely as a packaging format and therefore package system software like Plasma, KWin, plasma-login, etc… the sandboxing mechanism can be part of the runtime platform and apply regardless of how the software is delivered
  • Software installed via another way can make use of libraries in the runtimes
  • Clickable/double-clickable self-contained bundle; easy to move around and delete. All necessary system integration files (e.g. desktop file, appdata file, etc) live in the bundle
  • CLI binaries are writable, and don't use awkward rDNS style syntax
Retrieved from "https://community.kde.org/index.php?title=KDE_Linux/Obstsalat&oldid=104923"