At Tue, 23 Feb 2021 16:15:52 -0500, Henry Bent <henry.r.bent(a)gmail.com> wrote: Subject: Re: [TUHS] Abstractions Indeed. However /rescue is really just a hack to avoid the problems that occur when basic tools are dynamic-linked. My vastly preferred alternative is to static-link everything. Of course with C libraries these days that means the binaries can be rather large -- albiet still relatively small in comparison to modern disks. In any case I've also built NetBSD such that all of the base system binaries are linked together into one binary (we call this "crunchgen", but Linux usually calls it "Busybox(tm)"). I decided to put all the bin directories together into one for the ultimate savings of space and time and effort, but it would be trivial to keep the root and /usr split for better managing application-specific embedded systems. This hard-static-linking of everything into one binary results in a surprisingly small, indeed very tiny, system. For i386 (32-bit) it could probably boot multiuser in about 16mb of RAM. What I've got so far is a bootable image file of a "complete" NetBSD-5/i386 systems that's just a tiny bit over 7Mb. It contains a kernel and a ramdisk image with a 12Mb filesystem containing a crunchgen binary with almost everything in it (247 system programs, including all the networking tools, but no named, and no toolchain, no mailer, and no manual pages -- not atypical of what was delivered with some commercial unix systems of days gone by, but of course updated with modern things like ssh, etc..) -- Greg A. Woods <gwoods(a)acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca> Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>

At Tue, 23 Feb 2021 20:20:55 -0700, Warner Losh <imp(a)bsdimp.com> wrote: Subject: Re: [TUHS] Abstractions I guess it may depend on your measure of "better"? With a single static-linked binary on a modern demand paged system with shared text pages, the effect is that almost all instructions for any and all programs (and of course all libraries) are almost always paged in at any given time. The result is that program startup requires so few page-in faults that it appears to happen instantaneously. My little i386 image feels faster at the command line (e.g. running on an old Soekris box, even when the root filesystem is on a rather slow flash drive) than on any of the fastest non-static-linked systems I've ever used because of this -- that is of course until it is asked to do any actual computing or other I/O operations. :-) So, in an embedded system there will be many influencing factors, including such as how many exec()s there are during normal operations. For machines with oodles of memory and very fast and large SSDs (and using any kernel with a decently tuneable paging system) one can simply static-link all binaries separately and achieve similar results, at least for programs that are run relatively often. For example the build times of a full system build of, e.g. NetBSD, with a fully static-linked host system and toolchain are remarkably lower than on a fully dynamic-linked system since all the extra processing (and esp. any extra I/Os) done by the "stupid" dynamic linker (i.e. the one that's ubiquitous in modern unixy systems) are completely and forever eliminated. I haven't even measured the difference in years now because I find fully dynamic-linked systems too painful to use for intensive development of large systems. Taking this to the opposite extreme one need only use modern macOS on a machine with an older spinning-rust hard drive that has a loud seek arm to hear and feel how incredibly slow even the simplest tasks can be, e.g. typing "man man" after a reboot or a few days of not running "man". This is because on top of the "stupid" dynamic linker that's needed to start the "man" program, there's also a huge stinking pile of additional wrappers has been added to all of the toolchain command-line tools that require doing even more gratuitous I/O operations (as well as running perhaps millions more gratuitous instructions) for infrequent invocations (luckily these wrappers seem to cache some of the most expensive overhead). (note: "man" is not in the same boat as, e.g. the toolchain progs, and I'm not quite sure why it churns so much on first invocations) My little static-linked i386 system can run "man man" several (many?) thousand times before my old iMac can display even the first line of output. And that's for a simple small program -- just imagine the immense atrocities necessary to run a program that links to several dozen libraries (e.g. the typical GUI application like a web browser, with the saving grace that we don't usually restart browsers in a loop like we restart compilers; but, e.g. /usr/bin/php on macos links to 21 libraries, and even the linker (ld) needs 7 dynamic libraries). BTW, a non-stupid dynamic linker would work the way Multics did (and to some extent I think that's more how dynamic linking worked in AT&T UNIX (SysVr3.2) on the 3B2s), but such things are so much more complicated in a flat address space. Pre-binding, such as I think macOS and IRIX do (and maybe can be done with the most modern binutils), are somewhat like Multics "bound segments" (though still less flexible and perhaps less performant). -- Greg A. Woods <gwoods(a)acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca> Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>

Greg Woods responds to my posting: I meant "dump" as a generic verb, not specifically the Unix dump utility. Many sites also used tar to backup directory trees: after all, tar means Tape ARchiver. That was, however, contingent on a reliable signal from the tape unit, and my strong recollection is that when we moved to various types of cheap cassette tapes, the end-of-tape indicator was unreliable. Thus, we paid attention to both disk and tape sizes. Today, with 10TB+ on LTO-8 tapes, it isn't an issue for us, and we also tend to have many different ZFS volumes representing various parts of the filesystem, allowing different backup and snapshotting policies. Besides tapes and snapshots, we also have a live SAN mirror, and a remote snapshot server, giving plenty of data replication, and the warm fuzzy feelings from that. After 20 years of ZFS, I don't recall us ever losing data. We have also gone through two generations of major fileserver upgrades and complete data migrations without service interruptions (except for a brief interval for each user account to synchronize data on old and new servers). ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------