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 few
months ago. I tried a few other wifi connectivity tools, and ended
up
with wicd. What was different about wicd was that (i) it worked, and
(ii) it was independent of systemd. I don't know whether the
introduction 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
be
able to mount it from the file manager after entering the root
password. Starting a month or so ago, the file manager would
tantalizingly 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,
but
the 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.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/8c4f5aca51881d9d55ce8734469bd...@neutralite.org
