This is a more a DE question. But also a theroy. Are gtk3 DE starting to become more of a issue to used due to GNOME lack of consolekit support? If this is true. I wonder if the same issue will be in qt5. Or all this depend on the developer?

My mind went out to wonderland to much. Maybe being a little to concern to early.

Yes, right, its basically up to the developers.I try to answer regarding gnome.The bottleneck is systemd's logind.As of now, the is no true equivalent to logind as alternative, but consolekit2 is heading towards implementing kind of logind replacement. Historically, consolekit was the precursor of logind, but logind is for various reasons difficult to replicate.Consolekit2 is a forked and further developed version of unmaintained consolekit.So the short answer is, gnome devs decided to remove consolekit support couple of months ago.Their code doesn't support it any longer afaik. If someone was keen on patching in ck2 support, feel free to do.

I just installed this last night and I am at a loss of words. It was super fast, worked right out of the box. I started converting all my gentoo boxes over to this distro. Again I really appreciate your hard work on the switch from systemd to openrc and giving me a choice of init systems once more.

Not sure what I can do to help but let me know if there is anything I can do.

# if openrc should make use of /etc/modules-load.d# systemd places stuff thereuse_modules_load_d=false

This means, openrc will read conf files in /etc/modules-load.d and will write /etc/conf.d/modules at every boot. if set true. So it basically loads modules automatically, that are provided by kernel extra packagesIt is deactivated by default, but it should work well except for hybrid cards eventually.Enthusiasts can test by setting the switch to true, but please report back any errors.

# if openrc should make use of /etc/modules-load.d# systemd places stuff thereuse_modules_load_d=false

This means, openrc will read conf files in /etc/modules-load.d and will write /etc/conf.d/modules at every boot. if set true. So it basically loads modules automatically, that are provided by kernel extra packagesIt is deactivated by default, but it should work well except for hybrid cards eventually.Enthusiasts can test by setting the switch to true, but please report back any errors.

This is not working for my b43 module I need to load. I have blacklisted wl module and "unblacklisted" b43 in /etc/modprobe.d/linux41-broadcom-wl.conf. In /etc/modules-load.d/modules.conf I put b43. And my /etc/conf.d/modules contains a single line: use_modules_load_d=true. The /etc/conf.d/modules file is being generated at each boot, copying the old file to /etc/conf.d/modules.lastboot.

I can load the b43 with modprobe b43 and wifi works fine.

I am using Manjaro OpenRC xfce (The one just created by aaditya) and my updates are all current.

Hi Artoo, I'm using the KDE Openrc version from some days and I'm more than happy, also if I have to tune some aspects. Anyway, some considerations.First: I did an error voting and I'm using eudev, not udev, a click error; sorry

Second: I got some little problems, almost all solved and they are:1) I'm not able to startup pulseaudio as standard service (I read and tried all the options in the thread about it, but nothing), anyway, I was able to start it with the "Startup and Program" service in System Settings, so no problem, but strange2) Wine emulation is slower and more CPU crunching than with the standard systemd Manjaro KDE version (I'm till using it as my production OS), and I'm not able to understand why: all look like identical3) After the installation (KDE minimal the last version) the menu icon wasn't visible, and 2 reboot was needed4) Plasma 5 seems to be slower to open and close the windows, but I must profile the time better, this is simply an impression5) The upgrades are aligned with the standard Manjaro upgrade or there is a delay?

Just to inform you, but nothing so terrible and my BEST compliments for the great work!

I'm using a luks crypted disk with btrfs and no problems. In the next days I'll install also all the other programs that usually use and I'll do some deeper tests, but all seems to work fine.

If needed, I may manage some tests, I can install and I'll installa testing environment.

Good works also if its not yet ready for a "standard user", IMHO. I'll try also the xfce version, just cause I'm curious, but I like too much the Plasma environment

@dxrobertson, I did modprobe b43 right after installing and had no problems.

I think the recent kernels addressed some issue with the b43 module . My MacBook 7,1 broadcom 4322 chip suddenly started working out-of-the-box again. Earlier it needed pulling the sta driver from AUR on Arch Linux or installing the module from the main repos here in Manjaro.

On my side I would like to applaud the openRC endeavor for Manjaro. The Gentoo-converted packages work flawlessly and together with the Manjaro/Arch base are how an openRC distro should work, I think - simple dependency resolution with sane syntax and output (hail pacman!) + PKGBUILDs. The only minor problem I had was the openGL provider setter through mhwd (Gentoo uses eselect for that, so there is not much difference, though eselect is somewhat 'canon') and dhcpcd not being enabled through rc-update on startup after install (no internet connection, therefore).

The relative slowness may be a result of systemd libs still present on the system.Most arch packages are compiled with some systemd feature enabled.

Relatively to my gentoo on the same machine, yes, it tends to be a wee bit slower, however, my gentoo packages are also cpu optimized etc..., as opposed to generic arch/manjaro settings.

A long term goal would be to eliminate libsystemd, and to have a systemdless package base, which could also serve to reorganize swapping udev components. Its atm all pretty much libsystemd depend, instead of eg libudev, but this can only be addressed when there is some new needed infrastructure available.It is nearly impossible to maintain currently a full package set by just one dev.

The relative slowness may be a result of systemd libs still present on the system.Most arch packages are compiled with some systemd feature enabled.

Relatively to my gentoo on the same machine, yes, it tends to be a wee bit slower, however, my gentoo packages are also cpu optimized etc..., as opposed to generic arch/manjaro settings.

A long term goal would be to eliminate libsystemd, and to have a systemdless package base, which could also serve to reorganize swapping udev components. Its atm all pretty much libsystemd depend, instead of eg libudev, but this can only be addressed when there is some new needed infrastructure available.It is nearly impossible to maintain currently a full package set by just one dev.