On 09/03/2019 09:28 AM, Bruce Hill via lfs-dev wrote:
On Tue, Sep 03, 2019 at 12:39:18PM +0800, Kevin Buckley via lfs-dev wrote:Actually, as one of the people who strived to get away from the default package ordering (more or less alphabetcial once a core set of packages had been installed) when the SysV and SysD books started to diverge, yes I am aware of that.
My original comment was mainly about LFS chapter 5, where mandatory building order changed... Which, IMHO, should never occur as package layering is stable and known. (Here, LFS, by changing/finding new order, is responding to package changing their dependencies, not a critic about LFS team)
This seemed an open opportunity for one who has worked on distributions using "SysV-style init" (from UNIX System V), BSD-style, OpenRC, and now systemd, to post a couple of historical links [1,2]. Not just used, but tested, built, and maintained packages for 2 distros. When systemd was first announced, the BDFL taught me to hate it. When Linus went off on Lennart and Kay on LKML, I hoped systemd would die as did HAL. The reason it's caused so much strife has less to do with the design of systemd, I think. Rather, the fact that many people have used nothing other than SysV init (which, apart from the inittab handling, is just awful) and been contemplating their navels.
;) interesting comment, I strongly (as many) object on systemd design itself, but lets say I am "contemplating my navel", please help me to have a better systemd understanding. As sysadmin: - systemd is adding a layer of complexity, such, in cause of emergency/trouble, tools given by systemd doesn't allow to have contextual view of the problem. (A critical server is not rebooting, second counts!, why it not rebooting??!!, you need to resolve issue ASAP). - Systemd (by design) doesn't allow me to proceed in CLI mode, working, starting process in a new/debug order, trying to have a clear view of what is working, Not speaking of systemd logs (a recurring critic about systemd logs). Systemd paradox, systemd is a sys-admin tools, not designed by a sys-admin. As designer, - The systemd original goal was to speed up booting process (a none issue in server context), to achieve this, project end up to annex many many system functions (udev, time, dhcp, etc...) to have them embedded within systemd...Now, systemd is taking a lot of responsibilities/decisions, being de facto a kernel over a kernel (bad design?). - Last time I checked systemd, main program was over 6000 lines (in C) without even one comments, hardly open-sources or documented.... (as I am saying to younger colleagues, do not "piss" code, write something, yourself will be, still, able to easily understand in 6 month from now...). About sysvinit: I find it extremely simple, if you find it "awfull" it is, may be, you tried to use it in a way it is not designed to be used... (layering position and design issue) :) An the winner is: RedHat, being RedHat, I would push all my weight and power to have systemd widely accepted. - Easier to sell support. - Better to implement and support Linux desktop/tablette ... (but, AFIK and amazingly enough, the Redhat real market is the server one...) So please, LFS team, keep sysV-style book, as a teaching tool, it allow a better transparency about booting component relationship.
I'll take OpenRC over SysV-style init any day of the week, though. SysV is a nightmare. But now that my mind is open to systemd, it has been surprising to find that everything in systemd is properly documented. Kudos to Version 9.0, and your diligent work on this release. [1] http://0pointer.de/blog/projects/systemd.html [2] http://0pointer.de/blog/projects/systemd-for-admins-1.html Bruce
-- seen "Linux from scratch" and looking for ISO files www.osukiss.org
smime.p7s
Description: S/MIME Cryptographic Signature
-- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
