-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, sorry for another rant, but I'm a software developer and a user of a Linux-based operating system here.
I read the post about at 0pointer.de about "myths about systemd". [1] I want to address the issue of it being monolithic. More specifically, I want to tell what where is that coming from. systemd started an an init system. It had an idea of doing one thing "the proper way" - of system init on Linux-based systems. That made the project easy to understand and follow. Now, as was written in that post, the project consists of over 69 binaries, where most of them are entirely optional. The problem with this project is not how it is written. It is how it is *packaged and distributed* to end-users. Luckily, I use Gentoo. I have Portage, which will happily compile the package on my system and I can tell it by USE flags what to compile and what not to. Other package managers doesn't work this way. They fetch *pre-compiled packages*. Now, what is the PACKAGE "systemd" doing? Init? Is it a HTTP server? A system logger? Something that uses QR codes? Can I replace it with another package? The answer is: no one but the developers know. The package doesn't even have an understandable version numbering. It is one increasing number. How is a package maintainer supposed to know if version change from 340 to 341 introduces major changes? I don't even know *what* changed unless I read a ChangeLog. Normally, you have a major version and a minor version. If the major version changes, it is an alarm to do throught testing to see if everything works wellon the new one. Minor changes are minor, so they require less testing. What this project needs is division of this one big have-it-all package into individual packages, each containing components for a specific purpose. There is nothing wrong with them depending on each other, but they should be in different packages, each having a separate build system and version, for the following reasons: 1) You as developers are more aware of what changes in the project, beause commits are associated with individual componenets. 2) If a component was a failure, you can just drop the package and work on another - nothing else needs work. Most importantly, the main component is not touched. 3) The people that are not involved with the developement are more aware what the suite of packages called systemd is actually composed of. Package maintainers can now block one component if there is something wrong with it, but not all the others. 4) The user can then install the init system from systemd, and keep their system logger. Example: systemd-logind should not pass the messages to another logger. The other projects should be encouraged to use systemd APIs/ABIs on Linux to get them. This makes systemd-logind more lightweight. 5) Most importantly: by such a split you future-proof the project as a whole. Someone might come up with a better solution for a component than you in the future. That someone should not fight with your system in order to use other components. It should be made easy and simple to replace any binary systemd uses now with another - with another PACKAGE. If systemd keeps going the way it does, it will eventually get forked, because it will become an unmaintainable mess when you notice something major in the system could be done better, and that better approach breaks everything else in the system. systemd works fine. NOW. I also would want it to work after 20 years, because I see good ideas here. Actually, I think this project's future is a "Linux-based Init and Service Management System Standard", where the systemd suite of packages is the reference implementation. [1] http://0pointer.de/blog/projects/the-biggest-myths.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV+R5zAAoJEDRBz9VZHKuW2psQAKiqMb0H8djvKcWanKsYguIg pUFp2e32rHUGMW7DVtF1pk18rYygq+6vOgi+ACQVLlHOL0nOxhwyjqSkfhVF/Ew6 p6worj+PZIuHiEE6VwMZ9v7ptlPFniLQc73avPv7661YpC7DIsQGlV5GmtmR+Q73 LwQsAm82f1NR8Oh8Ud0MgJRVBpY9NYAmN0PSJnSxfYmmx4epO9MtLAf0aG4pnhKc 13EmVcD3N+bkHk8jWo4X3o1DiDDDJ/afWBIqbHxd0Z7o9JHn2YCyAWcC4t0DO2Tu vUvlzhced8jfFMua+323XNXzSP6BsRoDWiit4qTXGW8ptXW1VNc3wRLtef4i3Jao 6owtN7NIaYHRAKymUJUad5XH7a6EwcOBu3wtZ0jAJMa/1MdmG1VPtXUVobEAzCEj vjm+X0aJMB5JkOPkmT9szm0QSQh0Uj4Cme3e6GwTppteZNga9s1OV068zB/gdDIB y7bHHSO6d4AN4tFQXYyX7P0cBsQ3HWIaqn+IIDnPEz/hwNeh+6yEHPzdktWX5ksg Z4V7IkVOHYS60ejlldhavNOM2fF/57OTC9HtWjU1cbjithKzNzbLmTzbpt/UI6Ha LVFqQnKLqwfMvP+IQMlE4+rTaBa7Jl/VgQaogxScO1W1TBV+Nf4IIubob7BTR834 Mv1H1NT/S3+rp98uMTud =6YJT -----END PGP SIGNATURE----- _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
