How I broke KDE Plasma by changing my shell (and also writing a bad script)

My friends, I’d like to tell you the story of how I spent Monday morning. I had a one-on-one with my manager and a team coffee break to start the day. Since the weather was so nice, I thought I’d take my laptop and my coffee out to the deck. But when I tried to log in to my laptop, all I had was the mouse cursor. Oh no!

I did my meeting with my manager on my phone and then got to work trying to figure out what went wrong. I saw some errors in the journal, but it wasn’t clear to me what was wrong.

Aug 31 09:23:00 fpgm akonadi_control[5155]: org.kde.pim.akonadicontrol: ProcessControl: Application '/usr/bin/akonadi_googlecalendar_resource' returned with exit
code 253 (Unknown error)
Aug 31 09:23:00 fpgm akonadi_googlecalendar_resource[6249]: QObject::connect: No such signal QDBusAbstractInterface::resumingFromSuspend()
Aug 31 09:23:00 fpgm akonadiserver[5159]: org.kde.pim.akonadiserver: New notification connection (registered as Akonadi::Server::NotificationSubscriber(0x7f4d9c0
10140) )
Aug 31 09:23:00 fpgm akonadi_googlecalendar_resource[6249]: Icon theme "breeze" not found.
Aug 31 09:23:00 fpgm akonadiserver[5159]: org.kde.pim.akonadiserver: Subscriber Akonadi::Server::NotificationSubscriber(0x7f4d9c010140) identified as "AgentBaseC
hangeRecorder - 94433180309520"
Aug 31 09:23:01 fpgm akonadi_googlecalendar_resource[6249]: kf5.kservice.services: KMimeTypeTrader: couldn't find service type "KParts/ReadOnlyPart"  
                                                           Please ensure that the .desktop file for it is installed; then run kbuildsycoca5.

What broke

Before starting the weekend, I had updated all of the packages, as I normally did. But none of the updated packages seemed relevant. I hadn’t done any weird customization. As “pino|work” in IRC and I tried to work through it, I remembered that I had added a startup script to set the XDG_DATA_DIRS environment variable in the hopes of getting installed flatpaks to show up in the menu. (Hold on to this thought, it becomes important again later.)

I moved it out of the way to get things cleaned up (by removing the plasma-org.kde.plasma.desktop-appletsrc and plasmashellrc files). Looking at the script, I realized I had a syntax error (a stray single quote ended up in there) while trying to set XDG_DATA_DIRS. Yay! That’s easy enough to fix.

Why it broke

Except it was still broken. It was broken because I referred to XDG_DATA_DIRS but it was undefined. Why didn’t it inherit it? Ohhhhh because fish doesn’t use the /etc/profile.d directory.

So remember how I did this in order to get Flatpaks to show up in my start menu? I could have sworn they did at some point. It turns out that I was right. The flatpak package installs the scripts into /etc/profile.d, which fish doesn’t read. So when I switched my shell from Bash to fish a while ago, those scripts never ran at login.

How I “fixed” it

To fix my problem, I could have written scripts that work with fish. Instead, I decided to take the easy route and change my shell back to bash. But in order to keep using fish, I set Konsole to launch fish instead of bash. Since I only ever do a graphical login on my desktop, that’s no big deal, and it avoids a lot of headache.

The bummer of it all is that I lost some of the configuration I had in the files I deleted. But apparently the failed logins made it far enough to modify the files in a way that Plasma doesn’t like. At any rate, I didn’t do much customization, so I didn’t lose much either.

[solved] Can’t log in to KDE on Fedora 31

Earlier today, I ran dnf update on my laptop, as I do regularly. After rebooting, I couldn’t log in. When I typed in my user name and password, it almost immediately returned to the login screen. Running startx from the command line failed, too. I spent an hour or two trying to diagnose the problem. There were a lot of distracting messages in the xorg log.

The problem turned out to be that the startkde command was no longer on my machine. It seems upgrading from version 5.16 to 5.17 of the plasma-workspace package removes startkde in favor of startplasma-x11. Creating a symlink fixed it as a workaround.

This is reported as bug #1785826, and I’m sure Rex and the rest of the Fedora KDE team will have a suitable fix out soon. In the meantime, creating a symlink appears to be the best way to fix it.

Why the symlink works

When an X session starts, it looks in a few different places to see what should be run. One of those places is /etc/X11/xinit/Xclients. This file checks for a preferred desktop environment. If one isn’t specified, it works through a list trying to find one that works. It does this by looking for the specific desktop environment’s executable.

Since startkde no longer exists, it had no way of checking for KDE Plasma. I don’t have any other desktop environments installed on this machine, so there was no other desktop environment to fallback to. I suspect if GNOME were installed, it would have logged me into GNOME instead, at least when running startx.

So another fix would be to replace instances of startkde with startplasma-x11 in the Xclients file (similarly if you have that file in your home directory). However, this leaves anything else that might check for the existence of startkde in the lurch. (I don’t know if anything does).

There’s probably more options for fixing it out there; this is very much not my area of expertise. I’d have to say that this was the most frustrating issue I’ve had to debug in a long time, in part because it took me a while to even know where the problem was. The fact that moving my ~/.kde directory didn’t result in a new one being created told me that it was pretty early in the process.

What distractions did I see?

In trying to diagnose the issue, I got distracted by a variety of error messages:

  • xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
  • /dev/fb0: permission denied
  • gkr-pam: unable to locate daemon control file
  • pam_kwallet5: couldn't open file

The Linux desktop is not in trouble

Writing for ZDNet earlier this month, Steven J. Vaughan-Nichols declared trouble for the Linux desktop. He’s wrong.

Or maybe not. Maybe we’re just looking at different parts of the elephant. sjvn’s core argument, if I may sum it up, is that fragmentation is holding back the Linux desktop. Linux can’t gain significant traction in the desktop market because there are just so many options. This appeals to computer nerds, but leads to confusion for general users who don’t want to care about whether they’re running GNOME or KDE Plasma or whatever.

Fragmentation

I’m sympathetic to that argument. When I was writing documentation for Fedora, we generally wrote instructions for GNOME, since that was the default desktop. Fedora users can also choose from spins of KDE Plasma, LXQt, Xfce, plus can install other desktop environments. If someone installs KDE Plasma because that’s what their friend gave them, will they be able to follow the documentation? If not, will they get frustrated and move back to Windows or MacOS?

Even if they stick it out, there are two large players in the GUI toolkit world: GTK and Qt. You can use an app written in one in a desktop environment written in the other, but it doesn’t always look very good. And the configuration settings may not be consistent between apps, which is also frustrating.

Corporate indifference

Apart from that, sjvn also laments the lack of desktop effort from major Linux vendors:

True, the broad strokes of the Linux desktop are painted primarily by Canonical and Red Hat, but the desktop is far from their top priority. Instead, much of the nuts and bolts of the current generation of the Linux desktop is set by vendor-related communities: Red Hat, Fedora, SUSE’s openSUSE, and Canonical’s Ubuntu.

I would argue that this is the way it should be. As he notes in the preceding paragraph, the focus of revenue generation is on enterprise servers and cloud. There are two reasons for that: that’s where the customer money is and enterprises don’t want to innovate on their desktops.

I’ll leave the first part to someone else, but I think the “enterprises don’t want to innovate on their desktops” part is important. I’ve worked at and in support of some large organizations and in all cases, they didn’t want anything more from their desktops than “it allows our users to run their business applications in a reliable manner”. Combine this with the tendency of the enterprise to keep their upgrade cycles long and it makes no sense to keep desktop innovation in the enterprise product.

Community distributions are generally more focused on individuals or small organizations who may be more willing to accept disruptive change as the paradigm is moved forward. This is true beyond the desktop, too. Consider changes like the adoption of systemd or replacing yum with dnf: these also appeared in the community distributions first, but I didn’t see that used as a case for “enterprise Linux distributions are in trouble.”

What’s the answer?

Looking ahead, I’d love to see a foundation bring together the Linux desktop community and have them hammer out out a common desktop for everyone. Yes, I know, I know. Many hardcore Linux users love have a variety of choices. The world is not made up of desktop Linux users. For the million or so of us, there are hundreds of millions who want an easy-to-use desktop that’s not Windows, doesn’t require buying a Mac, and comes with broad software and hardware support.

Setting aside the XKCD #927 argument, I don’t know that this is an answer. Even if the major distros agreed to standardize on the same desktop (and with Ubuntu returning to GNOME, that’s now the case), that won’t stop effort on other desktops. If the corporate sponsors don’t invest any effort, the communities still will. People will use whatever is provided to them in the workplace, so presenting a single standard desktop to consumers will rely on the folks who make the community distributions to agree to that. It won’t happen.

But here’s the crux of my disagreement with this article. The facts are all correct, even if I disagree with the interpretation of some of them. The issue is that we’re not looking at the success of the Linux desktop in the same way.

If you define “Linux desktop” as “a desktop environment that runs the Linux kernel”, then ChromeOS is doing quite well, and will probably continue to grow (unless Google gets bored with it). In that case, the Linux desktop is not in trouble, it’s enjoying unprecedented success.

But when most people say “Linux desktop”, they think of a traditional desktop model. In this case, the threat to Linux desktops is the same as the threat to Windows and MacOS: desktops matter less these days. So much computing, particularly for consumers, happens in the web browser when done on a PC at all.

Rethinking the goal

This brings me back to my regular refrain: using a computer is a means, not an end. People don’t run a desktop environment to run a desktop environment, they run a desktop environment because it enables them to do the things they want to do. As those things are increasingly done on mobile or in the web browser, achieving dominant market share for desktops is no longer a meaningful goal (if, indeed, it ever was).

Many current Linux desktop users are (I guess), motivated at least in part by free software ideals. This is not a mainstream position. Consumers will need more practical reasons to choose any Linux desktop over the proprietary OS that was shipped by the computer’s manufacturer.

With that in mind, the answer isn’t standardization, it’s making the experience better. Fedora Silverblue and OpenSUSE Kubic are efforts in that direction. Using those as a base, with Flatpaks to distribute applications, the need for standardization at the desktop environment level decreases because the users are mostly interacting with the application level, one step above.

The usual disclaimer applies: I am a Red Hat employee who works on Fedora. The views in this post are my own and not necessarily the views of Red Hat, the Fedora Council, or anyone else. They may not even be my views by the time you read this.

Using the ASUS ZenBook for Fedora

I recently decided that I’d had enough of the refurbished laptop I bought four years ago. It’s big and heavy and slow and sometimes the fan doesn’t work. I wanted something more portable and powerful enough that I could smoothly scroll the web browser. After looking around for good Linux laptops, I settled on the ASUS ZenBook.

Installation

The laptop came with Windows 10 installed, but that’s not really my jam. I decided to boot off a Fedora 26 KDE live image first just to make sure everything worked before committing to installing. Desktop Linux has made a lot of progress over the years, but you never know which hardware might not be supported. As it turns out, that wasn’t a problem. WiFi, Bluetooth, webcam, speakers, etc all worked out of the box.

It’s almost disappointing in a sense. There used to be some challenge in getting things working, but now it’s just install and go. This is great overall, of course, because it means Linux is more accessible to new users and it’s less crap I have to deal with when I just want my damn computer to work. But there’s still a little bit of the nostalgia for the days when configuring X11 by hand was something you had to do.

Use

I’ve had the laptop for a little over a month now. I haven’t put it through quite the workout I’d hoped to, but I feel like I’ve used it enough to have an opinion at this point. Overall, I really like it. The main problem I have is that the trackpad has a middle-click, which is actually pretty nice except for when I accidentally use it. I’ve closed many a browser tab because I didn’t move my thumb far enough over. That’s probably something I can disable in the settings, but I’d rather learn my way around it.

The Bluetooth has been flaky transferring files to and from my phone. but audio is…well I’ve never found Bluetooth audio to be particularly great, but it works as well as anything else.

One other bit of trouble I’ve had is with my home WiFI. I bought a range extender so that I can use WiFi on the back deck and it to use the same SSID as the main router. The directions said you can do this, but it might cause problems. With this laptop, the WiFi connection becomes unusable after a short period of time. Turning off the range extender fixes it, and I’ve had no other problems on other networks, so I guess I know what I have to do.

One thing that really stood out to me is carrying it around in a backpack. This thing is light. I had a few brief moments of panic thinking I had left it behind. I’ve held lighter laptops, but this is a good weight. But don’t worry about the lightness, it still has plenty of electrons to have a good battery life.

Around the same time I bought this, I got a new MacBook Pro for work. When it comes to typing, I like the keyboard on the ZenBook way better than the new MacBook keyboards.

Recommendation

If you’re looking for a lightweight Linux laptop that can handle general development and desktop applications, the ASUS ZenBook is a great choice. Shameless commercialism: If you’re going to buy one, maybe use this here affiliate link? Or don’t. I won’t judge you.

KDE immediately returns to the login screen: one explanation

Earlier this week, I bought a new laptop. More on that once I’ve had a little more time to use it. But I wanted to share two things that I learned while setting it up. The first is straightforward: I really regret not putting effort into getting key configs (like users) into Ansible so that I didn’t have to do stuff by hands. The second requires some storytelling.

I installed Fedora 26 (KDE spin) and everything seemed good. I created accounts for my wife and me and then called it a night because I was tired. The next day, I wanted to get a little more configuration done, so I tried to log in. My password was accepted, but it immediately returned me to the login screen. So I logged in to a text console. That worked fine. I tried logging in to KDE as root. It worked. It had to be something about my account.

So I asked the trusty journal what was wrong. I saw messages like this:

Oct 05 18:04:44 holton sddm-helper[2770]: Starting: "/etc/X11/xinit/Xsession /usr/bin/startkde"
Oct 05 18:04:44 holton audit[2787]: AVC avc: denied { write } for pid=2787 comm="sddm-helper" name="bcotton" dev="dm-3" ino=5242881 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unco
Oct 05 18:04:44 holton sddm-helper[2787]: Could not open stderr to "/home/bcotton/.cache/xsession-errors"
Oct 05 18:04:44 holton audit[2787]: AVC avc: denied { write } for pid=2787 comm="sddm-helper" name="bcotton" dev="dm-3" ino=5242881 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unco
Oct 05 18:04:44 holton kernel: sddm-helper[2787]: segfault at 0 ip 00007fc1e8f97b1e sp 00007ffc7a29d1e0 error 4 in libc-2.25.so[7fc1e8f25000+1c7000]
Oct 05 18:04:44 holton audit[2787]: ANOM_ABEND auid=47703 uid=47703 gid=500 ses=5 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 pid=2787 comm="sddm-helper" exe="/usr/libexec/sddm-helper" sig=11 res=
Oct 05 18:04:44 holton sddm-helper[2787]: Opening the Xauthority file at "/home/bcotton/.Xauthority" failed
Oct 05 18:04:44 holton sddm-helper[2770]: pam_unix(sddm:session): session closed for user bcotton

I checked to make sure my home directory existed. It did.

I checked to make sure I could write to it. I could.

I turned off Selinux. No help.

A forum post suggested removing the sddm package and using kdm instead. It didn’t help.

I created a new user. It could log in. What was going on?

Well at one point, I noticed that when I did an ls -l on /home, my home directory showed a numeric group ID instead of a name. Ah ha! When I created the users, I used KDE’s user management GUI. It auto-created a group with a GID that matched the UID of the account. But I didn’t want that group, so I deleted it and made another group my default. But by that point, the home directory had already been created, so it was owned by the group that no longer exists.

After I changed the group ownership, it worked just fine. I should have just used the useradd command to begin with since I could have made it work the way I intended. Or I could have used a configuration management tool to do it for me. Maybe that will be my next project…

Fedora 24 upgrade

Fedora 24 was released last week, so of course I had to upgrade my machines. As has become the norm, there weren’t any serious issues, but I hit a few annoyances this time around. The first was due to packages in the RPMFusion repos not being signed. This isn’t Fedora’s fault, as RPMFusion is a completely separate project. And it was temporary: by the time I upgraded my laptop on Sunday night, the packages had all been signed.

Several packages had to be dropped by using the –allowerasing argument to dnf. Mostly these were packages installed from RPMFusion, but there were a couple of Fedora packages as well.

The biggest annoyance was that post-upgrade, I had no graphical login. I had to explicitly start the desktop manager service with:

systemctl enable kdm
systemctl start kdm

kdm had previously been enabled on both machines, but the upgrade nuked that in both cases. It looks like I’m not the only person to hit this: https://bugzilla.redhat.com/show_bug.cgi?id=1337546

And now, my traditional meaningless torrent stats!

Here’s my seeding ratios for Fedora 23:

Flavor i686 x86_64
KDE 16.2 35.6
Security 10.3 21.1
Workstation 30.9 46.7
Server 17.5 25.0

The “ratio ratio” as I call it is a comparison of seeding ratios between the two main architectures:

Flavor x86_64:i686
KDE 2.20
Security 2.05
Workstation 1.51
Server 1.43

So what does all of this tell us? Nothing, of course. Just because someone downloads a torrent that doesn’t mean they use it. Still, if we pretend that it’s a proxy for usage, all of the seeding ratios are higher than on the last release day. That tells me that Fedora is becoming more popular (yay!). 64-bit architectures are continuing to be a larger portion of the pie, as well.

Now that I’m starting to build a record of these, I can start reporting trends with the Fedora 25 release.

Changing my text editor

The great editor wars are over. Emacs is dumb and stupid and vi is the One True Editor. Well, actually, I use vim. Or I use gVim if I’m using a desktop environment. But still, I’ve staked out my position.

Until recently. I was getting really frustrated with the Markdown highlighting in gVim. It was usually good, but sometimes it would get confused. Plus, the fact that Ctrl+C, Ctrl+V, Ctrl+S, etc. didn’t work in a GUI was just jarring.

So I decided to give Kate a try. Kate is the “KDE Advanced Text Editor”, and since I already use KDE on my Linux machines, it seemed like a good place to start. I liked it so much that I installed on my MacBook Pro via MacPorts on a hotel WiFi connection (that was an overnight operation).

The better Markdown syntax support and word count features have made it my go-to for writing Opensource.com articles and other non-Blog-Fiasco content. I haven’t given it a try with LaTeX or DocBook yet, but I should. I still tend to use vim/gVim for code, in part because of inertia and in part because it’s often done over an SSH connection. I do like how Kate visually distinguishes between hard tabs and soft tabs when I work on Perl code, though.

Odd touchpad behavior in Fedora 22

A few days ago, the touchpad on my HP 2000 Notebook PC began acting up. It would jitter around a lot and insert phantom mouse clicks. My desktop ended up with approximately Avogadro’s number of Notes widgets. At first, I thought the touchpad was going bad. I resigned myself to a life of using a USB mouse, at least until I could buy a replacement.

As it turns out, though, it appears to be a software problem. On a whim, I opened up the KDE System Settings. When I selected “Touchpad” from the “Input Devices” menu, I saw a warning message that the saved settings did not match the current settings. Clicking “Apply” fixed…the glitch. Hopefully this helps if someone else comes across the issue. I didn’t file a bug because I don’t know what changed or how to reproduce it.

Using bookmark synchronization on Google Chrome for Linux and Mac

For a long time, I blamed the sluggish performance of the web browser on my Linux machine at home on the ancientness of the hardware.  However, when my much nicer Linux machine at work showed the same problem, I began to think maybe it was just Firefox.  I’ve been an avid Firefox user for many years, but my loyalty wavers when my browser can’t keep up with my keyboard.  Based on the advice of strangers on the Internet, I decided to give Google’s Chrome browser a try.

Chrome is still a maturing browser, but it is fast and capable.  There’s only one real drawback: bookmark synchronization.  With Firefox, I had been using Xmarks to synchronize my bookmarks, but that’s not currently available for Chrome.  In the “Early Access” builds of the Linux and Mac versions of Chrome, the bookmark sync that the Windows version has is available.  This syncs the bookmarks to your Google Docs account, which makes it rather handy.  However, synchronization is not enabled by default.  To enable it, you have to pass the –enable-sync option at launch time, which is easier said than done.  Fortunately, it’s not too terribly difficult.

Continue reading

Upgrading through yum, and how I feel about KDE 4

The Fedora Project wiki says that it’s possible to update to a new release using the Yum package manager, but that it isn’t recommended.  Normally, I’d heed the advice of those wiser than me and do an upgrade from DVD media.  Unfortunately, when I set up my desktop/server at home, I didn’t think my partitions through very well, so I figured a live upgrade was my best shot at not nuking /home.  My first step was to do a full backup of everything onto an external drive.  Protip: 28GB tarballs are awful — find a better way to do your backups.

After a few deep breaths, I started following the instructions at http://fedoraproject.org/wiki/YumUpgradeFaq.  The instructions are well-written, and I was able to follow them with nearly no problem.  When I got to the actual upgrade part, I got a few dependency errors, related to the redhat-artwork package.  Seriously?  Artwork is the holdup?  Well redhat-artwork refused to be anything but what was currently installed, so I figured I’d just un-install it and see what happened.  Normally, dependency hell prevents you from installing software; this time it prevented me from un-installing the package.  Well that’s just plain unacceptable.  After trying a few different combinations of packages to uninstall, I finally surrendered with `rpm -e –nodeps redhat-artwork`.  From there on out, the upgrade went smoothly.

So what’s so great about going from Fedora 7 to Fedora 9?  Well the main driving force was the fact that Fedora 7 was no longer getting new software, so if I wanted yum to automagically get Firefox 3 and Wine 1.0, then I needed a newer release.  I considered going to 8 and then to 9, but that seemed like a whole lot of extra work.  As it turns out, it didn’t really matter (although that may have helped my redhat-artwork issue, but maybe not).  Apart from that, there are two things I noticed right off the bat.  First, sudo now gives a more verbose prompt:

[1016 bcotton@boone /var/log ]$ sudo echo "wow Check out that informative prompt."
[sudo] password for bcotton:
wow Check out that informative prompt.

Have you ever been typing along and then you go to sudo and you forget what you need to do?  Now you get a friendly reminder.  It’s the little things like that, you know?

Of course, there’s also the second thing I noticed:  KDE 4.  When KDE 4 was released a few months ago, it was rather loudly touted on the internets.  I was interested to try it, but not interested enough to install it by hand, so I was initially rather excited to see KDE 4 when I logged in. The excitement didn’t last very long.  I am not a fan.

KDE 4 represents a significant change from KDE 3, including a much more eye-candyish look.  It is certainly a snazzy desktop, but the default UI settings aren’t all that great.  The default K-menu requires several more clicks to get to the application you want.  Toolbar widgets can’t be dragged into place, you have to right-click, select “Start Move of $widget”, lead it where you want it to go with the mouse, and then right-click and select “Stop Move of $widget”.  There are also fewer widgets (which will probably change as more people start using and developing for KDE 4), but it does support OS X widgets (at least the HTML ones).  It also seems to be less configurable than KDE 3.  This is apparently on purpose, since the code base isn’t as mature, so hopefully future releases will improve things.  I’m not displeased enough to switch to Gnome, but this will take some getting used to.