On Sun, 17.07.11 06:32, Sergey (sergem...@gmail.com) wrote: Heya,
sorry, but I am not interested. Unix is an inspiration but it is not dogma. Integration avoids duplication, integration hence avoids bloat. Note that systemd is not monolothic anyway. For example, you can just remove the bus mechanisms, and the early-boot components and everything will still work fine. Modularization for the only sake of modularization is however not what what we buy into. The more you modularize the bigger the overhead of communication becomes, and that again ... is bloat. Also note that there's a reason why sockets, services, mount points and so on, are all handled in the same concept of units: they have complex interdependencies, and managing those if the managers supervising them are separate would mean complex synchronozation logic. In addition, you are very much overestimating the code size of the socket handling, and similar code. Splitting short code like tht into separate processes is wastage. Finally, I am also not interested to encourage too much mix and matching, have too many variables in the installation. I want to help streamline and standardize our platform. That means I want to allow developers to rely that certain features in the OS are available, for example socket activation -- so that they actually use it. Hence making that optional would be diametrically against my goals. I see no value in the portability to other Unixes. I do see value however in our platform becoming stronger by removing the big variable of the OS we build on. > "Why is this better?" > ===================== > Because it's flexible, portable, simple, easy to support and it's > unix-way. Well, it's neither more flexible nor simpler or easier to support. And portabality to other Unixes or being the "unix way" I don't consider much of an advantage. (Also, I think you misunderstand Unix a bit.) > It does not have any extra dependencies. So if someone needs to build a > compact > system for netbook with 128MB RAM he can install just `systemd` and save a few > MB of RAM without dbus (Xorg+IceWM don't need dbus) and other systemd > services. > There's also no need in dbus on ssh/dns/http-servers. Not using D-Bus wastes memory, since programs have to reinvent their IPC systems each and every time. 1 good IPC instead of 20 fucked up ones means using less resources, having more security, more simplicity, and more transparency. I am not sure what the folks who claim dbus was bloat are smoking, but it certainly interferes with their ability to think logically. The idiocy of people who believe they could just remove the IPC from their system and everything would still be able to communicate as before but using fewer resources is amazing. You are welcome to question the implementation of D-Bus, but if you question the existance and need for it then this says more about your nescience than about D-Bus. > For example, this structure forces developers (or maintainers) of every > service > to write two startup scripts - one for systemd-based script and one sysv-init > script for non-systemd-based systems. Why not use a single script for that? > For example instead of writing second startup script we just add the line: > # TCPListen: 22 > to the LSB Header of /etc/init.d/sshd. That will make transition easy and > remains fully backward compatible. Services that don't have this line will > be treated as usual sysv services. I am not interested in that. If people want to keep using SysV scripts, it's their own burden. > That also makes developers' work easier - they won't have to write two > startup scripts and worry about compatibility. Upstream developers generally do not write init scripts, package maintainers do, simple because you have tow write different ones for different distros. Which coincidentally is something systemd fixes. Sorry if this reply is harsh, Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
