Hi. On Sat, 11 Oct 2014 23:02:01 +0300 Andrei POPESCU <andreimpope...@gmail.com> wrote:
> On Sb, 11 oct 14, 23:20:34, Reco wrote: > > On Sat, 11 Oct 2014 20:47:36 +0300 > > Andrei POPESCU <andreimpope...@gmail.com> wrote: > > > > > At least with systemd if you fix a bug it will benefit all daemons using > > > it. > > > > No, quite the contrary. By fixing such jack-of-all-trades > > libsystemd library you're risking to *break* some other daemons. > > But, pretending your point is valid, fixing /etc/init.d/skeleton grants > > the same benefits. > > Nope. The reason being? Code quality of systemd is not top-grade (to say lightly), and the project hardly reached its' maturity. It'll only get worse from here. And, I have to ask. Are you denying both of my statements, or the last one only? > > > This is the same reason we are using shared libraries and the Debian > > > Security Team is doing it's best to track code copies. > > > > Consider /etc/init.d/skeleton a library then. It's sources to > > any /etc/init.d script anyway. > > No, it doesn't. Again, simple 'no' is beautiful, but hardly contributes to the discussion. > > > True, but sysv-rc still can't deal with them correctly. > > > > It does not have to deal with the hardware, as it not its' job. > > It has to mount filesystems. No, it does not have to. In Debian, there's /etc/init.d/mountall.sh to do this job, in case initrd didn't care for it already. init(8) does not mount anything. And, to spice things up, [1]. Beautiful link telling everyone that it's not the init job to mount /usr as there's initrd for that. > > Ok. You have wired, that's one stanza in /etc/network/interfaces. Or > > one obscure systemd's unit, if you prefer *that*. > > You have wireless, and while it's possible to > > use /etc/network/interfaces for that too (I do, for example), Joe the > > Average User would probably use NetworkDestroyer (sorry, Manager), or > > wicd. Anyway, wireless requires usage of wpa_supplicant, which is not a > > part of systemd. Presumably one can use a systemd's unit for that too, > > but I've never tried it. > > A dongle for a mobile is probably a good old g_ether network interface > > aka usb0. It's complicated somewhat as one may need to use > > usb-modeswitch (not a part of systemd, btw), but it's nothing more > > complex than yet another stanza in /etc/network/interfaces. > > As for the IPv6 - unless you're turning your own PC into a router, > > configuring IPv6 is something that kernel does for you already without > > any intervention from the userspace (it's called a Router Advertisment). > > My point was that userspace has to react to changes in networking. The > following might also provide for an interested read: > http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ Oh, you've meant *that* by complex. Ok, I misunderstood you. Along all presumably good things that page tells, there's these gems: This will ensure that all configured network devices are up and have an IP address assigned before boot continues. This service will time out after 90s. Enabling this service might considerably delay your boot even if the timeout is not reached. Both services are disabled by default. … If you are a developer, instead of wondering what to do about network.target, please just fix your program to be friendly to dynamically changing network configuration. That way you will make your users happy because things just start to work, and you will get fewer bug reports as your stuff is just rock solid. Please enlighten me what exactly is systemd-specific here. Basically they tell "yadda-yadda-yadda, fix your applications, and if you don't - we have this 90-second hack for you". > > You don't have to, in this specific case. NFS should be mounted long > > before any daemon starts, mpd included. Things can break, as your > > example show. > > A better example would be 'how I can ensure that mpd will > > stop if I unmount a NFS share?'. > > Still, I agree that's a valid point, *if* you disregard an existence > > of automount(5). Because, mounting NFS from an fstab is *so* AIX. > > Why should I need to install yet another daemon, with yet another > configuration file/syntax? Brilliant question. Certainly you've meant systemd, right? Just joking. Joke aside - because it's convenient to mount a filesystem once you really need it, and (which is much more important) - unmount it once it's not needed anymore. > > [3] tells us "systemd 30 and newer include systemd-logind. This is a > > tiny daemon that manages user logins and seats in various ways." > > I had an impression that an ssh login is an actual login. > > And, since you can easily start an X session over ssh - there's need to > > consider it a ssh login a seat too. > > Are you talking about X forwarding? Isn't the X session on the ssh > client side (a.k.a. the X server side)? X server on host A. ssh connection from host A to host B. X clients wrapped in X session on host B. Saves the trouble of using XDMCP. Call it the way you like it. > > As for the x11vnc - I doubt that it could be fixed. x11vnc attaches to > > an existing X server, and is translating said server I/O over VNC to > > anyone. It does not spawn its' own session, so there's nothing that can > > be tracked. > > According to the package description it has "UNIX account and password" > support. If that is done via pam (how else?) it should be possible for > it to use libpam-logind. Probably it has such things. Never used them, as simple VNC authentication was always sufficient for my needs. But you've missed the main description 'VNC server to allow remote access to an existing X session'. "Existing X session" is crucial here, and that part (by design of x11vnc) is that confuses logind (and always will be). [1] http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ Reco -- 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/20141012014134.6ec0abe29730dfd9915af...@gmail.com
