# Sail round systemd

## GOS

Hey guys,

recently I upgraded my system and found out that systemd is on the rise. I collected some informations about it and now I think that I schould avoid it if possible. 

Furthermore I found out that I can replace udev by eudev but I still don't know how I can replace consolekit. I ask about consolekit because it isn't maintained any longer - isn't it!? But I think I need it for udisks, upower etc. It seems that systemd replaces consolekit with systemd-login but what should I, a systemd denier, use? Any ideas?

I don't know if it's of interrest but I use Slim and Xfce

Best regrads 

GOS

PS: Please excuse my english

----------

## The Doctor

Don't worry. Word around the forums is that OpenRC will remain the "defualt" Gentoo init system. You can mask also systemd if you feel really want to. *Quote:*   

> Furthermore I found out that I can replace udev by eudev but I still don't know how I can replace consolekit.

 It is true that eudev is a replacement for udev, however it is really just an older version of udev. I am not sure, but I think it may include a few patches. However, that said the Gentoo developers are still doing all they can to keep udev building without systemd. As far as I know, its still possible. There are also alternatives such as a static /dev and mdev. *Quote:*   

>  I ask about consolekit because it isn't maintained any longer - isn't it!? But I think I need it for udisks, upower etc. 

  Consolekit is unmaintained. It was a broken concept from the beginning. Merging the concept with systemd doesn't change that. However, you shouldn't need it at all. I have found that there are excellent alternatives which would allow you to get rid of all consolkit and udisks/upower. I can't recall the name of the udev rules for automounting, unfortunately.

Slim and Xfce should be very easily made *kit less. I actually don't speak from experience on this one. I don't use either.

----------

## fpemud

 *Quote:*   

>  It was a broken concept from the beginning. Merging the concept with systemd doesn't change that. 

 

Is there any doc to describe the breakage in detail?

I'm studying the multi-seat concept of consolekit/systemd recently but have not come to a fully understanding yet.

----------

## The Doctor

 *fpemud wrote:*   

>  *Quote:*    It was a broken concept from the beginning. Merging the concept with systemd doesn't change that.  
> 
> Is there any doc to describe the breakage in detail?
> 
> I'm studying the multi-seat concept of consolekit/systemd recently but have not come to a fully understanding yet.

  It basically violates the Unix philosophy of doing one thing well. If you ever wrote a class called <foo>kit your CS instructor would probably have your head. An object should be self contained. It shouldn't rely on an outside class to manage it.

As for systemd, vertical integration is just bad policy. It encourages lazy management of individual pieces so it no longer becomes possible to separate them. This makes it much harder to maintain. The Unix philosophy of "do one thing well" is directly opposed to this.

----------

## GOS

 *Quote:*   

> Consolekit is unmaintained. It was a broken concept from the beginning. Merging the concept with systemd doesn't change that. However, you shouldn't need it at all. I have found that there are excellent alternatives which would allow you to get rid of all consolkit and udisks/upower. 

 

Sounds nice. The only question is how to do this practically and how to do this without losing the ability to mount usb-drives as user in Xfce and use the Xfce Power-Management (or an alternative) for a Laptop?

In the next step I try to unmerge the kits and take a look if I miss some abilities. I will then post my results.

Best regards

GOS

----------

## GOS

I tried to get rid of consolekit, but it's not as easy as I thought to uninstall consolekit and policykit (policykit, because consolekit is a direct dependence of it). Apparently they are dependencies of thunar and many other programs such as udisks and upower while, e.g. udisks is a dependence of e.g. k3b. 

It seems to me that a system without consolekit is diametrically opposed to a system with some "benefits" like k3b and/or a power-manager.  :Crying or Very sad: 

 *Quote:*   

> I have found that there are excellent alternatives which would allow you to get rid of all consolkit and udisks/upower. 

 

Could be interesting what these programs are and how to install them instead of consolekit. I think the crucial challenge to continue the use of OpenRC instead of systemd is to overcome the problem with the unmaintained consolekit! 

Best regards

GOS

----------

## broken_chaos

 *The Doctor wrote:*   

> It is true that eudev is a replacement for udev, however it is really just an older version of udev. I am not sure, but I think it may include a few patches.

 

Currently it follows udev upstream fairly closely, with the deviations mainly being the source tree not being embedded in systemd's (which also means you don't need to compile systemd to compile udev by default), and maintaining a few older features as to not break backwards compatibility (notably the old-style net renaming rules still work).

Most of udev isn't horribly broken, so eudev, at least to my understanding, is mainly for dealing with the bundling with systemd and the times where udev intentionally breaks backwards compatibility (like when they could have, for example, changed to new-style net rules by default without also breaking the old rules in the same release).

----------

## The Doctor

 *Quote:*   

> Apparently they are dependencies of thunar and many other programs such as udisks and upower while, e.g. udisks is a dependence of e.g. k3b.

  The way around that is to make them all unnecessary. To do that, you would simply need to add -conseolkit -upower -udisks to you USE flags, emerge -auND world, then emerge -ac to clean the now orphaned dependencies. That will not work as long as you have applications like k3b which depend directly on the three. *Quote:*   

> It seems to me that a system without consolekit is diametrically opposed to a system with some "benefits" like k3b and/or a power-manager.

  k3b is actually part of the problem here. KDE has moved to requiring rather ridiculous dependencies. Yes, you would need to switch to something like app-cdr/xfburn which is much simpler and may or may not fill your needs. Automounting can either be handled with pmount (with configuration) or uam which is basically a set of rules that will automatically mount any removable media inserted. Neither one has a GUI front end, but they both get the job done.

I don't know anything about power management. I never used it. However, I am sure there is someone who knows more about this floating around.

On the plus side, I doubt consolekit is going anywhere fast so you can certainly keep using it.

----------

## The Doctor

 *broken_chaos wrote:*   

>  *The Doctor wrote:*   It is true that eudev is a replacement for udev, however it is really just an older version of udev. I am not sure, but I think it may include a few patches. 
> 
> Currently it follows udev upstream fairly closely, with the deviations mainly being the source tree not being embedded in systemd's (which also means you don't need to compile systemd to compile udev by default), and maintaining a few older features as to not break backwards compatibility (notably the old-style net renaming rules still work).
> 
> Most of udev isn't horribly broken, so eudev, at least to my understanding, is mainly for dealing with the bundling with systemd and the times where udev intentionally breaks backwards compatibility (like when they could have, for example, changed to new-style net rules by default without also breaking the old rules in the same release).

 

The reason I posted what I did was that a Dev corrected me before when I posted something similar about eudev. Things may very well have changed. I haven't used either for since just after the network renaming and I haven't kept up on the latest news.

----------

## GOS

Thanks a lot for your help,

I will try it with xfburn and look how I can substitute my power-management. It seems to me that the dependencies putted in by the kdelibs for k3b are problematic, so Xfburn is a good idea. 

I use power-management only on my laptop, but there it's necessary. The future will show if sailing round systemd is a hopeful oder hopeless endeavor.

Best regards 

GOS

----------

## _______0

systemd stanzas resemble m$$ registry. Not that there's anything wrong with that sort of organization, just pointing that out.

----------

## broken_chaos

 *The Doctor wrote:*   

> The reason I posted what I did was that a Dev corrected me before when I posted something similar about eudev. Things may very well have changed. I haven't used either for since just after the network renaming and I haven't kept up on the latest news.

 

It's definitely changed since then. There's a bit of info in something like eudev's UPSTREAM.notes (or some more detail in the git commit log), if you're interested in it. I think eudev's git repo is roughly caught up to udev's (well, systemd's...) right now, partly as udev doesn't see constant heavy changes.

----------

## Ant P.

 *GOS wrote:*   

> I tried to get rid of consolekit, but it's not as easy as I thought to uninstall consolekit and policykit (policykit, because consolekit is a direct dependence of it). Apparently they are dependencies of thunar and many other programs such as udisks and upower while, e.g. udisks is a dependence of e.g. k3b. 
> 
> It seems to me that a system without consolekit is diametrically opposed to a system with some "benefits" like k3b and/or a power-manager. :cry:

 

The saddest part of this is that Xfce used to be fully functional, well designed *and* bloat free; it had small sudo helper binaries to e.g. shut the system down, which were removed around 4.10 to force people onto cruftkit.

As for k3b, I can usually tab-complete `wodim file.iso` before K-apps finish loading their GUI...

----------

## The Doctor

 *GOS wrote:*   

>  It seems to me that the dependencies putted in by the kdelibs for k3b are problematic, so Xfburn is a good idea.

 

Depending on what else you use kdelibs for, you can actually keep a surprisingly large number of KDE applications and go *kit free. Unfortunately, mandatory semantic desktop features are on the horizon. Depending on how you feel about this you may want to drop KDE apps all together.

I did think to bring this up before, but there is a handy tool in gentoolkit called equery which will show dependencies. For examply, to find what depends on consolekit you can use equery d consolekit and you will be given a list. The list should also tell you if it is a use flag option or is a hard dependency.

Completely off topic, I now notice someone was being cleaver. Is it gentoo-kit or gen-toolkit?

@broken_chaos Thanks for the update on eudev.

----------

