SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hence my question, until the FUD stops. Which it probably never will. It seems the question of the thread is answered by reality. I have been using slacklive with Plasma 5.13 in a VM. Very responsive and bug free and it seems amongst the vocal, the sane ones, that the issues of stability, performance, mentioned before and in other threads are solved. My opinion means crap, but from my observations Plasma 5.13 is ready as is. It is the Plasma I have had hopes of becoming what it is, and to work as flawlessly as it does in a VM and the speed it does with my hardware amazes me.
Why you test Plasma5 on a virtual machine?
I hope you read the past Poprocks experiences who tell us that testing for months in a VM that Plasma5 has a questionable value.
Maybe you do not trust it yet to live on bare metal? At least you can make an 8GB USB stick with the liveslack and test it on real hardware.
Last edited by ZhaoLin1457; 08-02-2018 at 03:37 AM.
Did you expect me to read this entire forum and its thousands of threads, looking respectful even for your posts made 10 years ago?
I joined this forum 6 months ago and is not my fault that you or your minions do not bothered to make a page in whatever site, explaining your precious points of view on those important aspects.
Last edited by ZhaoLin1457; 08-02-2018 at 03:47 AM.
Did you expect me to read this entire forum and its thousands of threads, looking respectful even for your posts made 10 years ago?
I joined this forum 6 months ago and is not my fault that you or your minions do not bothered to make a page in whatever site, explaining your precious points of view on those important aspects.
Next time I will not bother with a smiley then, OK?
If you state "We known certainly that Plasma5 depends hard on systemd-logind features for Wayland" without reference to where you obtained that knowledge it smells like dogma to me. You are repeating the half-truths and false facts that were refuted several years ago, but these opinions still echo in this and other forums.
In such a case it is better to set the record straight. No need to read 10 years of posts written by me, no need to read even one single post actually - just read the KDE documentation or do a simple Google search. I had the same misconception about KWin, Wayland and systemd and that got resolved 4 years ago. If you want to know more, scroll down on http://blog.martin-graesslin.com/blo...n-kwinwayland/ to where the "FAQ" starts and read from there. That FAQ resulted partly because of my own ranting at the time.
If you think this is about "Eric and his minions against the righteous people in this forum" then I suggest that you start growing up very fast.
What happens is something like in the attached screenshot after some random time, needed login/logout to return to normal
This happened to me, too. I purchased this laptop second hand so I attributed it to shit hardware (the laptop also freezes sometimes if I 'move it' the wrong way). It has only happened twice that I can remember, and I am unable to reproduce it because it seems it just happened randomly.
Quote:
Originally Posted by Darth Vader
and when I reboot the computer KWin disable its effects, claiming they crashed
Not here. Reboot fixed the problem, until it happened randomly again several weeks later. Hasn't happened since.
Lenovo x240
8GB RAM
Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz
lscpu
Code:
root@firefly:~ # lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 69
Model name: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz
Stepping: 1
CPU MHz: 1779.658
CPU max MHz: 2900.0000
CPU min MHz: 800.0000
BogoMIPS: 4988.49
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 3072K
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pln pts
lspci
Code:
root@firefly:~ # lspci
00:00.0 Host bridge: Intel Corporation Haswell-ULT DRAM Controller (rev 0b)
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b)
00:03.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev 0b)
00:14.0 USB controller: Intel Corporation 8 Series USB xHCI HC (rev 04)
00:16.0 Communication controller: Intel Corporation 8 Series HECI #0 (rev 04)
00:16.3 Serial controller: Intel Corporation 8 Series HECI KT (rev 04)
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I218-LM (rev 04)
00:1b.0 Audio device: Intel Corporation 8 Series HD Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 6 (rev e4)
00:1c.1 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 3 (rev e4)
00:1d.0 USB controller: Intel Corporation 8 Series USB EHCI #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation 8 Series LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 8 Series SATA Controller 1 [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 8 Series SMBus Controller (rev 04)
02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5227 PCI Express Card Reader (rev 01)
03:00.0 Network controller: Intel Corporation Wireless 7260 (rev 83)
root@firefly:~ # uname -a
Linux firefly.lan 4.14.51 #1 SMP Wed Jun 20 20:11:55 CDT 2018 x86_64 Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz GenuineIntel GNU/Linux
Throwing this information out there to have something to refer to in case it becomes a problem. That being said, I think KDE 5 Plasma is ready for -current. Most of the new features have been useful for me and it's actually displeasing going back to 14.2/KDE4 on my desktop.
Quote:
Originally Posted by brianL
If this thread goes on much longer, Peter Jackson will make a trilogy of it.
Worry not. If this thread only had a single post, he'd still stretch it into a trilogy and add a love story.
True, ZhaoLin, I did have a poor experience with 5.12 on bare metal. Like I said before though, I don't know how much of that was a function of my baloo5 index becoming corrupt.
My experience with 5.13 on bare metal has been nothing short of amazing.
I'm quite sorry to hear it's not working well with older Nvidia cards. KDE 4.2 did not run properly on my old Radeon 9250 at the time Slackware 13 came out either, so I made do with XFCE. That option was available and will continue to be.
I'm not going to express any more opinions about what should be done, because I don't know, and it's not my decision. But I do think stability issues should take precedence over compatibility with older graphics cards. If it doesn't run so well with those cards, the issue could always be documented in CHANGES_AND_HINTS. If it is unstable for everyone or has the potential to be at the drop of a hat, that is a bigger issues IMO.
However with an old GeForce 210 and NVIDIA-Linux-x86_64-340.107.run, the latest Plasma 5.13.3 is so sluggish and buggy that become unusable.
In the same system, the native KDE4 from -current works perfectly.
FWIW I'm writing this from an old T61P Thinkpad that cost me less than your 210 for the whole notebook (used of course). It has Core 2 Duo and nVidia Quadro and I'm in fresh unaltered liveslak Plasma5 latest with desktop effects showing FPS. Even with the default nouveau driver it, only upon loading of new large apps, like Firefox, drops below 61FPS. It does drop to around 20 but as soon as it's up goes right back to 61 where it is now as I type this. Hardly a thorough test and certainly merely anecdotal but it feels fine to me.
In fact it's so nice I'm going to go for a current hdd install. I like it.
Last edited by enorbet; 08-03-2018 at 11:28 PM.
Reason: typo
He wants to say that even Plasma5 works perfectly for months in a virtual machine (like you claim yourself), in your real box it can still present issues, like @Poprock experiences demonstrated.
How we are interested to find bugs on the Plasma5 for Slackware (and not OpenSUSE, Kubuntu, Arch or whatever other distro), probably is much better to test it on bare metal.
To curb the outrage of the three people who don't really understand how this works, I set up a -current box and installed Plasma 5 from Alien Bob's ktown repository.
Unsurprisingly, the spacing between desktop icons hasn't changed, the KWin alt-tab timeout is the same etc. -- tl;dr it's the same damn software that works exactly the same, except in a pure and holy environment. The only two major differences in the environment (i.e. eudev and ConsoleKit2) didn't seem to make any difference since (again, unsurprisingly) KDE is one of the main things that are ran against CK2 so upstream gets bug reports quite quickly, and eudev is regularly used by a lot of other projects and it's very well-maintained.
I'll try to set it up on a box with an NVidia driver next week -- that's my daily driver, but I have a spare hard drive -- and see if there's anything interesting happening there. Unfortunately, I can't say much about daily usage because I prefer to avoid -current on my production machines (it's great, but when a customer calls me at 9 AM about a bug, the last thing I want to tell them is can you call me in half an hour or so, I thrashed my -current installation).
So by way of update in relation to how I had been saying 5.13 has been working flawlessly on bare metal, compared to 5.12 - that remains MOSTLY true. The only issue that has cropped up pertains, once again, to that old favourite of mine: baloo.
Everything was working swimmingly for about two weeks, until a print-to-file operation from Seamonkey caused baloo to crash after it choked on the PDF. Baloo never really recovered after that, even after removing the "offending" file, as I'm guessing the database became corrupt once again. That's the main problem with Baloo IMO - it seems to have virtually no sane database recovery or error handling operations.
Anyway, I deleted the 'index' and 'index-lock' files again, and set 'only basic indexing=true' and now the database is only tracking filenames. It rebuilt within seconds. I really have a feeling, as AlienBob has indicated in the past, disabling Baloo monitoring the content of files will prevent further issues. I really didn't want to have to deviate from the defaults though.
I noticed that AlienBob recently disabled Baloo in the KDE4 LiveSlak on git. Perhaps that should be one of the few exceptions made to Slackware maintaining application defaults if Pat does decide to ship Plasma5 with mainline Slackware, and baloo should either be disabled or set to 'only basic indexing=true' by default.
I noticed that AlienBob recently disabled Baloo in the KDE4 LiveSlak on git. Perhaps that should be one of the few exceptions made to Slackware maintaining application defaults if Pat does decide to ship Plasma5 with mainline Slackware, and baloo should either be disabled or set to 'only basic indexing=true' by default.
I disabled it on the KDE4 Live image just like I am doing it since the beginning for the Plasma5 Live image. It is virtually useless to have Baloo start indexing the same files again, every time you start the Live OS. In the case without persistence, that Baloo index is wiped the moment you shutdown and the same indexing happens again after reboot. Waste of CPU cycles.
For what it is worth, I haven't had any problems with the latest ktown build on any of systems I have had the opportunity to try it on.
System 1:
Asus B350M-A with Ryzen 2400G using built-in graphics. Running -current and 4.17.14 kernel.
I am running 4.17 since 4.14 doesn't have AMDGPU support for Raven Ridge CPUs.
System 2:
HP Z420 with a Xeon E5-1620 and 6GB nVidia GTX 1060. Tested with latest Slackware Live. Tried with both Nouveau and nVidia 396.51 drivers.
System 3:
HP 8770W Laptop with AMD FirePro M4000. Tested with latest Slackware Live.
System 4:
Gigabyte z87x-ud3h with a i5-4440 and 4GB Nvidia GTX 970. Tested with latest Slackware Live. Nouveau driver.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.