Arch is a great distro. I've used it on and off since 2004. It's probably my second favourite after Slackware. I agree it is not a mere toy distro, but for certain use cases, like servers, I really don't understand why people think using it is a good idea. Other than LTS kernel packages which are available, there is no upgrade path to the latest versions of server software packages (eg, when security updates arise) without updating the whole system. When you update the whole system, things WILL break from time to time. What sysadmin in their right mind has the time for that?

On my desktop, I'd probably use Arch if I wasn't using Slackware. I was actually using it on my laptop with KDE5 in 2014/2015 as I couldn't get the stable Slackware at that time to boot and didn't want to mess with current ISOs.

It's great to have a distro out there with such a dedicated community (much like Slackware but bigger and they take themselves a BIT too seriously) that provides essentially a demonstration for what a vanilla distro might look like if all packages were kept up to date at all times. It's a bit like Fedora in the sense that they are the frontline testers of the bleeding edge. Their wiki is also amazing and invaluable even to the Linux community at large.

KDE5 was a mess at that time. You could see the promise but it just wasn't anywhere close to feature complete or stable enough to replace KDE4. Yet Arch did it anyway, because that's their mandate. You don't like it? Complain upstream or fix the bugs yourself.

I guess that's why I reacted so strongly when I saw how much KDE5 has improved since then.

Anyway, back to Slackware... for servers, Slackware is far and away the superior distro IMO. Even though I don't like their inner workings as much as Slackware (or Arch) my next choices for servers would probably be Debian Stable or CentOS/RHEL, because of their more stable fixed release models.

I remember reading on the Arch forum a while back that some folks have tried to create an "Arch server edition" with stable fixed releases, but there was such a lack of interest it just didn't take off. It's just not their mandate by the look of it.

1 members found this post helpful.

I have a harder time thinking how they are the same than ways they are different. The obvious example is that arch handles dependencies unlike Slackware where each and every dependency is hardcoded in the PKGBUILD file. Another obvious example is that updating arch is like a slot machine, sometimes the results are okay, other times the update fails because of a pacman ABI conflict... The inverse is true, if you don't update preferably at least once a week suddenly your mirrors are all gone and pacman is too old to update. This is the result of Slackware's development being very focused and not much happens in the main tree without Pat okaying it, arch on the other hand has countless developers and runs into the too many cooks problem. Their lack of quality control only compounds this. Also I'm not saying my arch install was broken, it worked a lot better than a lot of other arch installs I have been told about, but the time cost in making it work was too much. Maintaining a single arch install well is a full time job, I'm not saying its a toy distribution as an insult, but rather that it literally is a toybox. Treating it as a serious production machine will just waste your time, but if you want to find this out for yourself I'm not stopping you.

1 members found this post helpful.

I think Crux is a better fit for Slackware users.

I'm arriving a little late to post...
I have AMD APU A-10 7700k
Works well with drivers amdgpu and radeon(ati)

Plasma 5.12.5 in Slack Current
Plasma 5.12.6 in Gentoo
Plasma 5.13.3 in another Gentoo

Radeon uses less memory.
AMDGPU has a better image texture.

Eric, I just wanted to say that I see you as much a part of Slackware as Pat. Two arms on the same body, or two wings of the same bird! Just saying.

PS: Hope you don't mind my signature....

4 members found this post helpful.

Thankfully i saw your paypal signature for pat so i was able to make a donation.

Craig Miles

1 members found this post helpful.

sbbdep can tell about binary runtime dependencies, not what is optional, or required through an optional KDE component.
It can also not say what should be in stock Slackware, like openCV, that is a default lib for a lot of tasks today

about trimming down KDE, I would especially be interested if KDE Pim could be omitted, and if this would allow to build without akonadi, other components would follow. (since PIM has been used to beta test kolab stuff, with all the problems there where for some time)

about what I read in your blog, that Pat prefers current KDE ...
KDE and LTS, this does not fit.
as much as I like KDE, KDE and LTS is a bad joke, the only consistency KDE has is to be inconsistent and not trustable.
they do not have the knowledge, the will, and the drive to do something like LTS, and (this is my interpretation) as long as huge parts of KDE are driven as a philanthropic toy of a person that never needed to satisfy customers, this will not change.

So putting KDE into a distro will always have the risk that you end up with something buggy that will not be fixed ...

1 members found this post helpful.

This!

Akonadi is part of KDEPIM suite now, so if you exlude KDEPIM you also lose akonadi. Outside of KDEPIM, there's only kjots and kmymoney that have a dependency on akonadi. Those two are in my "applications-extra" subdirectory i.e. optionals that can easily be omitted from a trimmed-down Plasma5.

2 members found this post helpful.

There are distributions that sort of go by such a route. E.g. Arch has separate plasma-desktop (a minimal install), plasma and kde-applications packages ( see https://wiki.archlinux.org/index.php/KDE#Installation ), and a bunch of additional packages, too (e.g. Konsole and Okular are separate packages and not installed as part of kde-applications IIRC). Debian does something similar ( see https://wiki.debian.org/KDE#Installation ). It may be worth looking into how these are split.

I have a working Arch installation at home (and I think it still has a working Plasma 5 installation, too) and a Debian system at work, let me know if you want me to check anything specific.

I'm not sure how much value there is in things like e.g. splitting off KDE PIM. On the one hand, yeah, it's pretty terrible; I can remember a time when Kmail was great, back in its 1.x days. Nowadays all it can reliably do is corrupt mailboxes, settings files and address books, and all I've seen Akonadi do on my system was use up 100% of my CPU or crash. But on the other hand it's not like it can't be disabled. Upstream doesn't seem to treat it as "optional". They may be wrong about how useful it is in its current state, but it also means that depending on it won't be frowned upon in the future, for example.

1 members found this post helpful.

Finally I found an application made in Qt5 which looks interesting for me: radeon-profile https://github.com/marazmista/radeon-profile

And guess what?

It use QtCharts https://doc.qt.io/qt-5.11/qtcharts-overview.html to display some shiny graphs, BUT this thing apparently lacks from Eric's Qt-5.11.1

I know, I know that saying: do not look in the mouth of a gifted horse...

Those Arch packages are in fact meta-packages (contains only a list of dependencies to another packages).

It's kind of strange that a sub-module which is present in the big Qt5 tarball is not being built by default.
From what I read in Qt support forums, it should be compiled explicitly... I'll see what I can do.

Update:
I can see QtCharts sitting inside the qt5-5.11.1-x86_64-1alien.txz package... how did you arrive to the conclusion that it is missing from the package?

3 members found this post helpful.

Thanks!