On Tue, 2011-06-14 at 13:14 +0200, Lennart Poettering wrote: > On Tue, 14.06.11 12:36, Denys Vlasenko (dvlasenk@xxxxxxxxxx) wrote: > > > > > On Tue, 2011-06-14 at 10:20 +0200, Lennart Poettering wrote: > > > On Mon, 13.06.11 22:46, Denys Vlasenko (dvlasenk@xxxxxxxxxx) wrote: > > > > Slide 6: > > > > "We can now boot a system shell-free" > > > > > > > > IOW: shell is bad, my new shiny toy is good. > > > > > > Oh god. If you had listened you'd have understood that my aim is to > > > deemphasize shell in the boot process > > > > You go quite farther than that. > > > > "We can now boot a system shell-free". *Shell-free*. > > Yupp, and this is one of the reasons why we boot so fast and can boot > a reasonably comprehensive userspace in less than one second. Wrong. Running shell scripts per se is not a significant slowdown. daemontools does it all the time. It just *runs them in parallel*. Performing system initialization *from* shell scripts *is* significant slowdown, because writing parallelized init in shell, correctly, is not easy. > A shell-free boot doesn't mean there wasn't any /bin/sh anymore. I mean, > I use bash all the time, it's a key way how I interface with my > machine. I use it in build scripts and everything, and I have no plans > at all to remove it from that and doing that would be crazy. I never thought you want to do that. No argument here. > But in the boot process? I don't think it is the best tool for the job, and > unnecessary, and if we deemphasize or remove it from the boot process we > have a lot to win. I don't think this is the only your motivation. You want to acquire as much "turf" as possible. Killing shell scripts everywhere in init process and requiring everyone to use systemd's way to set ulimit and whatnot etc will give you significant amounts of authority and "power". Packaging people will be forced to come to you and ask for this and that (anything they could do in shell scripts, but not they can't). This will feel good, right? You will be such an important guy! I don't see any other reason for the crusade to eliminate shell scripting from boot process. You are too clever to actually believe that shell script start time is the biggest problem in boot time. > systemd will not take /bin/sh away from you. It will just give you the > right tools so that you don't need it anymore for booting, thus saving > resources, making things faster and more robust. We will continue to > support SysV init scripts for a long time, for compatibility reasons, > and you'll always be able to plug a shell script into the ExecStart= > line of a systemd service file, if you want to. > > > ulimit -d $((16*1024*1024)) > > exec my_favorite_program some_opts > > Sure you can do that, systemd will not take that away from you. However, > we offer you a nicer, more descriptive, more homogenous way to do that in > the service file itself, simply by using LimitDATA= in the service > file. Easier to use, more descriptive, faster and involves no shell. Exactly as I suspected. Your new shiny way is better than our stupid old way. Except that I was quite happy with the old stupid way of setting data segment limit. I don't want to learn new way just to stroke your oversized ego by being forced to do it your way. daemontools has it right: it doesn't force me to abandon what worked so well for 40 years. It allowed me to run a service by writing a small shell script which can set, say, ulimit. Or cd to a directory. Or chroot. Or export a variable. Or mkdir /var/run/FOO... -- vda -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
