Re: Here's how to make yourself happier OT in re systemd
Le 06.03.2014 19:17, Andrei POPESCU a écrit : On Jo, 06 mar 14, 10:54:04, berenger.mo...@neutralite.org wrote: [...] I think that it's easy enough to disable/enable a particular daemon, since we only need to change a file name and run #update-rc.d script defaults. Sorry, but this doesn't parse, 'defaults' should configure the service to start/not start according to the LSB headers. As far as I know at the moment the only recommended and reliable to enable/disable daemons is update-rc.d service-name enable|disable I'd rather see this in service(8), and it seems others thought the same (see #545325). Kind regards, Andrei I never really dug into this. It's only that this line is the one given /etc/rcX.d/README : $ cat /etc/rc2.d/README The scripts in this directory are executed each time the system enters this runlevel. The scripts are all symbolic links whose targets are located in /etc/init.d/ . To disable a service in this runlevel, rename its script in this directory so that the new name begins with a 'K' and a two-digit number, and run 'update-rc.d script defaults' to reorder the scripts according to dependencies. A warning about the current runlevels being enabled not matching the LSB header in the init.d script will be printed. To re-enable the service, rename the script back to its original name beginning with 'S' and run update-rc.d again. For a more information see /etc/init.d/README. -- 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/090842be919fcf0e6a82d41dcffc1...@neutralite.org
Re: Here's how to make yourself happier OT in re systemd
On Vi, 07 mar 14, 14:17:47, berenger.mo...@neutralite.org wrote: To disable a service in this runlevel, rename its script in this directory so that the new name begins with a 'K' and a two-digit number, and run 'update-rc.d script defaults' to reorder the scripts according to dependencies. A warning about the current runlevels being enabled not matching the LSB header in the init.d script will be printed. To re-enable the service, rename the script back to its original name beginning with 'S' and run update-rc.d again. For a more information see /etc/init.d/README. I stand corrected, and update-rc.d(8) also explains why: If any files named /etc/rcrunlevel.d/[SK]??name already exist then update-rc.d does nothing. The program was written this way so that it will never change an existing configuration, which may have been customized by the system administrator. The program will only install links if none are present, i.e., if it appears that the service has never been installed before. However, 'update-rc.d service disable|enable', besides being shorter and easier, also takes care of the other supported inits (currently only upstart and systemd, OpenRC is work in progress). This way a daemon disabled under sysvinit will stay disabled if you switch to something else. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Here's how to make yourself happier OT in re systemd
Le 05.03.2014 08:54, Raffaele Morelli a écrit : 2014-03-04 18:15 GMT+01:00 Paul E Condon : On 20140304_160239, Raffaele Morelli wrote: 2014-03-04 15:45 GMT+01:00 Steve Litt of Troubleshooters.Com litt...@gmail.com [1]: On Tue, 4 Mar 2014 09:05:41 +0100 Raffaele Morelli wrote: Lately I would add :0B * .*(systemd) $GARBAGE :0 * ^Subject.*(systemd) $GARBAGE I can't do that, because I really need to know about that stuff. When Jessie becomes stable, I'm going to try to work with systemd. But if that becomes problematic, I'll need a plan B. A lot of today's traffic was very informative stuff about system startup. IMHO you won't need a plan B, it's just another system service manager, that said you can try systemd before Jessie release, it's in debian Wheezy... /r I switched to systemd under Wheezy a couple of weeks ago. I had a small problem convincing aptitude to stop switching back to the old way any time that I wanted to install packages from security.debian.org [3]. After fixing that I have noticed no difference from the old way, whose name I have already forgotten. My hardware has a built in, intended, delay before start of boot, so I don't percieve that boot is faster. Maybe it is. I just can't see it in my particular set up. I am much more worried now about the world going nuclear before systemd gets a chance to prove its usefulness. +1000 sometimes people on this list get somewhat horny when discussing those things, which are really subjective in the end... they go on with a mixture of tecno-steronic, 0.02$ philosophy which I can't stand :-( Peace to all, I hope respect /raffaele Links: -- [1] mailto:litt...@gmail.com [2] mailto:raffaele.more...@gmail.com [3] http://security.debian.org [4] mailto:pecon...@mesanetworks.net The speed you can gain by changing an application depends on more than one parameter. It depends on the software configuration of the system: switching from a KDE application to a GTK one ( on a GTK-based desktop ) will allow to notice resources gains. But also on the hardware you have: depending on the computer you have, running eclipse can start instantly ( at least, I guess so, I've never seen that ;) ), or starting even vim can take more than a second. Finally, it also depends on it's own configuration: keeping eclipse as an example, it will be obviously faster if you configure it to load less plug-ins. Most of the time, it's stupid to say my application will be faster than others which does the same, on all hardwares and softwares configurations. Except if you publish a fork in which you removed features, or fixed bugs. And even then, maybe the end user will not notice the speed improvement because he's computer is too fast for that. Systemd, as every piece of software, also depends on those points. And speed is not the killer feature of this daemon, instead, it's easy to write configuration files ( and not, script files! ). For me, systemd is not a good choice. Because it does not fit with my objectives, and would only give me a very limited, if any, speed and maintenance gain: I like very minimalist systems, where things are started by hand if and when I really need them. So I do not have a lot of services. Plus, I am not a maintainer, so I do not have to maintain starting scripts ( but I need someone to do so instead of me, for now ;) ) and I think that it's easy enough to disable/enable a particular daemon, since we only need to change a file name and run #update-rc.d script defaults. But, that's only my use. Normal users uses KDE or Gnome, with tons of potentially useful daemons started all the time ( cups, sane, network-manager, dbus, and for some programmers apache, php, DBMS... ) which are really heavy. For those, systemd will really be useful. And those daemons have dependencies on others, so it will help their maintainers to use systemd, too. Note, I did not read the latest trolls. And I do not care if someone thinks I'm wrong. I have built my opinion on what I really need if systemd can help me with my own special needs long ago. And I think it is not a software built for peoples like me. I'm fine with that, and with Debian's default choice, as long as I can switch to others. I already manually explicitly ask debian to install lilo and not grub, no DE but instead a wm plus some specific tools, no basic tools but a hand-made selection of them. I can ask it to install a particular init system as well, I do not mind. And people who are really angry about that Debian's maintainer's choice can just do the same, instead of flooding a mailing list dedicated to helping other people solving problems. That's what adults should do, btw. I'm becoming tired of all that useless noise around a subject which have been discussed so many times. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact
Re: Here's how to make yourself happier OT in re systemd
On Jo, 06 mar 14, 10:54:04, berenger.mo...@neutralite.org wrote: [...] I think that it's easy enough to disable/enable a particular daemon, since we only need to change a file name and run #update-rc.d script defaults. Sorry, but this doesn't parse, 'defaults' should configure the service to start/not start according to the LSB headers. As far as I know at the moment the only recommended and reliable to enable/disable daemons is update-rc.d service-name enable|disable I'd rather see this in service(8), and it seems others thought the same (see #545325). Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Here's how to make yourself happier OT in re systemd
2014-03-04 18:15 GMT+01:00 Paul E Condon pecon...@mesanetworks.net: On 20140304_160239, Raffaele Morelli wrote: 2014-03-04 15:45 GMT+01:00 Steve Litt of Troubleshooters.Com litt...@gmail.com: On Tue, 4 Mar 2014 09:05:41 +0100 Raffaele Morelli raffaele.more...@gmail.com wrote: Lately I would add :0B * .*(systemd) $GARBAGE :0 * ^Subject.*(systemd) $GARBAGE I can't do that, because I really need to know about that stuff. When Jessie becomes stable, I'm going to try to work with systemd. But if that becomes problematic, I'll need a plan B. A lot of today's traffic was very informative stuff about system startup. IMHO you won't need a plan B, it's just another system service manager, that said you can try systemd before Jessie release, it's in debian Wheezy... /r I switched to systemd under Wheezy a couple of weeks ago. I had a small problem convincing aptitude to stop switching back to the old way any time that I wanted to install packages from security.debian.org. After fixing that I have noticed no difference from the old way, whose name I have already forgotten. My hardware has a built in, intended, delay before start of boot, so I don't percieve that boot is faster. Maybe it is. I just can't see it in my particular set up. I am much more worried now about the world going nuclear before systemd gets a chance to prove its usefulness. +1000 sometimes people on this list get somewhat horny when discussing those things, which are really subjective in the end... they go on with a mixture of tecno-steronic, 0.02$ philosophy which I can't stand :-( Peace to all, I hope respect /raffaele
Re: Here's how to make yourself happier OT in re systemd
On 20140304_160239, Raffaele Morelli wrote: 2014-03-04 15:45 GMT+01:00 Steve Litt of Troubleshooters.Com litt...@gmail.com: On Tue, 4 Mar 2014 09:05:41 +0100 Raffaele Morelli raffaele.more...@gmail.com wrote: Lately I would add :0B * .*(systemd) $GARBAGE :0 * ^Subject.*(systemd) $GARBAGE I can't do that, because I really need to know about that stuff. When Jessie becomes stable, I'm going to try to work with systemd. But if that becomes problematic, I'll need a plan B. A lot of today's traffic was very informative stuff about system startup. IMHO you won't need a plan B, it's just another system service manager, that said you can try systemd before Jessie release, it's in debian Wheezy... /r I switched to systemd under Wheezy a couple of weeks ago. I had a small problem convincing aptitude to stop switching back to the old way any time that I wanted to install packages from security.debian.org. After fixing that I have noticed no difference from the old way, whose name I have already forgotten. My hardware has a built in, intended, delay before start of boot, so I don't percieve that boot is faster. Maybe it is. I just can't see it in my particular set up. I am much more worried now about the world going nuclear before systemd gets a chance to prove its usefulness. Peace to all, I hope -- Paul E Condon pecon...@mesanetworks.net -- 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/20140304171544.gb9...@big.lan.gnu
