Those snowflakes over there can't handle it....

4 members found this post helpful.

Lets do it. Here is the battle arena: http://slackbuilds.org/repository/14.2/games/openarena/
I'll take you all on including whatever Debianites and Archers you bring along with you!

4 members found this post helpful.

But he did not classify qt as pollution. I do know that qt4 is used elsewhere in the distro than just KDE4 (my computer is still boxed up since we won't be in our new house until next month, so I can't find any specific examples right now) (I decided to use ivandi's resource... see below), and it would likely be similar with qt5.

According to ivandi's dependency list, the following programs outside of the kde/ series require qt. Some of the libraries may still be for KDE related items, however, I removed a few like attica, grantlee, libdbusmenu-qt, liblastfm, polkit-qt-1, qca, qimageblitz, qjson, qjson, soprano, and strigi that seemed to be only tied to KDE, but there's others that certainly are not tied to KDE.

2 members found this post helpful.

I think the point is that you wanted Darth to spell out what he disliked about Qt5/Plasma 5. Calling it pollution wasn't enough.

But PV says he's fed up with the pollution of the /L series, and that's good enough for you.

PV said he was fed up with the pollution of the l/ series in regards to KDE. As I showed above, qt4 is not only tied to KDE, so I was trying to find out why Darth considered it pollution (which I'm guessing he thinks it is only for KDE, but I was trying to verify that and didn't want to assume).

And I didn't ask for him to explain why he thought Plasma5 didn't belong. He has shared that sentiment for a long time (although, it was nice when to see him eventually share reasoning after he started using it).

If I remember right, Darth Vader stated that 6 months ago he made a dedicated box for testing Plasma5 and "he started to use it" daily.

However, I think that before this moment he had at disposition various ways to frugally test the Plasma5, for example the LIVESLAK made too by Eric Hameleers, or maybe temporary installations. He also stated multiple times that he's an adept of the backups, then I do not exclude temporary installations rolled back after several hours or even minutes.

Did you are sure that he does not touched at all the Plasma5 previously to the moment he made his test-box?

I love Plasma 5 myself and it is my favourite DE. Yet, it can be annoying as hell. It reminds me of the 6 years it took for GNOME 3 to be useful, where some papercut did not distract you, fustrate you, or make you scratch your head: why did they make that choice? Kind of. The GNOME 3 s%#t show is hard to match in scale. Typing this on Fedora GNOME ironically because I was in a masochist mood and Steam is my vice.

It seems to me Plasma 5 is the major hold up on Slackware 15. Everything else is top notch from what I can tell, but I' am only one user. I just use XFCE on Slackware anyways, and I do not think one distro can package Plasma and the complexity in a state that just matches the productivity of XFCE. AlienBob does an excellent job but he too is only mortal. I agree with AlienBOB, not a fan of GTK looks and much prefer the QT/KDE look. I do not like LXQt or Lumina. Missing Okular would suck but last time I checked it' s deps were pretty minimal. I would rather see Plasma 5 inclusion put on hold for a point release then wait and wait for inclusion for 15. On the other hand it would be a good anniversary feat.

I say remove KDE 4, exclude Plasma 5 and keep QT5. Removal of QT5 is not really an option these days, ok, a sane option. Include Lumina, something minimal and low effort the QT folks can adjust too. They universally seem to like it.

One of the things I rediscovered with Slackware is the benefit with a large amount of programs installed. It is a waste of bandwith and electricity to keep downloading little utilities, or some old program to handle an old file that should be still openable with a more modern program; but is not for various reasons. This is not bitrot as someone suggested, this is a feature. No hunting and waiting for a program to download, install, install more useless s%4t for the latter mentioned scenario, or some utility for a hack, or some weird use case scenario. It is usually already there. The relief that some CLI program you forgot about briefly or just discovered from a reference is already there. It is called continuity and practicality.


I' am really chomping on the bit for 15, it is mainly my impatience speaking.

1 members found this post helpful.

First of all, I never demanded everyone move to plasma5. I expressed my opinion at the time that I felt plasma5 should be pushed to current. Existing KDE users on current would then be forced to upgrade, in a manner of speaking, but xfce users or users of other WMs obviously be unaffected.

I admitted I may be wrong about that given the bugs, yes. I don't think I should be given a "free pass" but I think to err is human, and all that jazz. This is why I'm just some luser posting in a forum and Pat is the BDFL.

Also I've made less than 300 posts at the time of writing in 15 years. I just don't *say* a whole lot around here. So I think it's only natural to focus less on what I say than Darth, who is literally posting *constantly*.

Also Pat's post about the Store fiasco was a bit of a wakeup call. I think I like many people want to see this great distro be successful. We also want to see it ship and not be in limbo for too long.

Part of it was also seeing how impressive XFCE is now by trying it again as a result of firing up AlienBob's amazing xfce live CD. I used xfce for years when I was running Slackware on an older machine but always saw it as a second tier desktop. I think it could pass for a sensible default at this point, but the fact that its development seems to be troubled with the port to gtk3 and they haven't had a major release in 3 years. :shrug: it may just be the best option right now.

Yes, I agree with jakedp that kde4 should be cut too in that process. Users shouldn't be encouraged to use deprecated/EOL'd software, for obvious security reasons.

I am not saying adding plasma5 to current for pre-15.0 testing would be wrong. I am saying it would not be wrong not to include it. Slackware has never had a "default" DE (except perhaps fvwm2 in the 90s, which I understand was configured by Pat, but that's a different story) so including it may be perfectly fine, as long as the known bugs are documented. As I said before, and again I find myself agreeing with jakedp, is that plasma5 will still remain my personal favourite DE, and I'll use it regardless.

Not including qt5 would just be silly. It's not even in the same category as including plasma5 as a whole. It's a *library*. And a damn good one. It's also an absolute dream to develop for.

The "pollution" of the KDE libs is a separate issue. Some of them are so tied to KDE that IMHO they should be cut from l/. I guess a new category called "kdel" (or whatever) might be one way of doing it or hell, just throw it all into kde/, especially if there is no reasonable likelihood the library would be used for anything other than KDE applications.

1 members found this post helpful.

I am not a developer. I am not a programmer. I'm just a guy who uses Slackware for all my day-to-day computing needs. I am, however, reasonably computer literate, and have a technical background.

Many of the applications I use on a daily basis are no longer supported - and indeed, won't compile - under kde4. I *have* to use kde5 / plasma / call it what you will, in order to do the jobs that I have to do - mostly video editing and multimedia stuff.

Thanks to AlienBob's efforts, I have a very stable kde5 setup running on top of -current. Were it not for AlienBob's efforts, I would by now have been forced - reluctantly - to switch to another distro.

OK, I admit my requirements may be a bit specialised, but even my menial tasks all work just fine and dandy under kde5. I have found no stability issues or any other show-stoppers. I do have many show-stoppers under kde4.

AlienBob has made the transition to kde5 relatively painless for me, but from my personal perspective, it would be more satisfactory to have kde5 incorporated into the main Slackware distro, rather than having to take pieces from here and pieces from there.

It took a while before Slackware embraced 64-bit, and in the interim Fred Emmott's Slamd64 provided a very satisfactory alternative. I see the current situation with regard to kde5 in a similar light, and without any disrespect to AlienBob's sterling efforts, I will be a much happier bunny when kde5 is integrated into the official Slackware distribution.

--
Pete

1 members found this post helpful.

By how long time the people praise there the Plasma5 and ask for it to be included? Myself I counted several years, yet until 5.12 there was a silly security issue on Plasma5 while ironically the KDE4 was unaffected.

https://www.scmagazineuk.com/linux-s...rticle/1473251
Of course, that just one of them which made in the news, how many similar issues may still hang around?

And looking about the opinion of no one else than Martin Graesslin, the now retired KWin Guru: https://blog.martin-graesslin.com/bl...plasmawayland/
Or even looking to the generic security state of a Linux desktop
https://arstechnica.com/information-...inux-security/
I think is safelly to assume that both the "deprecated" KDE4 and the modern Plasma5 has similar security level like any other Linux desktop environment: zero.

As a biased personal opinion, maybe the KDE4 could be a bit more secure. But only a bit. So, why we should remove it?

1 members found this post helpful.

Same here. I am not a programmer or a Linux Guru.

Certainly you have your own use case, and certainly you need that Plasma5 for your applications and your work. You need a pretty modern DE and no one can blame you.

But let's talk a bit about your preference for inclusion of Plasma5 on Slackware. You are sure that's what you want?

From what I seen, the Plasma5 has a release cycle of one month. Slackware has a release cycle of around 3 years and a life cycle of around 8 years.

Hence the question, assuming that Plasma5 is merged in Slackware: you are certainly that a 3 years old Plasma5 is OK for you to run your particular applications? How about a 7 years old Plasma5?

Looking at your experience with KDE4, your particular applications evolves quite fast and probably you need your own Plasma5 installation to evolve according.

Apparently for me, you need to update your Plasma5 installation much often, and how that can be done?

A solution can be a separate repository, with its own much faster release cycle, for example the Eric Hameleers's KTown.

Hence my speculation that even Slackware adopts the Plasma5, shortly after the 15.0 release you will jump in KTown. Again.

2 members found this post helpful.

Finally someone who try to rationalize!

Is obviously that nobody will stay on a Slackware shipped Plasma5 more than several months! And its very fans will be first ones who will jump back into KTOWN.

You missed the cherry on top of cake: the DBUS thing heavily used by both Plasma5 and KDE4, to be honest.

Basically, it is something like this: any application able to communicate via DBUS can instruct another one to do things in background, without user interaction.

Imagine something like a Kate with the Konsole plugin activated, and a web-browser able to communicate via DBUS and driven by an obsolete Chromium, err... WebEngine. The future Falkon, maybe?

Oh, man! I believe that the future will be hilarious, with computers hijacked because a visit on a particular site...

BTW, did you know that that Qt-5.9.6 LTS today ships something like Chromium 56.x?

2 members found this post helpful.

KDE4 also had a release cycle of one month. The only thing that changed in the meantime is that the KDE4 Software Collection has been split differently so that now, Plasma5 Desktop is comprised of the KDE Frameworks, KDE Plasma and KDE Applications and each of these three have separate release cycles. In short, you will get a new release of all these components once per month. That's no different from KDE4, so this is not an argument against Plasma5 inclusion.

People who use the stable Slackware release 14.2 are running a KDE4 platform for which the support had already ended (except for the kdelibs LTS package) when Slackware 14.2 was released. That was 2 years ago. I see no difference with what will happen with Plasma5 in Slackware. In fact, Darth Vader is a KDE4 champion and is determined to stick with KDE4 even when Slackware 15.0 is released and KDE4 has been removed from it. So, yours is not an argument against inclusion of Plasma5 because for those same reasons, KDE4 (and 3, and 2) should never have been included either.

There is no difference here between what would happen for Plasma5. compared with KDE4. I have been offering the bleeding edge KDE4 in my ktown repository since 2008, and Slackware in all those years almost never had that bleeding edge included, even -current at that time. Even back then, users of KDE4 would use my ktown releases if they thought the Slackware versions of KDE4 were too old for their purpuses. After all, the same happens all the time: applications evolve and start requiring newer versions of the supporting libraries, up to a point where a stock Slackware installation is unable to satisfy these requirements and you have to move on.
If everything remained the same all the time, there would not be any point in newer Slackware releases either. The very point of new Slackware releases is to be able to introduce new capabilities or adopt new philosophies. Sometimes those are disruptive, think of the removal of GNOME, or the switch of KDE3 to KDE4, or the inclusion of Pulse Audio.

And there's nothing wrong with that. All you did was fabricate reasons to support your opinion that Plasma5 is bad.
It is quite simple: do not use the software you do not want to use. Do not assume you have the right to decide for other people what they must or must not use.

6 members found this post helpful.

A few months ago I tried to build a bunch of KDE stuff from scratch (I'd say "I tried to build KDE" but nowadays it seems the KDE folks frown upon that, now that it's all Plasma, KDE Applications and KDE Frameworks...) and fix a couple of things that were irking me in Konsole. I failed miserably and that's about all the experience I have on the dev side, but here's what I learned in the process:

• So first of all, with the KDE frameworks now being nicely split, you end up building a lot (200+?) of "modules" (I hesitate to call them "packages" in order to avoid the confusion with the native package manager's packages, but I think that's the term they use?). I'm sure this makes sense from a maintenance perspective and that it works better for the KDE team. And probably for everyone else who's more than mildly familiar with this stuff. But it was really hard for me to wrap my head around it, and there's not too much documentation, either. (Edit: please note that I don't remember the exact number and I don't have it in my notes. It may have been less. I definitely remember it being outrageous)
• Plasma and the ecosystem around it moves really fast nowadays. This isn't your late-stage KDE 3.5 or KDE 4.12 development, where most of it was bugfixing and changes were easily compatible. It's crazy and hectic and you get big features in this release, and then important bugfixes for them six months from now.
• For all the remarkable effort in it, "KDE 5" (whatever, Plasma 5 + whatever version of KDE Frameworks and KDE Applications is "latest" right now) has just recently come to be on par with 3.x or 4.x on a per-feature basis. This may quiet down as things mature a bit, but even a one-year difference is very noticeable.

KDE applications and Plasma 5 use the KDE Frameworks heavily. Qt 5 is behind those, yes, but I expect that most of the pollution would be due to the KDE frameworks, not Qt. Qt is used by a lot of other applications that I use without Plasma -- xpdf lately, Rosegarden, pcmanfm-qt come to mind. Packaging it doesn't seem trivial because of the build infrastructure, but it certainly looks more accessible than KDE's stuff.

As for security, remember that time when it turned out you could inject commands by crafting volume labels on USB sticks? https://www.kde.org/info/security/ad...20180208-2.txt

I wouldn't hold my breath for either KDE 4.x or post-4.x being too bulletproof.

1 members found this post helpful.