I use partition labels and Dolphin displays those names. Additionally the most commonly used and temporary file systems. like Optical and USB drives, I have designated in fstab and mounted to /mnt/fooX where "fooX" is the same as the partition label. Maybe this is just a workaround but I could never quickly get ANY File Manager to display where /run/media devices were actually located so I could do deeper work on them. Making certain that devices mounted in the traditional way and exactly as I instructed solved all of that.

One of the recent changes I absolutely hate about other distros is destroying even the setting of a root account password (depending instead totally on "sudo") and denying the use of root oriented actions like "kdesu" and actively preventing the launching of Dolphin in root mode.

Thanks for the post, Don't you know that hate will kill you. I use device names and expect the best device manager there is to work. If I was a developer KDF would have been fixed 4-5 yes ago and would stay fixed with each release. The problem is today's developers are using windows and just don't care about the Linux their running in v-box. Sorry to hear you're having problems using dolphin as root. I'm hoping Patrick or somebody else will fix KDF.

Just FTR I'm not having problems running Dolphin as root because my Main is Slackware. The problems only exist in other distros that apparently want to be "Free Windows".

I don't agree that most, let alone all "today's developers are using windows". Linux dominates everywhere except SOHO Desktop and it is gaining slowly but steadily there, which is one of the reasons MS is so desperate to force the "upgrade" to Win10.

I'm still using Ktown so KDF still works for me but I tend to just use GParted, or "du" and "df" instead anyway. For specific graphical interfaces Slackbuilds includes xdiskusage, QDirStat, and JDiskReport as alternatives to KDF. Hope that helps.

That's great. I'm running slackware stable, current kde4 and now testing kde5(when I get them all updated) on a dozen computers.

Most, All. Now you're putting words in my mouth. I was paid to do windows from win-3 to win-2012. Please, no more windows.

Yes, kdf still mounts and unmounts drives, but kwikdisk and kdiskfree are no longer working together and kwikdisk no longer shows mount status or drive info. Using kde4 or kde3 will show you how bad kdf is broken. Please no more post, enough has been said. Thanks.

I've installed Slackware64 -current (via Alien Bob's slackware64-current-install-dvd.iso updated yesterday) in a test partition alongside Slackware64 14.2 to give vtown a try.

It seems to have installed correctly. I've tried only a few applications, but what I've tried is working well.

This is really nice. Big thanks to Pat and Eric for Slackware with Plasma5!

TKS

Ok I figured out the time issue - in virtualbox if you enable Hardware Clock in UTC Time, the clock in your VM whatever OS running will be wrong, you uncheck it and reboot the VM, the time in the VM is then correct. So yea, don't check enable Hardware Clock in UTC Time.

VTown works great for me, so far I haven't come across any issues, based on my usage of course. Thanks to all involved in bringing Plasma 5 to Slackware.

Probably not a good idea to revisit TDE after playing with Plasma5. Maybe it is a good thing TDE isn't really in slackbuilds and Plasma is default because the, I would have another tough decision .

So nothing to do with authentication/systemd, just a simple PATH issue, thanks

One thing I noticed was kwin_x11 was running rampant with CPU cycles. I restarted X, and the issue went away. In the research I've found, I've noticed that this is an issue. (There are about 5-10 reddit threads about it.) Anyone else notice it? What causes it?

Here's one discussion: https://www.reddit.com/r/kde/comment...eb2x&context=3

Seems like runaway kwin_x11 processes is an issue.

I think I know why my desktop timezone is messed up. And you are right, it does not having to do with systemd.

So I deleted all time-related configuration files in /etc (localtime, localtime-copied-from, timezone, hardwareclock) then rerun Slackware's timeconfig and select the preferred timezone. This creates a timezone file /etc/localtime and one symlink /etc/localtime-copy-from. On the desktop I got the clock correctly but with UTC as the timezone. But the date command shows the correct time and timezone. So KDE thinks my local timezone is UTC but with local clock. I removed /etc/localtime and /etc/localtime-copied-from once again and the desktop now shows the UTC clock with the UTC timezone, same as date command.

Then I use KDE date/time to configure my clock. It created two files, /etc/timezone and /etc/localtime. Now my desktop clock shows the correct clock and timezone, same with the output of date command.

Just wild guessing, is it maybe the symlink /etc/localtime-copied-from which makes KDE thinks that my local timezone is the UTC?

Additional info:
If I'm selecting "Hardware clock is set to local time" in timeconfig then KDE will assume my local time is the UTC time, hence the desktop will show UTC+X for my real timezone time. Using "Hardware clock is set to UTC" in timeconfig fixes this.

Try enabling the Killer Mode on /etc/elogind/logind.conf
I use it since long time with no issues regarding runaway processes - and I bring up even the PipeWire daemon, which have no ways to auto-shutdown alone.

BUT, there is a big caveat which had been made Mr. Hameleers to not enable it by default: with this configuration the elogind will kill any user processes on logout, then there will be no way to use properly tmux or screen for your unprivileged users.

So, if you intend also to tmux/screen in your computer as unprivileged user, I will recommend you to create and use a separate user for remote logins, and to instruct elogind to leave it alone with the option "KillExcludeUsers" and/or "KillOnlyUsers" for example, something like:
Also, I believe that another thing for you to consider is this particular post from the requests' thread:

https://www.linuxquestions.org/quest...ml#post6182882

2 members found this post helpful.

No sure what seem to be going on with time here. I am not seeing any issues with time. This computer's hardware time is set to UTC, Slackware is set to my local timezone, KDE Plasma 5 (vtown) shows correct time. I run the NTP daemon using time servers from my region.

This computer is the host for VirtualBox. I have six Slackware, two other Linux (Neon) and one Windows 10 guest machines. All with the Hardware Clock in UTC Time checked. All guest machine times match that of the host. If fact it's the opposite of what @Jeebizz describes.

In my case, the VM shows the incorrect time if Hardware Clock in UTC Time is unchecked and if checked the correct time.

Example: Host time: 19:54 local time
Guest time with box checked 19:54
Guest time with box not checked: 03:54

Question, the short version, what keeps kde4 from running once all the Vtown files have been removed and kde4 re-installed?

Long version, I've done this twice (actually, two and a half, at this point).
Removed all traces of kde4. Installed Vtown. Ran it for a couple of days.
Decided to go back to kde4.
Removed all traces of Vtown including the configuration files its scatters all over hell and gone. Rebooted.
Re-installed all the kde4 files. Rebooted.
Ran startx and the splash screen appeared for a second and then disappeared and a message appeared that kde could not start and to check the installation.
The first time this happened I looked around, but couldn't find the problem and since I hadn't done a fresh install in a month or two, did so.
Kde4 ran fine.
Kept reading all the "excitement" about Vtown and tried it again.
Still don't see the need and wanted to go back to kde4.
Repeated the previous steps with the same results, i.e., kde4 won't run.
BTW, installing Vtown, both times, trashed the Xfce installation, but can be salvaged by re-installing the Xfce files.
I don't feel like doing another fresh install, so is there an way to get kde4 to run after removing Vtown?
Thanks.

you remove elogind and reinstall consolekit for kde4 ?
dbus ?

1 members found this post helpful.