The Lumina Desktop is part of the TrueOS project, a FreeBSD variant. I packaged version 1.4.0.p1 for Slackware and it is part of the Plasma5 variant of my Slackware Live Edition.
I noticed a while ago that Lumina would no longer start but it was low on my priority list to try and fix it.
Today I found the time to look into this, but a recompilation against the latest Qt5 and other libraries, altough error-free, would not make the Lumina Desktop start successfully: it will start to load, but then you’ll hear a beep and you’re dumped at the command prompt or at the graphical login screen without evidence of what happened.
A bit of research showed that apparently, Lumina stopped working on Linux with versions of Qt greater than 5.9 (gentoo discussion and lumina bug report). According to the developer Lumina works fine on FreeBSD, even with Qt 5.12, and the developer will not troubleshoot the Linux code according to what he posted in that bug report.
Therefore I am sorry to say (I really liked this light-weight Qt5 based Desktop Environment) that I will remove the lumina package from my slackware-current repository. If this issue ever gets fixed, I’ll be happy to re-add the package.
Long before the “letsencrypt” initiative, we already had another free and open Certificate Authority, called CACert.org. CACert is community driven, and uses ‘assurers’ who personally verify users’ identities, thereby building a “web of trust”. Unfortunately, the big players on the Internet (Google, Mozilla, Microsoft) have always refused to accept and incorporate the CACert root certificate into their browsers. Instead, after many years of imploring these companies to add CACert as a trusted Certificate Authority without any success, they spat in the face of the community and launched their own alternative for free SSL certificates: letsencrypt.
And therefore, even today, a site that uses a CACert-issued SSL certificate is flagged by browsers as untrustworthy. In my opinion. this refusal to accept a community-driven security initiative is nothing short of bullying.
My own server, bear.alienbase.nl, uses a CACert-issued certificate. Folks, it is secure to use https on it! Even when Chrome or Firefox says it is not. So, how to fix that bogus warning message?
For Firefox, Chrome and for the OS in general: import the CACert certificates as follows:
First add the CACert root and class3 certificates to your Linux system.
As the root user you download the two .crt files, copy them to /etc/ssl/certs and generate openssl hashes (I used backslashes to indicate that some lines are wrapping because the text would otherwise not be visible on this page):
Click on the link for “Class 1 PKI Key” called “Root Certificate (DER Format)“. You will see the text “You have been asked to trust a new Certificate Authority (CA). Do you want to trust ‘CA Cert Signing Authority’ for the following purposes?“. At a minimum you must check the box to the left of “Trust this CA to identify web sites” before importing the certificate.
Then do the same for the “Class 3 PKI Key” called “Intermediate Certificate (DER Format)” a bit lower on the page.
I wish I were better with words. There’s thoughts that strike a note in your heart and mind, but I would not be able to express these thoughts on paper so that they deliver the needed punch. That was my first thought when I read this open letter on the Linux Kernel Mailing List (LKML): https://lkml.org/lkml/2014/8/12/459 . The text is written by a longtime Debian user who feels deeply betrayed by its board of leadership. The emotions he penned down are exactly mine. Thank you, Christopher Barry. This was of course not the first eloquently written rant, but I hope it sparks a discussion in Kernel Land about what is happening in User Land, and whether they can afford to keep looking the other way (with the public exception of Linus and some others).
One word. One demon. systemd.
What relation does Christopher’s rant have to Slackware? After all, it’s Debian that got the flak, and in the comments section people indicate they intend to switch to Gentoo… forgetting that Slackware is a good systemd-free alternative (but hey! this automatic dependency resolution thingie that makes life so comfortable in Gentoo is not part of Slackware either).
Of course, the ConsoleKit successor systemd-logind, written by the same team that gave us all the *Kit crap, depends on PAM which we also do not have in Slackware. One of the fellow core developers in Slackware, who is intimately familiar with the KDE developers community, has heard from multiple sources that KDE is moving towards a hard dependency on systemd (probably because they are going to need the functionality of systemd-logind). We all know what that means, folks! It will be the day that I must stop delivering you new KDE package releases for Slackware. That’ll be the day.
Dear visitor, you seem to be using an Ad Blocker. Please consider whitelisting 'Alien Pastures'. I use the revenue from displaying ads (small as it is) to keep this site running. Thanks!