To be honest, I do not think that Plasma5 is particulary bad since 5.13.2 and myself I see myself jumping back in KTown quite fast too.

Maybe it is just something from my Fedora background, where the remote repositories are quite usual and YUM is a King.

That's why that insistence about including particular software in the core distribution is for me a bit strange.

Some things stay better in their own repositories. Of course, that's just my biased opinion.

I must have missed obvious. Speaking for my self, since I have no idea what others plan to do. If the next version of Slackware ships with Plasma 5, I will already be there since I use Slackware64-current and ktown for all my boxes except one. That one Slackware64 14.2 box will be updated to the next version and stay with what is shipped until the next stable release. Of course as with Slackware 14.2 I will apply updates. The rest of my boxen running -current will have never jumped ship from ktown. When the next Slackware64 version is released both -current and ktown will be "in-sync" with the stable release until the first updates to -current and/or ktown. I intend to stay with -current and ktown as it progresses as I have since Eric introduced ktown. No plans to jump in the first place.

1 members found this post helpful.

The KDE Frameworks are 72 in total at the moment, that's a lot less than 200. The Frameworks are tiered into 4 groups where the most basic ones are pure extensions to Qt5, mostly abstractions to benefit other parts of KDE further down the road and to take away direct dependencies on Qt5 itself. The higher tiers start depending on both Qt5 and lower-tier Frameworks, and eventually also on other system libraries. None of the Frameworks depend on anything else from KDE.
Then, Plasma depends on Frameworks but not on the Applications (mostly... some features in Plasma get enabled with the presence of some Applications) and finally the Applications build on top of Frameworks and Plasma.

Indeed here's where the real improvements and disruptive change becomes apparent. The release cycles of Plasma are largely functionally oriented. The increments to a release follow a Fibonacci sequence of weeks after initial release (1, 1, 2, 3, 5). See https://community.kde.org/Schedules/Plasma_5.

That's why this would be an ideal time to absorb the KDE Plasma5 Desktop into Slackware.

Compiling all of Plasma 5 (including Frameworks and Applications etc) is trivial. I guess you have never looked at the kde.SlackBuild script? It only takes a single commandline. Rebuilding parts is just as trivial. I wrote an article about kde.SlackBuild for KDE4 but it's still relevant for the Plasma5: https://alien.slackbook.org/blog/kde...de-slackbuild/

And I do not consider the KDE Frameworks to be a 'pollution'. They have no place in the "L/" series, being an integral part of the KDE software. However, the LXQT desktop which is also built on top of Qt5 uses several of these KDE Frameworks. If Pat decides to not adopt Plasma5 but instead use LXQT as a more light-weight Qt5 based Desktop Environment in Slackware, he will still have to add the KDE Frameworks to Slackware as well.

Qt5 is indeed not something which is exclusively used by KDE software. It is an important piece of generic GUI framework.

6 members found this post helpful.

Because I think Alien Bob's preferred focus is to incorporate future versions of Plasma 5 into Slackware. He never meant to be the community's Plasma 5 maintainer for Stable and Current. He isn't getting paid. Its a lot of work. He has every reason to stop supporting Plasma 5 for Slackware if it isn't incorporated in for Slackware 15. He did make Pat an offer in the donating thread that if Pat incorporated part of it he would do the rest. He is doing us all a kindness by putting out Plasma 5. It is up to Pat what happens with Plasma 5. I can understand why he would ditch Plasma 5 based on current circumstances.

The only thing I don't understand about Alien Bob's stance is why would he move to Arch which has systemd? I didn't see that coming.

2 members found this post helpful.

Same here. My opposition to systemd is not ideological, it is purely technical and philosophical. I would politely ask Alien Bob why out of curiosity but I think it would probably degrade into abuse considering the very emotional nature of the topic.

2 members found this post helpful.

I would prefer a systemd-free distro if I were to abandon Slackware. I considered Porteus but after frequenting their discussion board for a year I doubt that they will survive without Slackware, it is not a real distro but a hack-together of binaries from all kinds of repositories that they 'borrow' and not compile themselves. And on top of that, they seem to move away from Slackware as a base anyway. It's a live OS, not meant for installation to a computer, and that finishes it for me.

Arch appeals to me, and if I want a systemd-free version of Arch I will probably look at https://artixlinux.org/ . But as a mere user of a distro I will have to comply with the design principles of its developers, and if systemd is part of the OS, then that is what I have to accept.
For Slackware it is different since I am involved in the development of that OS. I have a chance to prevent systemd from entering Slackware and therefore that is what I do.

6 members found this post helpful.

But that has already happened with the core Slackware distribution! -current is now widely different from 14.2, and is updated on a near daily basis! I moved from 14.2 to current when I needed support for some new hardware and software. 14.2, despite updates, was getting behind the curve.

What I'm saying, in effect, is that the arguments you are applying to kde5 could equally well be levelled at an ageing 14.2.

I'm not implying that there's anything wrong with 14.2 *unless* you need right up-to-date support for some functions.

And just because something is updated, it doesn't follow that everyone needs that update - unless its security related, of course! The only time you *need* to update is if you need newly added functionality.

Eric's kde5 seems to be every bit as stable as kde4 ever was, and certainly is more capable and better supported. Based on my experiences, I believe its time to switch.

Just my 2p worth!

--
Pete

Ah. No, I didn't do it via the SlackBuild. I wanted to do it for development, not packaging/installation purposes (i.e. I wanted to fix a few things in Konsole). So I was working off KDE's build scripts + semi-official "how to build stuff" documentation on their wiki.

So I wasn't working off a stable release, and also needed to deploy a separate tree in a workspace directory, so as not to damage my actual KDE installation (which I was using at the time).

Yeah, and it needs to be done with more or less of an eye for the future, too. I read the LXQT project's forums -- their stance on KDE Frameworks is basically along the lines of "if it's not too heavyweight and does something which we want, but don't have the resources for, we'll adopt it". So they might adopt more in the future.

I have no useful opinion to offer on whether Plasma 5 is "ready" for Slackware or not. I haven't used KDE since 3.5 and my taste when it comes to these things has been heavily skewed by my post-3.5 exposure (returning to WindowMaker, then using Ratpoison, XFCE and Openbox). And I have no useful baseline to compare it against -- I didn't use KDE 4 as a daily driver for long enough to tell if it's convincingly better or worse.

I'd really love if Qt 5 remained well-supported. Due to GTK3 being really odd for someone who spent their teenage years with the likes of Windows 98, I use a lot of Qt-only applications just so that I can avoid GTK 3.

It's also worth pointing out that, unlike KDE 3.5-era applications, modern KDE apps work fine without KDE and there's no significant brokenness, nor significant environment hacking needed to get them working. I reliably used Konsole and Okular, for example, without running Plasma 5.

I must ask, have you actually lived with an arch install before? I have and its a constant maintenance burden, sure you can make it not use systemd or a lot of other software, but the arch development cycle moves very fast and there is real risk of breaking your system if you either do not update promptly or don't stay 100% on top of your updates. Frankly its a toy distro in that it requires constant attention, care and tinkering to work well. Additionally if you dare venture off the chosen path there is a lot of fighting pacman to let it do what you want. This is very much unlike Slackware where you can safely update old installs without much effort and aren't constantly fighting with your OS.

As for Artix I'm not familiar with them and can't really judge them, but they give off the impression that they don't have much reason to exist beyond not using systemd.

2 members found this post helpful.

I've never used Arch, but I did use an Arch derivative (Manjaro) for a few months before coming to Slackware. It was fun for awhile, and actually I never experienced major breakage from updates, but you do have to stay on top of updates and be willing to spend time making little tweaks and fixes (in the best case) due to stuff changing all the time. It is a hobbyist distro IMO, as opposed to something you'd ever want to put on a production machine. After that experience, I decided that stability was definitely a priority for me.

1 members found this post helpful.

Thanks for the reply Alien Bob. Let us hope it does not devolve into typical systemd public discussions.

I have had the same experience with Arch as orbea. Arch will break, it is only a question of when. If I want to check out newer software, ideas, etc, I peek at Fedora. I looked at Artix and Parabola but they did not install because of flaky UEFI.

For non-Slackware and non-systemd I like Devuan. I consider it Debian fixed and like the decisions they make. Other than splitting header files into -dev packages which has little supporting reasons now that hardware is so cheap compared to when it was implemented.

I imagine you are fustrated Alien Bob. Yet, there is nothing like Slackware and everything else ends up being a pale comparison.

3 members found this post helpful.

interesting thread, especially when I see patterns of post I do not see, thanks to the ignore list :-)
my condolences to the people here that try to fix this echo chamber some try to create here, but a lot of thanks for the effort to keep some sanity here

one question on topic, and maybe Eric, or some one else, can answer.

I think I heard/read somewhere that KDE is configurable and it does not need to be build with everything,
eg omitting KDE PIM

I wonder if this is
a) true
and
b) a possibility to consider

is there a 'slim' KDE possibility, and if, what could be optional?




also, as an maybe extra topic but slightly related:
the impact on the dependencies. looking at the ktown dependencies, some/many of them should be part of a distribution anyway or are there to update .
jsonglibc, hack fonts, cracklib, openCV! ,
some others are shared with kdenlive? mlt, vid, maybe others shared with other projects
and some I do not understand, openAL, nice but... 3d sound for KDE?
not that I think this is bad, I had my own openAL build for years and would welcome the idea to have this in Slackware per default ... :-)
is there an overview which dependencies for what and if it could be optional?

I don't think Arch Linux is a toy distribution at all. And I have been running Slackware-current for countless years, how is that different from frequent updates to Arch Linux? I think the approach is pretty much the same. Note that I do not speak of experience - I never used or even installed Arch. The same is true for a lot of other distros by the way.

That is how I perceive it as well.

It should not be extremely hard to slim down a KDE installation. KDEPIM and Telapathy are trivial to remove.
The bigger issue is, what can you miss? When slimming down I look at de-duplication of functionality and stripping the features I do not want or need. Perhaps it's worth writing down what you or other people consider a bare minimum to KDE.
Note that I already did that for liveslak. The very first ISO variant that I created is the one that never saw any actual ISOs released to the public... it is the "KDE4" variant which was supposed to become the KDE equivalent to my small XFCE Live ISO, only with a max size limit of 1 GB as opposed to the 700 MB of the XFCE variant.

For the package list I had in mind, look at the min.lst, x_base.lst, xapbase.lst and kde4base.lst in https://git.slackware.nl/liveslak/tree/pkglists - and it is the kde4base.lst where I tried to define what a bare KDE4 should contain. For Plasma5 something similar should be done one day.

I never actually wrote down what dependencies are for what KDE packages. But that is doable. Not right now though... I need my time elsewhere. BUt perhaps your sbbdep will come in handy?

1 members found this post helpful.

I have installed Arch on bare metal before and more recently in a VM. Arch is an amazing distro, but, from my experience it is a little less stable than Slackware64-current. That is, Slackware64-current will on occasion break. Arch will break more often in my experience. This is my opinion and not a condemnation of Arch.
At the moment I am running all Slackware64-current (one of my units has an OpenBSD partition).