Le 09.11.2014 05:05, Hendrik Boom a écrit :
On Wed, 05 Nov 2014 09:32:57 -0500, Miles Fidelman wrote:1. What are your issues, reasons for doing so - general and/or specific?I've had trouble with passwords in the network-manager starting a fewmonths ago. I tried a few other wifi connectivity tools, and ended upwith wicd. What was different about wicd was that (i) it worked, and (ii) it was independent of systemd. I don't know whether theintroduction of expansion of systemd had anything to do with my problems.
This might be a policykit-related issue. AFAIK, policykit has been deprecated in favor of systemd-login0. From what you describe, it seems the migration from policykit to systemd-login0 (which is not systemd itself, but only a module. I hope I'm not wrong here, since I do not really understand the language used in systemd-world).
I've started to have trouble mounting the NTFS partition on my machine from Linux. No problem doing this in Windows, of course. I used to beable to mount it from the file manager after entering the root password. Starting a month or so ago, the file manager wouldtantalizingly show me the partition but refuse to let me mount it because I didn't have the proveleges. Finally, it stopped even showing me that partition. Of course I cann still log in as root and mount it from the command line, copy any files from it, and chown them to myself. But it is unnecessarily awkward. I understand systemd had involved itselg with permissions. Could this be relevant? I have the same problem with usb sticks -- having to be root to use them. Again, I have no idea whether the architecture changes caused by systemd has any relevance to this, butthe general level of paranoia that is starting to exist makes me suspicious, perhaps unjustly.
This could be udev-related. Udev is the part of the system which fills /dev.
It does this at boot, and while your computer run.The current man-page says that, "the udev daemon, systemd-udevd.service(8), receives device uevents directly from the kernel whenever a device is added or removed from the system, or it changes its state". You can build rules in /etc/udev, which could eventually allow you to fix your problem by yourself. I can't really help you about how to write the rule, since I have never tried to build some myself. Why things have stopped working, is a good question: maybe a change in /dev/disk/by-uuid? Does things works anew if you create a user to login with (and so, with a clear $HOME)?
It seems that your problems seems to not be systemd-related, since systemd is only the PID1 process' stuff. They are only related to things which are parts of the systemd...hum... sorry, softwares which shares the same source-code repository that systemd uses. Yeah, some irony here, indeed. I won't argue about the fact that udev/login0 are or are not parts of systemd. I do not mind, in facts.
PS: about knowing which software is used by which DE to do some task, I agree with you. Now, you can retrieve this information quite easily: use aptitude in ncurses mode, find the meta-package which is named after your DE (xfce4 in your case), and take a look at the depended softwares. For some kind of softwares, there is stuff provided by the alternative system. I do not know if there is something for file browsers.