David Chmelik posted on Mon, 11 Mar 2024 06:13:16 -0000 (UTC) Imagine meeting you here! =:^) (We're both active on the pan newsclient list, as in the user-agent header, as well.)
... as excerpted: > We tried KDE Neon 6 (and had problems mentioned on discuss.kde.org > threads like 'are you out of your mind to release such a faulty update' > and 100+ other major problem threads since) which broke 2/3 our PCs (one > inoperable) so downgraded to OS with KDEP5. AFAIK kde/plasma 6 isn't really considered stable yet -- it's just the first full release to get it out there for broader testing by those willing to deal with the problems in ordered to be running the newest release. Of course I'm testing actually live-git (via the gentoo/kde overlay live- git package-ebuilds), not even released-versions but the goal is CI/CD stability level and deployed here, they do seem to meet that goal most of the time, for people like me prepared to deal with the occasion fallout when something goes wrong. I guess that would correspond to Neon Testing? But even the most stable of the Neon editions, the User edition, is recommended for "adventurous users" (Neon FAQ, What is KDE neon?), "who want to experience the latest and greatest software as quickly as possible", with the caveat that "using the latest software the moment it's released will inevitably result in a less stable experience compared to distros that delay software by days, weeks, or months. As such the ideal KDE neon user is someone excited to use the latest and greatest KDE software who can tolerate some bumps in the road from time to time, not someone with mission-critical reliability needs." (FAQ, Who is KDE neon for?) So presumably you're not using it for mission-critical and are willing to tolerate those "bumps in the road", as the faq says... And because it's related, back a few years ago I was hanging out on the btrfs lists while it was still unstable enough to have a big warning attached to the kernel config option that enabled that filesystem... and a lot of folks came in there after-the-fact of defining their data as not worth a whole lot by their action of running a still unstable filesystem and not having backups of the data they were placing on it... Because the value of the data in question is defined not by mere claims but by the number of backups considered worth the trouble to keep, just in case the working copy AND the N-1 level of backups ALL fail at the same time... and especially because in this case the running software is known to be not suitable for mission-critical reliability so the calculated risk factor is accordingly higher than normal... those backups either exist and can be restored from should the need arise, or by definition the value of that data has been established as below that of the time/hassle of doing further backups. (IIRC back on that then still unstable btrfs list, one unlucky poster had even defined his /wedding/ pictures as of low enough value not to have even a single backup... while storing them on that then still unstable filesystem!!! One can only hope that whatever photography services he used for that wedding still had rather higher value definitions for that data... and of course that they charged in accordance with that defined value as part of the value proposition of their services.) > Now that ~/.kde doesn’t seem > much-used, what do I delete from ~/.config & ~/.local/share so KDEP5 is > usable again (downgrade led to many bugs/crashes)? I know most stuff > starts with k, but a lot also doesn’t: maybe Okular and a large amount > of optional KDE software we have but I can’t keep track of. Ideally you can just restore from backups made before the upgrade and not have to worry about sorting through the changed config. But it reads like you lost the backups bet and the costs must now be paid... Which I do at times too, yes, even running live-git versions! After all it's a calculated but at the time as yet untriggered risk against a known time and hassle value! =:^] What I do when I lose the bet in those cases is make an after-the-fact backup, wipe the directories in question, and restore on either a bisected or case-by-case basis. (Bisected in this context means split in half, restore the one half and see what works or is still broken, split either the restored half or the unrestored half in half again so now in quarters, and repeat, then repeat with eighths, etc, until either the bad is all sorted out or the remainder is small enough that the hassle of reconfiguring it is less then the hassle of continuing the bisect.) For me at least, that works /reasonably/ well (given the circumstances I've found myself in), because kde's my only desktop (tho I do have the minimal weston compositor as a backup wayland compositor), so most of the stuff under ~/.config and ~/.local/share is either specifically identifiable and thus excludable from my bisect (either don't wipe it at all or restore it unconditionally), or if not easily/specifically identifiable, can be assumed to be kde-related. If I were running gnome or something else big enough to have a whole bunch of non-specifically-identifiable stuff in the standard XDG locations, as well as kde/plasma, and was significantly worried about losing the config and some data of both/all of them... well, I guess I'd then need to define the value of that data to be higher because the cost of sorting its corruption/loss would be higher, so I'd hope I'd keep better backups to do so! =:^] Well either that or I'd be aiming for something a bit more stable than the live-git stuff I run... Or maybe both more stable and more backup updates! > We’ll try KDEP6 when FreeBSD UNIX, Slackware & Kubuntu LTS GNU/Linuxes > upgrade. That reads like it might be a policy better matching your instability tolerance, agreed. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
