4 ms·
To add to that, I think the definitive reason for a persistent dependency graph would be enabling a deterministic boot order.
by vezzy-fnord 11y ago
To add to that, I think the definitive reason for a persistent dependency graph would be enabling a deterministic boot order.
- JdeBP 11y agoI'd have to check to see whether M. Bercot explained the design decision, but I wouldn't discount simple efficiency as a reason. Calculate things once, store the result, recalculate when the inputs change rather than again and again whenever one wants the result. It's the principle that has tinydns-data run via a makefile. It's the principle that has vipw run pwd_mkdb. It's a design principle that gave nosh cd /etc/system-control/convert/ && redo all which is another system that takes files (/etc/fstab, /etc/passwd, /etc/ttys, /etc/rc.conf, and others) and builds a structure of services. The principle prompts the question "I know that my /var volume is /dev/label/var and it stays that way across reboots. Why should I regenerate the service for mounting it over and over, instead of only when /etc/fstab actually changes?".