No systemd, no elogind, no consolekit, no dbus – what did I miss?

Many reviews of linux distros you may read tell you what you need  to have (systemd – elogind – consolekit, – dbus : SECD from now on) to use the distro.  It is rarely seen or heard whether you can have an effective graphical interface, a desktop, a window manager, and not use any of the above.  Sometimes for a rarely used or never used utility you need one of those monsters, but hardly ever anyone goes out of his way to tell you “this is the ONLY instance you need this, otherwise you can do without”.  So the question on this topic should be obvious, “what can I do and have installed, or even if it is installed have it running, without the use of the SECD?”.  The less obvious question to the one questioning is “why?”.  Does anyone still ask why anymore, or have we (linux users) generally turned to fashion monkeys?There are good and valid technical and security reasons to run a display manager.  The common obvious one is ssh login to your X environment.  But do we all need a display manager?  Is the display manager, for most users, just this fancy graphical screen we enter a user name and password, select which desktop or window manager to use, and as we hit enter it vanishes till the next time we boot or login?  For some it has additional functionality.  I would speculate that 95% of DM users right now have no clue what this functionality may be other than selecting and entering a desktop as a user, because X can not be started by a user (or that is what they believe).  Have you heard of xinit and startx?  On the other hand a DM can’t be run by a user.  How about .xsession modifications?  Major distro wikis are full of information (eg: https://wiki.archlinux.org/index.php/Xinitrc#Starting_applications_without_a_window_manager https://wiki.archlinux.org/index.php/Xinit).

When asking around on boards and forums, whether I need elogind or consolekit with xxx-DM, they will tell you of course you do.  Lately fewer and fewer work with CK/CK2 (consolekit), and even if they could, since others don’t, within a non-systemd distros they are all packaged to require elogind.  Since they will use elogind for some DM and Desktop that require it, they might as well use it for all and drop the redundancy of CK.  But linux was founded in redundancy and choice.  “It becomes too much work to maintain dependencies to two similar systems”.  If you look for excuses you will find some.  Some courageous souls, hopefully and eventually, will manage a reliable new login daemon better and leaner than systemd/elogind or consolekit.  There have been tries and there are current projects working on such alternatives.  Maybe s6 will come out with an s6-logind and s6-bus.

I don’t see many “experts” point out that you can do without the DM instead and therefore not use either CK2 or elogind.  Sometimes I wonder.  Are all of those guys on some kind of secret payroll to advance a dependency?  No reason to stand on this detail and speculate, just take it as “we might never know”.  To give arch some credit they have never issued their system’s image with X, or a DM, or instructed anyone what to do.  Instead they have an extensive wiki so you can do what you like.

I use Openbox, nearly exclusively, once in a while I play around with JWM but not to use it for work really, just to see how much customization can make a simplistic spartan window manager act like a full desktop (Obarun .  I have tried many tiling window managers, I tend to like the floating ones better.  I even tried bspwm which is like a gray area between a tiling manager that can also float windows).  Most floating window managers can also tile windows, jwm seems to be the easiest to set up for this, in my honest opinion (IMHO from now on).  I use no SECD.  Dbus is installed because it appears as a dependency to many pieces of software.  On the majority of systemd based distros it runs by default.  So compile X with dbus functionality built into it and X will throw some errors if running without it.  Obarun luckily doesn’t do that.

Void has a special X dbus pkg that is part of the bundle that makes X come up, and if you force remove it everything still runs fine but this dbus is absent.  If not as soon as you enter your graphic session you see dbus-launch and dbus-daemon running.  So, this is a solution for me who despises having “unnecessary” side projects of the IBM/RH teams running.

Pulseaudio, I’d rather have no audio than succumb to the “pressure”, but alsa works fine, and it is the reason that pulseaudio runs.  I have yet to see an example of pulseaudio without alsa.  But look all around the forums and you will find people asking and talking about no sound with alsa but pulseaudio works.  How can pulseaudio work without its primary dependency (alsa) not working?

Logind as part of systemd or removed and isolated as a service and library in the form of elogind (libelogind instead of systemd-libs).  Is it a good thing?  The reasons for a msg-bus and login daemon may be nobble.  How the evil team of the octopus (systemd-IBM/RH) have executed those nobble needs is another story.  S6 for example is working on its own version of s6-bus, expect it any year now.  Consolekit is no saint on its own, it is a huge ball of mesh.  If I am not mistaken it was a discontinued project of the evil team as well, but it wasn’t able to be incorporated into the systemd bundle of system-everything.  So they abandoned it and started from scratch for a login daemon that can be modular to systemd.  What would a login daemon be without its bus msg system.

Life without them (SECD and pulseaudio) can be pleasing.  Just the sense of freedom of doing all the things you want to do without them is a joy on its own.  Things that are not really missed:  Many people have been conditioned by MS-win of having “autoplay”, plugging in a cd/dvd, usb disk, and it being activated immidiately and ready to access through guys.  To do so in linux, or to replicate the functionality I should say, a bundle of software is used.  GVFS, udisks/2, udiskie, … etc.  If you don’t have those annoying gadgets can you access a disk entered into the system?  Yes.  Thanks to the very smart kernel with all this industrial firmware it is loaded with, when you plug in a medium through USB, scsi, ide, .. the kernel knows.  An id of its firmware is sent and it knows it is connected.  A complex /proc /dev entry is made for this connection, but your system will not utilize it until you choose to.  You run blkid or list the files on /dev/disk/by-(label,uuid,..etc.) and see what is physically connected.  You see your usb disk listed as /dev/sdb and its particular partition as /dev/sdb3 which you want to read and write.

Make a mount point and call it a name (usbstick)

# mkdir /media/usbstick
# mount /dev/sdb3 /media/usbstick
# ls -al /media/usbstick

Is it mounted all the time?  Make an entry in /etc/fstab and it will be available after boot is complete.  On an automounted plug-and-appear system, how do you know the medium is umounted so you can safely remove it without corrupting data?  Are you sure, because you clicked an icon on the fm that it is?  If it is so automated how do you know it is not automatically remounted?

Can I start X from console as a user with xinit/startx no SECD?

In late trends and most distros I have seen there is a small file, or needs to be, in /etc/X11 called: /etc/X11/Xwrapper.config

needs_root_rights = yes

If it contains the above line you can startx.  If your ~/.xinitrc and ~/.xsession are configured correctly it will start.  “exec jwm” or “exec openbox-session” “exec startkde” etc. is the command in .xinitrc that points X to start your window manager.  If you have installed xinit or xorg-xinit (however it is named in your distro) there should be something like /etc/skel/xinitrc which is a template to copy to your home directory and edit.  If you are not using consolekit then “exec ck-launch-session jwm” will fail.  “exec jwm” will work.

It can be done, and it can be light, and you can adopt to less automatization than major distros project as “a feature” and you might even feel more secure.  Less things running that can break, less things that your system can be attacked on, less overhead more work and play.   But pamac-gui doesn’t work by clicking on the icon, or gparted doesn’t start, or ….  this is why they were eager of getting rid of gksu, so you can’t make menu items to start software that need to run as root or some other system user.  There is an AUR pkg for gksu, there is qksu, and other alternatives in other distros, like void.

Just try and if something doesn’t work as generalized and summarized here we can find the solution together.