#Lysia release is really close now. So we managed to spin the latest RC for our Plasma5 (KDE) edition. @oberon did a great job to tweak the most out of it.
Our KDE edition provides the powerful, mature and feature-rich Plasma 5.18 desktop environment with a unique look-and-feel, which we completely re-designed in 2020.
full set of Breath2-themes includes light and dark versions
animated splash-screen
Konsole profiles
Yakuake skins and many more little details.
We have rounded off text editor Kate with some additional color schemes and offer Plasma-Simplemenu as an alternative to the traditional Kickoff-Launcher.
With a wide selection of latest KDE-Apps 20.04 and other applications Manjaro-KDE aims to be a versatile and elegant environment ready for all your everyday needs.
@philm are those of us that received the last 2 sets of testing updates going to automatically get the updates from this RC build? If not no biggy. Thanks
I am afraid of the "unstable" because I am a novice, but excellent news!
In itself it is a great satisfaction to be able to configure everything in our own way and thus be more productive. If someone uploads screenshoots of the changes, I will be grateful.
Very good work, this .iso has some really good defaults and polished to shine!
Few things still deserve fix / look:
After first boot - it still takes about minute or more of looking at black screen on HDD (on SSD it's little faster, but still a lot of black screen for no apparent reason)...That's real shame, because it's only KDE edition which acts that way to my knowledge, and no other DE Manjaro edition does same...
There must be something wrong with initial setup of Manjaro KDE specific things, please fix it.
It makes so much more sense to use as default:
/etc/makepkg.conf
PKGEXT='.pkg.tar.zst'
Not sure on options though, but with just changing extension - it's insanely much faster to make packages, especially if it's some big build, like WPS office for example.
Surely package file size is somewhat bigger, but speed is not even close in comparison!
@oberon more of a question, than anything...As someone heavily invested in audio, i've noticed that KDE editions, compared to let's say your previous Deepin one has: /etc/sysctl.d/50-max_user_watches.conf
fs.inotify.max_user_watches = 16384
According to realtimeconfigquickscan this is one of those things that can't be good for audio, unless...(Manjaro Deepin for example had no 50-max_user_watches.conf present)
Checking checking sysctl inotify max_user_watches... >= 524288 - good
Is there any particular reason to use this value specifically in KDE? If not, maybe we could follow other editions which are little more audio friendly by default?
Rest of settings from this script and audio/video use in general may be questionable for average user, no doubts, but that particular settings i'm not sure
Why Balena Etcher again...? We have established previously in lounge that it's not safe
Oh, i always build myself with makepkg -s to review changes manually and all that...
As i don't really trust AUR that much and like to prep my packages for doomsday.
I thought it's exactly same for pamac, but if it's conflicting then it's fine..
This morning, I installed a kde-based system using architect using test repositories to test the RC branch. At the moment, everything is fine, if there are problems, I will let you know, thanks.
VM was fine, but on real HW, I could not get the ISO to boot to a graphical environment.
With Free Drivers, I saw SDDM start, I saw a cursor, and the Enjoy the Simplicity splash screen, and it hung there, and I had to hard power-off. I could not get to a TTY.
With Non-free Drivers, it seemed as if I got less far. I saw [ OK ] Started TLP System Startup/Shutdown and it appeared to hang, but from there I was able to Ctrl Alt F4 to a TTY where I could systemctl poweroff.
/proc/sys/fs/inotify/max_user_watches
This specifies an upper limit on the number of watches that can be created per real user ID
Listen uses inotify by default on Linux to monitor directories for changes. It's not uncommon to encounter a system limit on the number of files you can monitor. For example, Ubuntu Lucid's (64bit) inotify limit is set to 8192.
The issue
When dropbox or guard says like:
Unable to monitor filesystem Please run: echo 100000 | sudo tee /proc/sys/fs/inotify/max_user_watches and restart Dropbox to correct the problem.
No space left on device - Failed to watch "…": The user limit on the total number of inotify watches was reached or the kernel failed to allocate a needed resource. (Errno::ENOSPC)
Is it safe to raise that value and what would be the consequences of a too high value?
Yes, it's safe to raise that value and below are the possible costs [source]:
Each used inotify watch takes up 540 bytes (32-bit system), or 1 kB (double - on 64-bit) [sources: 1, 2]
This comes out of kernel memory , which is unswappable.
Assuming you set the max at 524288 and all were used (improbable), you'd be using approximately 256MB/512MB of 32-bit/64-bit kernel memory.
Note that your application will also use additional memory to keep track of the inotify handles, file/directory paths, etc. -- how much depends on its design
To see current value do
cat /proc/sys/fs/inotify/max_user_watches
But we probably want it highish. I see recommends at ex: 524288
From my limited research I might be comfortable with either 1/2 (262114) or 1/4 (131072) as well.
Based on some bug reports - 128k seems to be ceiling .. or floor.. for some. Though I guess it all depends on amount of stored data. If the above is to believed though, maybe setting a maximum of 128/256mb for kernel to monitor files is enough until proven otherwise.
(and yes though - whatever decided, this shouldnt be a DE-specific consideration.)
This lot of course was on the 19.0 ISO, so nothing has changed in that regard. It did exactly the same thing in Live environment but once installed, all Breath2 Konsole themes are available. EDIT - you can actually try them in live environment too. right click in the konsole terminal window and edit the profile.
@oberon & @bogdancovaciu I am not overly impressed with the latest iteration of the Breath2 Konsole themes. Feel free to carry on butchering them as I said all along you can do what you like with them but it would have been nice to have been involved in the discussions if there were any about such changes.
I'll keep my own going forward stored in my local folder for use with whichever distribution I see fit. I know there were compromises with it but on balance the new version has introduced far worse issues instead. You can deal with the mess yourselves because I won't be contributing anything further since you failed to ask for my input over the changes to my work.
I am sorry for the bad procedure. My fault, I should have contacted you first.
Yesterday someone in the team noticed that alsamixer was completely unusable with breath2 terminal colours and @bogdancovaciu kindly offered to take a look at the schemes. He didn't even know it was your contribution - my fault again that I didn't communicate that.
In any case apparently he found a few more issues with the way the colours where defined and uploaded his fix to the repo which I just quickly checked and packaged. To me the result looked great and more or less like before in general...
Sorry again for the bad miscommunication!
I'd hope that there could still be an exchange between the two of you about the problems of thre color-scheme and what was - or apparently still is - broken...
Thank you
