Soplos Linux

thanks for the prompt reply,
i have to say that Soplos Linux is the most i've enjoyed since Sam Linux and that was a bunch of years ago... i've been on Debian Stable with xfce for a long time. Debian Testing with a tuned plasma 6 in Soplos style is a blast!

Hi Sergi,
I wanted to give you a quick piece of feedback regarding Soplos Welcome (the Kernels section). I know I'm probably an outlier here because I created a dedicated 1GB /boot partition on my MacBook Pro, which isn't very common nowadays.
However, the kernel update cycle over the last 15 days has been quite intense, and my boot partition quickly filled up to 80%. I noticed that the "Clean Old Kernels" tool in Soplos Welcome works as an "all or nothing" solution—it offers to purge every single older kernel, leaving only the currently running one.
Since Soplos is based on Forky and is essentially a one-man show, I prefer to keep at least 3 kernel versions (the current one + 2 older functional backups) just to be safe. If a new kernel misbehaves after an update, I need a working fallback to boot into.
Could you please consider adding an option to the GUI allowing users to choose how many old kernels they want to keep (e.g., a limit of 3)?
For now, I've resolved this on my end by creating a permanent rule via a custom APT hook. Whenever packages are updated, it checks the number of installed kernels. If there are more than 3, it automatically and safely purges the oldest one using dpkg (to avoid APT looping) and updates GRUB. I placed it in /etc/apt/apt.conf.d/99soplos-kernel-limit:
DPkg::Post-Invoke { "if [ $(dpkg -l | grep -E '^ii linux-image-[0-9]' | wc -l) -gt 3 ]; then KERNELS=$(dpkg -l | grep -E '^ii linux-image-[0-9]' | awk '{print $2}' | sort -V); OLDEST=$(echo "$KERNELS" | head -n 1); VER=$(echo "$OLDEST" | sed 's/linux-image-//'); CURRENT=$(uname -r); if [ "$CURRENT" != "$VER" ]; then echo "[Soplos Kernel Limit] Nalezena > 3 jádra. Automaticky odstraňuji nejstarší: $VER"; dpkg --purge "linux-image-$VER" "linux-headers-$VER"; update-grub; fi; fi"; };
Maybe a similar automation or an APT hook that retains n-versions could be useful directly in the distribution for users who forget to clean up manually via the app.
Thanks for your hard work on Soplos Linux, it runs great!

The main thing is that it works under the hood. You did a huge amount of work on the kernel for the old hardware. Thanks for that!!!

Great! thanks for the quick reply. now I'll let rsync work for a while and I'm really looking forward to the first launch of Tyson. If you want some tests and reports in the future, I can also use mbp 5.5 (8GB ram, 500GB 7200rpm wd hdd), it's a lowend lab. and mbp 9.2, (16GB ram, 512GB p210 dram-less ssd), where there is enough disk space.

Anyway, I'm going to do a full rsync on the mbp 11.5 and I'll try to install Soplos Tyson this weekend, unless you tell me not to do it due to oclp. Considering how smoothly the live system runs, I wouldn't worry about it that much.

I would guess that the problems are mainly in power management, stricter ACPI validation, and changes in the DRM subsystem in new kernels.

 dan ~ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 465,9G 0 disk
├─sda1 8:1 0 476,8M 0 part
├─sda2 8:2 0 119,2G 0 part
├─sda3 8:3 0 500M 0 part /boot/efi
├─sda4 8:4 0 1G 0 part /boot
├─sda5 8:5 0 18G 0 part [SWAP]
├─sda6 8:6 0 70G 0 part /
└─sda7 8:7 0 256,8G 0 part /home
zram0 253:0 0 7,8G 0 disk [SWAP]
 dan ~ lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1 vfat FAT32 EFI E36D-1923
├─sda2 apfs 389b1468-aa7a-461d-aa4e-03c036965539
├─sda3 vfat FAT32 DEBIAN 0B7E-D33A 491,9M 1% /boot/efi
├─sda4 ext4 1.0 13923bbe-4a10-488e-a638-abe3f7e49e9b 436,7M 48% /boot
├─sda5 swap 1 63b8fa75-36b3-43ba-9170-a8ccf3f7f527 [SWAP]
├─sda6 ext4 1.0 ab12187f-e433-4fc3-aff8-8c26de474feb 46,8G 26% /
└─sda7 ext4 1.0 HOME 5494ca87-e106-45ed-8c93-bfddc22c71f6 193,4G 18% /home
zram0 swap 1 50b32861-f03c-479a-842d-29005e8fdda9 [SWAP]
I use an atypical partition table (after Anaconda "ate" my oclp EFI). I have my oclp EFI and Debian strictly separated, so the OC loader only safely detects the second system via the apfs partition.

I had a complete CuerdOS installation on that mbp 11.5. Then I discovered what was hidden inside the system and started cleaning it up to a pure Debian Trixie. In the end I was left with pure Trixie, where I wanted to use a vanilla kernel, but after trying it out, the custom CuerdOS kernel turned out to be more responsive, so I locked it down and am using it as a production kernel.
Those old unobody pieces are really trouble-free with the latest systems and kernels I've tried so far.
I had an interesting problem with MX Linux 25.1, which wouldn't even boot on my mbp 10.1 and 11.5. I think it's because of the MX Linux boot loader settings, which confuse the oclp writes in nvram and the boot just gets confused and stops...

It's about the architecture. The old unibody mbps generally don't have a problem with new kernels. Even on my mbp 5.5 I ran vanilla Debian kernel 7.0.9 with btrfs without any problems. mbp 10.1 and 11.5 are much more sensitive to the new truncated kernels 7+. That's why I locked the 6.12 lts kernels as a backup and use the locked 6.18 lts as production (on the mbp custom CuerdOS kernel 6.18.5, which works perfectly). Moreover, I'm in a specific situation because I have oclp and dualboot Sequoia / Trixie on the disk.

Hi, I'm new here. Is soplos tested on old intel mbps? It's clear to me that the new kernel won't have a problem on mbps 5.5 and 9.2. I tried live usb soplos tyson on mbps 10.1 and 11.5 and they worked perfectly. Should I try reinstalling? I have debian trixie 13.7 there (on mbps 11.5 with custom kernel CuerdOS 6.18.5.). I've tested that vanilla kernels 7+ are system killers on both Fedora and Debian.