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. 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. 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. > You are not saying "driving boot process by shell scripts is slow > because ... ... ..." (an argument I would agree with), you are > aiming at *eliminating* shell scripts from boot process. Yes, I want to deemphasize the shell in the boot process, and ideally remove it entirely from the boot process. > > > Slide 14: > > > "systemd is an Init System" > > > "systemd is a Platform" > > > > > > systemd is a platform? Really? What next? systemd is an Aircraft > > > Carrier? > > > > That is not a technical argument, but just FUDing. > > No, it is a technical argument. I am saying that this is not how things > are supposed to be done in Unix. I am saying that you are trying to > incorporate as much stuff as possible into systemd, and I think it's > wrong. You don't like me saying this? Well, not a surprise. > I also don't like when people tell me that I'm wrong. Wow, you honestly believe that suggesting systemd would turn into an aircraft carrier is a technical argument? Must be good stuff you are smoking... I think we'll just have to agree to disagree and leave it at that. > > > Slide 50: > > > "Shell is evil" > > > "Move to systemd, daemons, kernel, udev, ..." > > > > > > Again, shell, a tool which endured for 40+ years, is suddenly "evil". > > > I don't think this being the consensus. > > > > Yeah, it's not the right tool for the boot process. Doesn't mean it > > wasn't useful for interactive use or for scripting. Just not the right > > tool for the boot process. Since you seem to have trouble understanding > > that, let me repeat it a couple of times: shell is not the best tool to > > accomplish a quick and reliable bootup. > > Can shell play a part in the boot process, or is it now completely > banished? I don't know, is something like this acceptable in the new > world of systemd? 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. > > In fact those slides you refer to explain all that. If you don't listen > > and don't want to read, then I cannot help you. One last try with > > different words, nonetheless: simplicity, speed, robustness, > > compactness, functionality. > > Good that you don't include "modularity" any more. At least one of my > arguments reached through, it seems. Uh? systemd is modular. Absolutely, you can choose the parts you want and the ones you don't, which is handy for embedded uses. If you however ask why we integrate a lot of previously separate stuff in systemd, then answering "to make it modular" would be kinda bogus. systemd is absolutely modular, but modularity is not a reason for integrating things the way we do. Oh, and the list above why we do this is not complete anyway, there's a lot I could still add as reasons why we integrate things like this. For example we want to use systemd as gentle push for the distros using it to unify, standardize and de-balkanize the basic set of components of the OS. > Let's take a look at each of them: > > simplicity - I don't see it What's so hard to understand, that with systemd you need 10 basic packages to build a minimal system, and without systemd you need 50. systemd is hence much simpler to understand. (these are not exact numbers) > speed - yes > robustness - actually yes, your code seems to be good in that area > compactness - no Oh hell, absolutely. It's much more compact, since you need to build only 10 instead of 50 packages to build your basic system... > functionality - too much of it. I'd call it bloat Well, I call a system bloated that is build from a myriad of separate packages, with lots of glue kludges inbetween, and enourmous amounts of duplication. However a systemd which simplifies, unifies, streamlines the chaotic set of existing basic building blocks into a few, integrated well-written ones, that's what I call the opposite of bloat, and that's what systemd is. > I would also add "monolithic and inflexible". Sorry. Well, it's neither monolithic nor inflexbile, it's pretty much the contrary. But I have enough of this nonsense. We have to agree to disagree. I'll leave you to your opinions -- how wrong they might be. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
