Amazing Awesome PCLinuxOS

Welllll, since I’m leaving the ol’ favorite Ubuntu-based world (Mint, Xubuntu, Linux Lite – all old favorites) to escape the imposition of snaps-by-default, systemd, and a host of other issues Ubuntu is famous for, I decided to give a whole new desktop a try.  As much as I love the Xfce desktop and may go back to it, I’m intrigued by KDE Plasma.

And I just gotta say, Plasma in PCLinuxOS freakin’ amazing, visually stunning, full-featured beyond my wildest imagination, and all very confusing at the same time.  I’ve been at it almost all day today, and I hope I’ll find some kind of “KDE Plasma for Dummies” guide for newbies who have no idea what all these things do.  But this is surprisingly responsive on this modest Dell Optiplex computer with a modest 8gigs of RAM (PCLinuxOS recommends 4 gigs or more for it’s KDE edition).

PCLOSviewThis is a desktop screenshot (sorry it’s choppy, still learning) of my PCLinuxOS Plasma desktop!  Got a big ol’ analog clock and desktop weather like usual, but check out the animated wallpaper!!  Disappearing panel on the bottom (until I mouse over it), then it’s transparent except for the stuff I have on it.  Lots of people use a dock for KDE called Latte which looks and acts kinda sorta like Cairo Dock did, and I might play with that a bit too.

PCLinuxOS doesn’t come with all the gadgets out of the box like this, but I’m just playing and discovered quite by accident that it’s possible to run animated gifs as wallpaper in KDE without using a zillion and twelve terrabytes of RAM.  This is not the resource-hog it used to be!

Soooooo much fun.  And so much to learn!

 

Moving On

My beloved Xubuntu 18.04 is good until next April, but I won’t wait that long to replace it. In my previous post I wrote about the Future of Ubuntu, and have looked closely at the new default package management, snap. The old .deb packaging will still be around for legacy apps and stuff that we all depend on, but the default in 20.04 is snap packaging. To me this will mean a ton of duplicated libraries and cruft, since snaps are kinda-sorta sandboxed and snaps do not share libraries. Bad for those of us who don’t have super-ultra-mega-terrabyte hard drives, right?

Ordinarily rolling-release distros scare me a bit. But even without selectively updating (other than the kernel), there are cool tools like Timeshift that can put things back to a “restore point” in a few clicks and a few minutes’ time. And I dislike the idea of re-installing an OS from scratch and configuring everything the way I want it, adding and removing applications, fonts, themes, and all the rest of it. Updates breaking things has always been a kind of phobia for me I guess, but maybe it’s one that I have overcome with the reassurance offered by super-simple backup-and-restore tools, and the fact that my new distro of choice has a thorough vetting process for updates that filters out a lot of buggy stuff before it hits the stable repositories.

Experimental, beta, or too-new-to-be-proven stuff appears in Ubuntu (and all it’s flavors and downstream distros) without warning all too often. I still remember how buggy PulseAudio was when it foisted upon us all. I dumped it for ALSA with every new installation for months until it wasn’t possible anymore, but by that time it was stable enough. Then Unity. Then systemd. All buggy as hell at the start, but everyone became a tester, like it or not. In a distro intended for newcomers, novices, simpletons, technophobes, and other “ordinary” desktop users, this buggy experimental stuff thrown in as the new default is – well, bullshit. Snaps is the last straw. While I grant that snap isn’t replacing apt for the time being at least, by making it the default, Ubuntu has again brought buggy beta crud to “ordinary” users. No lessons learned from the last several times they’ve pulled this kinda stuff. I’m all for innovation, but let’s not use the LTS versions for that! Enough surprises.

Goodbye again, Xubuntu. Hello, PCLinuxOS!

The Future of Ubuntu (and Ubuntu-based distros)

There are Pros and Cons for everything, but when a distro’s development team makes big changes in policy towards users, there’s always a reason for it, and it’s not always a reasonable choice. Such may be the case with Canonical’s Ubuntu Linux distribution. There’s a big discussion about it going on in their forums (clicky here to have a look). Yes, this matters a lot because it affects every flavor of Ubuntu and every “downstream” project derived from Ubuntu (Linux Mint, Linux Lite, ElementaryOS, and one zillion and twelve others).

Snaps and Flatpaks and such are probably the future anyway, but the vetting of software by a bunch of testers before distribution to users should never go away. But unless you build your own OS from scratch (and some people do), you have to live with whatever the distribution developers decide.

That would be most of us. This “apparent” decision by Ubuntu developers, while probably relieving them of the burden of maintaining packages for their users (and making their job a lot easier and not having to keep package maintainers on the job getting updates to testers and then to users), it also means that we ordinary desktop users could end up as unwitting software testers, trying to find workarounds for broken software. We’re already finding that in instances where the Snap version of a software won’t work but the .deb version from the repository works fine, or vice versa. And that, more than anything else, has been my chief complaint with Ubuntu for years: Making unwitting testers out of novices and newbies without their knowledge (let alone consent).

Read the linked discussion and offer some comments! I’d love to know what some of my Linuxer readers think of this new trend.

How I Graduated Debt-Free — Back To Stable Hill (reblogged)

I’m sure you don’t need me to tell you this, but just in case you were wondering, college is expensive. Even more so now that colleges are increasing tuition because they have lost money due to the COVID-19 pandemic (while forgetting that their students have, as well). So how can you get around the extraordinary […]

via How I Graduated Debt-Free — Back To Stable Hill

Intel’s 10th Gen CPUs: What’s New, and Why It Matters

Wag 'n Bietjie

by Ian Paul

An Intel 10th generation Core i9 blue processor in its packaging.

Intel rose to AMD’s Ryzen 3000 challenge with its recent announcement of new 10th generation desktop processors. Dubbed Comet Lake-S, these CPUs bring a slew of improvements and a few surprising new features. Here’s what’s so great about them, and why PC builders, or anyone looking at prebuilt desktops, should consider one for their next rig.

Intel announced the new Comet Lake desktop chips on April 30. Earlier that month, it introduced new Comet Lake mobile processors for laptops and other smaller PCs. We won’t delve into the laptop side of things here. However, Intel said more than 100 laptops are slated to come out with the new 10th generation processors this year. As for the desktop processors, those should start rolling out in May 2020.
Lots of Cores

Comet Lake CPUs have a lot of cores. The Core i9-10900K is the top chip, with 10 cores…

View original post 93 more words

xdg-desktop-portals-gtk broken in ubuntu 20.04, and how to fix it.

The Problem:

some programs take an extraordinary long time to start.

If you take a look at the error messages:

$ systemctl --user status xdg-desktop-portal-gtk.service ● xdg-desktop-portal-gtk.service - Portal service (GTK+/GNOME implementation) Loaded: loaded (/usr/local/lib/systemd/user/xdg-desktop-portal-gtk.service; static; vendor preset: enabled) Active: failed (Result: exit-code) since Wed 2020-05-13 23:46:05 CEST; 11min ago Process: 6937 ExecStart=/usr/local/libexec/xdg-desktop-portal-gtk (code=exited, status=127) Main PID: 6937 (code=exited, status=127) maj 13 23:46:05 octo systemd[2171]: Starting Portal service (GTK+/GNOME implementation)... maj 13 23:46:05 octo xdg-desktop-portal-gtk[6937]: /usr/local/libexec/xdg-desktop-portal-gtk: error while loading shared libraries: libgnome-desktop-3.so.18: cannot open shared object file:> maj 13 23:46:05 octo systemd[2171]: xdg-desktop-portal-gtk.service: Main process exited, code=exited, status=127/n/a maj 13 23:46:05 octo systemd[2171]: xdg-desktop-portal-gtk.service: Failed with result 'exit-code'. maj 13 23:46:05 octo systemd[2171]: Failed to start Portal service (GTK+/GNOME implementation). ...skipping... ● xdg-desktop-portal-gtk.service - Portal service (GTK+/GNOME implementation) Loaded: loaded (/usr/local/lib/systemd/user/xdg-desktop-portal-gtk.service; static; vendor preset: enabled) Active: failed (Result: exit-code) since Wed 2020-05-13 23:46:05 CEST; 11min ago Process: 6937 ExecStart=/usr/local/libexec/xdg-desktop-portal-gtk (code=exited, status=127) Main PID: 6937 (code=exited, status=127) maj 13 23:46:05 octo systemd[2171]: Starting Portal service (GTK+/GNOME implementation)... maj 13 23:46:05 octo xdg-desktop-portal-gtk[6937]: /usr/local/libexec/xdg-desktop-portal-gtk: error while loading shared libraries: libgnome-desktop-3.so.18: cannot open shared object file:> maj 13 23:46:05 octo systemd[2171]: xdg-desktop-portal-gtk.service: Main process exited, code=exited, status=127/n/a maj 13 23:46:05 octo systemd[2171]: xdg-desktop-portal-gtk.service: Failed with result 'exit-code'. maj 13 23:46:05 octo systemd[2171]: Failed to start Portal service (GTK+/GNOME implementation). 

you will see that the problem is that libgnome-3.so.18 is missing, and it is not shipped with 20.04, and can not be installed.

The fix:

We just sym-link it…

$ cd /usr/lib/x86_64-linux-gnu $ sudo ln -s libgnome-desktop-3.so libgnome-desktop-3.so.18 

Now the service can start. It seems to be a dependency issue.