Installed and run KDE-Linux, works great, but

Help
1

So I finally manage to install and run the new KDE Linux. Before I tried it on a spare partition (34Gb) using manual partitionning in the installer, the install seems to work but it would not start. I supposed it was due to multiboot with rEFInd but it was not the problem. Then, I used another partition (100Gb) and choose the “Replace a partition” in the installer and the install proceed and boot without a problem. It would be good to document that, I don’t know if 34G was not enough or if the manual partionning was the problem.

Now that my KDE-Linux is up and runing I tried to understand how to manage it. I have little to no experience with immutable system, apart from using Magisk’s module ovelay on Android, and looking a bit at Nix (but I gave up and went back). I understand that the system is not based on package manager, that flatpak/snap/Appimage is used for your GUI apps. I think I get the overlay principle (on top of RO /usr and all). For developpement I see that you use systemd-sysext, and I have setup ~/kde for extensions as per the wiki.
I understand that it is a new approch than need some chang in habits but I am not sure to really understand how to manage my system, in particular how to install programs other than those avaible on flatpak and all or is it the only supported way to do. Here some use case:

  • I use neovim and I compiled It with DESTDIR=~/kde so I have it trough systemd-sysext, is it the way for those app (flatpak’s neovim seems not adapted just for an editor)
  • On other system I install a very useful tool for keyboard/layout remapping (with layer and other good stuff) called keyd it work at udev level. Am I supposed to compile it with DESTDIR=~/kde or maybe is it just not supported?
  • the config of keyd goes into /etc, It is writable, right?
  • by default man is not installed how I get it ?
  • Am I supposed to compile every libs and apps I could need (if not provided by flatpaks)?

Sorry for those really noobs question, I use linux for quite some time but I am a little lost with this new approch. I want to try it as it seems the future for linux system (KDE Linux is deemed to replace Neon right?) and provide interresting benefit. On the KDE Linux I know that it’s alpha, I just want to test it in parallel to other working install.
I am under the impression that there is something I don’t get, if someone can put me in the right direction, that would be awesome. Thanks in advance.

1 Like
2

Another 24 in a dozen linux “distro”. And an extremely niche one for that matter. Hardly documented. I doubt there are many using this, or even considering it. But…it’s your rig and maybe someone can help you with the blanks. Come to think of it, I believe there’s one user here that uses project banana.

3

@alioth9:

The openSUSE Aeon immutable (currently Beta project phase) Desktop distribution has some documentation that may, or may not, help you: <Portal:Aeon>

  • But, beware – Aeon is GNOME …

The KDE variant – “Kalpa” – is currently in the Alpha project phase – <Portal:Kalpa>.

4

i thought the whole point of an immutable distro is that you can not install native packages to it… it’s rather fixed that way.

the only apps you can run on it are the one’s available as flatpak, snap, etc.

if that library doesn’t suit you, then an immutable distro is not what you want.

https://www.howtogeek.com/what-is-an-immutable-linux-distro/

am i missing something?

Installing software also doesn’t work the same as using traditional package managers. If you want to install apps not available as Flatpaks or other universal formats, you need to install a whole new distro in a container just to use a single app. That doesn’t sound so good.

5

Hi - I think that may be the catch here, KDE Linux is not in an Alpha state for general testing. You can take a look at the milestones, and the tasks on the path to each one, on the KDE Invent site here: Milestones · KDE Linux / KDE Linux · GitLab

If you’re interested in participating in the design, development and testing of the process to build the OS - awesome! The folks working on all of that are using the Matrix chat room #kde-linux:kde.org as a place for real-time discussion of ongoing work, and GitLab Issues for asynchronous tracking of to-do items.

6

Thanks you for all the responses.
For the fact that it is alpha I do know that and I neither expect it to be ready for general testing nor do I expect someone comming to help fix every problem I could encounter. Unfortunately I am not dev and I could not help with that.
The thing I ask is more to help me (and probably others) understand how this new approch is supposed to work (even if currently it is not ready for KDE Linux). If the goal is to have a system absolutly unmodifiable where you could only use flatpak/snap/Appimage, ok then.

But, It is advertise as a replacement for KDE Neon including for enthusiast and developpers (for KDE in particular). I could not imagine dev not wanting to tinker theyre system to work as they want (using theyre prefered editor or ide , prefered terminal and all ). For example I prefer Kitty (or foot) as terminal emulator and I install it to ~/.local but Konsole is installed trough flatpak and could not grab some zsh plugin if (if installed through overlay).

For example how you install all the cli tools for administartion (btop, ranger, evtest, meson.) if not installed by default into the image.
I was more asking to users of immutable distro ( Kinoite for exemple) or even people who already tried KDE Linux for theyre enlightemnent.

7

I think that what I had imagined was more close to nix with an immutable core system with a layer that still use package, or something, to install tools on top of it (as an overlay) and then flatpak for youre usual big software and kde component (krita, libreoffice, calligra, etc). The core providing a rock solid base and that if any problem appear it was just a matter of removing a directory of the ovelay to get back the base layer who is sure to boot and run . Nix for example is a package manager system, so maybe something between nix and Aeon/Kalpa (wich only propose flatpak as it seems).

8

I think you’re pretty much there - here’s my understanding of the general concept:

  • Core operating system components are based on tested and deployed images, rather than assembled ad-hoc from thousands of individual “packages” on each user’s machine
  • Developers use some combination of built-in tools and container solutions for build environments
  • End user applications are obtained through their own containerized methods (like Flatpak) that can be kept up-to-date without worrying about the underlying system

The folks working on KDE Linux in particular are working through the architecture, and then the guidance for developers and users, on the technologies to be used and how to use them to accomplish that end goal, since as you mentioned there are multiple ways to approach the overall concept (Fedora Atomic and its images+layering, openSUSE Aeon and its Btrfs snapshots+distrobox, etc.).

9

It’s true that it might sound like Milton Friedman in a jailbreaking style, advertisingly without a jail.

The “External resources” section at KDE Linux - KDE Community Wiki has two articles along with the slides and video of the presentation at the last KDE Akademy event.

Maybe in a possible future, progress comes in a form of hybrid solution: the immutability of image-based systems becomes cryptographically toggle-able, and therefore “image-based” can be considered a better term than “immutable”; systemd ups its millions of lines of code a tad bit more and offers an incremental upgrade option in systemd-sysupdate; and bubblewrap, ostree, flatpak, systemd, and linux can live together happily ever after.

The point in this may be more containerization than immutability, where immutability becomes a byproduct after removing the package support, in which case an existing packaging infrastructure can be considered like a part of a built system for operating system images I guess. Therefore, Flatpak and similar distribution-independent package management technologies using OS-level virtualization are the main point of all this I guess. They essentially dissociate the processes from the operating system, where each containerized process runs in a separate root file system and use portals to have access to the rest of the system resources, as a result of which the system may become less of a system and more of a platform to be honest with you :]

I don’t have any Flatpak applications. But it looks like Flatpak is mainly built on Bubblewrap, which is a low-level unprivileged sandboxing utility, and OSTree (a.k.a. libostree), which is a version control system for atomic operating system updates and is similar to the Git version control system, although Flatpak uses OSTree to track local Flatpak repositories where Flatpak packages are installed, and to check out particular versions of the installed packages, which OSTree does by creating hard links to the files installed by packages in the checkout directories outside the repositories the packages were first installed in. Flatpak packages are downloaded from a remote Flatpak repository, such as Flathub, rather than a remote repository for a particular distribution, and installed in a system-wide or user-specific local OSTree repository, which are in the /var/lib/flatpak/repo and ~/.local/share/flatpak/repo directories respectively by default, where each installed Flatpak package is a branch in the repository, and each system-wide and user-specific Flatpak application is checked out in a directory under the /var/lib/flatpak/app and ~/.local/share/flatpak/app directories respectively by creating hard links to the application’s files, including the shared runtime libraries that the application depends on, in that directory, which were originally installed in a system-wide or user-specific Flatpak repository. Multiple application directories under the /var/lib/flatpak/app and ~/.local/share/flatpak/app directories may contain hardlinks to the same runtime libraries in the local Flatpak repository since Flatpak applications share runtimes. For example, a Flatpak application that is installed system-wide has a directory under the /var/lib/flatpak/app directory, which contains the hardlinks created after downloading and installing the application to the system-wide local Flatpak repository in the /var/lib/flatpak/repo directory.

So, it seems like schedulable entities in linux are getting larger from processes to control groups, memory images are getting larger from process images to ostree branches, maybe even the space is getting larger for more root file systems hehe It seems the trend is getting larger, literally :confused:

1 Like
10

Thanks for the long and detailed answer.
On a side note I wouldn’t take Milton Friedman as a example for freedom, he has little problem with Pinochet’s jails in Chile for example.

For the technical aspect I have seen also critic for the “immutable” name with some calling it more of a layer system which as I understand it converge with the idea of a hybrid system or platform as you call it. I use some flatpak with the difference between user and system wide flatpak install but I didn’t look much into the details. It is indeed a new approch to the system.
On a practical point, flatpak are also more ressource hungry. For example Flatpak’s Emacs start in more than 5s when it is 1.5s for the repo version on an Arch system on the same machine.

There are, if I understand it correctly, different approch to immutable system or base on an immutable core. KDE Linux drop the use of package management and rely on some OS-level virtualization through flatpak/snap/Appimage and also distrobox. But there is also NixOS that rely on a package manager with all the package one can dream of. The immutable core is not really a problem for me, and I see and am interrested with the advantage it brings. I wish, though, there could be way to keep some of the advantage of the linux package system: discoverability, adaptibility and all. Flatpak/Snap/Appimage partly provide it and maybe it is a matter of more programs being brought to Flatpak.
I think though there is room for a layer in between for small programs and tinkering on top of the immutable base. I was seeing it through the overlay system between the immutable core and the Flatpak. Maybe it breaks the purpose of those system/platform and it is a distort of the intended usage of for example systemd-ext, which is advertise for developpement. But it is the way I would see a hybrid system with different layer for different purpose without removing the possibility of tinkering and customizing and using the wide possibility of linux programs. I have no experience with it but MacOS is an immutable and you still have homebrew.

1 Like
11

Indeed one would have a hard time considering Friedman as an example of freedom as in free.

The compute overhead of containerized applications is negligible at runtime, and loading will only get less noticeable. Flatpak also does deduplication in its repositories so the more Flatpak applications the user installs the less space Flatpak wastes compared to the native packages of distributions. And, it has a plain clear interface. It just creates a parallel universe, and opens the way for various payment methods, all the while bringing extra security measures with it.

I’ve heard of MacOS. Somewhat large part of their codebase even has a free software license, which I understand excludes the parts where what you see is what you get (and the drivers). I don’t think MacOS is image based despite having a degree of immutability for the part of their root file system where they store executables and libraries, and therefore their package manager probably just takes the seal off by changing permissions and/or some privilege escalation mechanism, puts the files in, and seals the tree back on.

I guess it’s been about 40-50 years (?) since the distinction between the root-level directories (e.g. /bin, /sbin, /lib, etc.) and their counterparts in the /usr directory (e.g. /usr/bin, /usr/sbin, /usr/lib, etc.) isn’t valid anymore, and so they were merged, which was originally due to very limited storage spaces in the early days of computing, although /usr is still preferably called “user” instead of “Unix system resources” or “unified system resources”. And after that, the distinction between the /usr/bin and /usr/sbin directories wasn’t practical anymore either, due to the user substitution and privilege escalation mechanisms that are normally used on all systems now, and the increased set of functionalities of modern programs that can be used by both normal users and system administrators, and so some distributions have already marged them, and some haven’t yet but about to, apparently. Applications’ having separate root file systems is not necessarily the same thing as having application-specific file hierarchy standards :] Come to think of it, there is no reason for containerized applications to be ABI-independent unless maybe gaming is considered to be the core aspect of it.

So, I think the distinction between package-based and image-based distributions, as well as the distinction between an operating system’s native processes and containerized processes, will be valid and sound for conventional computer systems unless the desktop environments replace distributions (or something), although the non-profit character thereof may diminish by isolating the programs that run on an operating system unless a better understanding of the system and how to use it is obtained by larger groups of people.

2 Likes
12

just gonna say THANKS for all those links and info.
I’m really lookin forward to KDE Linux. The early distros were necessary evolutionary steps. But it will be SO COOL to have things done more properly.

13

40-50 years is not true, rather around 2010 and mostly because of systemd, and they have their use in server systems, in the BSDs, etc. Iirc Debian only recently (~3-4 years) merged them.

1 Like
14

The time period when the distinction wasn’t valid was when the storage technology wasn’t advanced enough in the early days of computing so that the operating system’s internal files (i.e. internal executables, libraries, etc.) had to be stored in one drive that had the root-level directories and the operating system’s public files (i.e. public executables, libraries, etc., which were referred to as user files) had to be stored in another drive that had the /usr directory. Drives that had large enough capacity for an entire root file system must have become practical, and widely available, quickly in those early times as has been the trend with computer stuff in general. Conventions change much more slowly, and normative references like specifications and standards even more slowly. When it comes to the proper ways to do things, and the proper ways to decide on them, one suggestion is making the leap of faith, properly :]

1 Like
15

How about Manjaro?
It has many friends and is based on Arch Linux.
I personally use Arch pure, but I receive many tipps and solutions by the Manjaro community and Reddit as well.

16

I already use Endeavour OS (Arch based closer to main Arch).
Maybe I am not clear but It is not about finding a distro that work or whatever. I installed KDE Linux for testing, very much knowing there would be bug and caveat. I wanted to test this new approch, sometime advertise as the future for linux system (on personal computer). It is about this old curiosity in free and open software. I want to undertand its merits, limits, and the underliing mecanic (to some extent).

Beside, on my main machine I use Tuxedo OS (since it is a Tuxedo :wink: ) which is based on KDE Neon, and KDE Linux, if I undestand it right, is supposed to replace Neon.

Among the advantage of the immutable system is the promiss of smooth upgrade and a rock solid system. You then are basically asure to be able to log in to your system or easily revert to a previous state where you can carry on.

17

I think you’re falling under the issue being discussed in How can we ensure sufficient flexibility for enthusiasts and developers? (#12) · Issues · KDE Linux / KDE Linux · GitLab. Personally I’m in favor of recommending brew (and pre-installing) as our officially blessed userspace CLI package manager. But that’s still an open topic.

As noted, this distro is pre-alpha, in heavy development and with critical components still changing on a regular basis, but also with corresponding ability to have an early impact on its direction. I’d only recommend using it if that description sounds like fun to you. :slight_smile:

1 Like
18

First thanks to take the time of answering and Yes it’s sound like fun to me ;-). I have already learn a lot and exploration/tinkering/learning is one of my attraction to Linux/FOSS. Also thanks a lot for the good work, recently see resolution of the local error who resolve a bunch of issues.

It is interesting that you mentioned brew because I was considering it (without prior experience of it) but read some critic, in part about security (/usr/local becoming writable without root access and basically program install without as user). So I went another way: it is hacky and not as intended, and certainly It could fail at some point but I bootstrap pacman into a systymd-sysext extension directory like ~/kde that act as overlay on /usr (using guide in KDE Linux - KDE Community Wiki ) . I then can install package with sudo pacman -S <package> -r ~/kde. I see it like brew but based on pacman which as a comforting aspect of it (I generally use Debian based distro but start to like Arch-based and pacman). One (big ) advantage for me is that if anything goes wrong I just could unmerge the extension or mv or rm and start over.
When I came with this “solution” pacman was preinstalled then not (was a little surprised). I can see that it somewhat works now because right KDE Linux is based on Arch which can change. Maybe it is a bad use of systemd-sysext (no prior experience of it).

If you have the time/interrest here some question/observation/bug I have

  • I wonder what is the reach of the immutable base: when you remove pacman config in /etc was too and it make me wonder if it is expected that config in /etc could change anytime (was considering using systemd-confext), also for /var and /opt?

  • Maybe a list of wath is out of scope for configuring, for exemple some of what I have: sddm.conf/sddm.con.d, pacman stuff, crypttab(is boot/initrd configurable and what is used)

  • on the boot config, what is used? I have some config, I wonder if I put it in /etc/crypttab or /etc/mkinitcpio-systemd-tool: I am more use to Debian config version and drakut on Arch.

  • Flatpaks by default don’t follow user general config, theme (even dark/light), I have tried giving more permission/access to those app in systemsettings but it seems not enough, I will look more further but I wonder with is the goal for the default in future. Will it need some manual config (a good step by step specific guide would be useful) or will we loose on integration. For exemple I have a config for dolphin that I usually copy to ~/.local/share/kxmlgui5/ (cf konsave). With flatpak I wonder if I am supposed to redo it by hand or maybe copy it to a flatpak specific folder. Same with the usual theming things

  • I have tried distrobox but encounter an error about /etc/localtime I suppose it is a known bug ?

  • Also I can’t make maliit-keyboard to work.

  • I have seen some remarks about packaging some cli app to flatpaks but: they seems not to be listed (in discover or website ) so basically hidden only known to the initiated, some app I use are really better as package, Emacs is the main that come to mind, (no emacs-daemon, no native-build, verrry long startup) maybe it is a matter of better flatpak packaging but still.

Some other tools I can see: btop, ranger, nnn, neovim, wev, evtest, wl-clipboard, keyd (not sure it could work as flatpak), kitty, foot.

Sorry for my long post if came to that point and thanks again for the good work.

Here is an (old) ref I use for pacman build and install (it is for mac so I remove all part about building bash and libs ), I did install it in ~/kde in place of /opt and then reinstall pacman with pacman:
https://github.com/kladd/pacman-osx

1 Like
19

Running KDE Linux well, I am testing distrobox , I had to configure it to use podman instead of docker maybe it is better to make podman the default.
There is one area that I want to point out, it is regarding input, I would suggest to include those tool into the base system:

  • maliit-keyboard: I know there is some work for a better virtual keyboard (with modifier support and proper configuration) but until then it seems the best solution as virtual keyboard, for accessibility and input on touchscreen (I test KDE Linux on a touchscreen device). I have tested to install it in my systemd-sysext extension but without luck.
  • keyd : it is a keyboard remapper tool that work at the kernel level, it is really simple to use and very efficient. It provide qmk/zmk fonctionality (but much cheaper :wink: ) ; per-app config , with a comprehensive config file in /etc/keyd. It is in arch repo and due to is low level nature I think it would make sens to include it in the base image. I was able to make it work by use of systemd-sysext extensions though but I think it would benefit more people to have it included.