How should programs without GUI be published/installed for KDE Linux

KDE-Linux does only come with flatpak and not with pacman, but flathub doesn’t allow console software. How am I excepted to publish or install service/server software then?

My concrete case is GNS3. GNS3 is split into the GNS3 Client and Server. A majority of user runs the server on their PC instead of a remote server and therefore the local server is very integrated into the software.

How are you supposed to deal with this?

Hello,

You can try your luck with solutions such as Distrobox, Kapsule, or Toolbox. Those have worked for me in the past for installing basic command line utilities and even some apps. Might work for you. Worth checking out.

Good news specifically for the GNS3 server, it can be deployed in a Docker container, and you can use Docker in KDE Linux (there’s also Podman and Incus available for containers):

If you’re feeling adventurous, even if there’s no modules in the Python system installation, you can create a venv in which you’ll have pip and the possibility to install what’s needed to run it:

For client CLI app purposes, then as Trog said, you can check out Distobox, Toolbox or Kapsule.

Running the server in docker might be a way, but I’m looking to contribute to GNS3, as they do have a fantastic piece of software, so I’m not looking into some sort of hacky way.

This is exactly what Sysext is for. KDE Linux even comes with a utility that takes the dredge out of setting an extension up.

Run set-up-systemd-extension as a regular user and it will set up an environment in your $HOME which you can use to extend the /usr folder—i.e. somewhere where you can install your console software.

So I might be a little confused here.
I thought the goal for KDE Linux is to be as user friendly for “normal” users as possible.

With GNS3 on Kubuntu I just installed the gns3-gui and gns3-server from their APT repository and every time I started the GUI is server is launched in the background and stopped when the GUI is stopped. So no systemd service when it’s running fully locally.

If I understand the usage of systemd-sysext correctly, the user needs to setup the extension over the terminal by hand?
That would be in my view a step backwards in terms of user friendliness.
Or is there a way my flatpak can install and control the extension?

I already “broke” the sandbox, because the GNS3-GUI needs to spawn a Wireshark and terminal emulators.

FYI

I currently have the following ways identified:

  • Bundle it with the client?
    Downside: Makes the sandbox obsolete, as the server needs extensive permissions
  • Run Server as a docker container?
    Open Questions: Existing image? Installation process?
  • Ask the Flathub folks to make an exception and ship the Server as standalone Flatpak?
    Downside: Makes the sandbox obsolete, as the server needs extensive permissions
  • Only allow remote servers
    Downside: Losing one great feature
  • systemd-sysext
    Downside: Installation process
  • flatpak extension
    Downside: Makes the sandbox obsolete, as the server needs extensive permissions

I’m not looking for a concrete statement for every one of them. Just so you now where I come from.

I guess people like you and I are not considered “normal” users! :grinning_face:

Joke aside, the “user-friendliness” of KDE Linux is apparently focused on “average” PC users, whose overwhelming majority currently use Windows (and MacOS).

For “advanced” users, there’s sysext, which apparently creates a layer of Linux environment that can be used as we use any “user-friendly” Linux distro (Arch-based ones, in particular).

The tricky part is perhaps the “average Linux user” group, falling in between the two groups above.

Perhaps, all we need is to start learning and mastering that thing called sysext, and perhaps KDE Linux developers (or somebody else) can make it a little bit more “user-friendly”.

Or perhaps, we should accept that KDE Linux is not particularly for this particular user group, and it resembles MacOS very much in that respect, where some “advanced” users and especially developers can do all sorts of things using terminal etc. - an area which its “normal” users are not even aware of.

Personally, I’ll try sysext first, and if I find it unsuitable for me, instead of switching to KDE Linux, I’ll stick with my current distro choice, Debian Testing, which I’ve concluded to be the most suitable distro for me to enjoy KDE Plasma, after so many disappointments with KDE neon, Kubuntu, Arch Linux, OpenSUSE etc. over the years.

There is some truth in your words, but I’m not creating a flatpak just for myself. It doesn’t matter which distro I’m choosing. The user should not be limited by his choice of distro. With that said maybe systemd-sysext isn’t a great choice at all, maybe for KDE Linux, which I choosed to test on, because it’s bleeding edge and allows no shortcuts.

I think it’s okay to expect the user to use a distro with systemd-sysext (I’m no systemd hater).

I’m still not sure which way to go and maybe I’m offtopic by now, but I’m happy for every input.

Maybe I want to much. Maybe something on the GNS3 side has to change.
But maybe, there is the best solution…

What @Sadi said, plus KDE Linux is ALPHA software . Not only there are going to be bugs, there are also going to be missing features. You can talk directly to the devs and explain your ideas.

Plus plus if as a power user you are not comfortable using sytemd, KDE Linux is definitely not the distro for you. systemd is everywhere in KDE Linux.

Plus plus plus KDE Linux is not meant to take the place of any other distro. There is still Fedora, Arch, CahyOS, Bazzite, Alma, openSUSE and many more distros with KDE devs working on them and that have excellent implementations of Plasma.

KDE Linux is for quite a specific audience and will not satisfy every user’s needs.