The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: ron@ronnatalie.com (Ronald Natalie)
Subject: [TUHS] /bin/true (was basic tools / Universal Unix)
Date: Thu, 19 Oct 2017 22:05:15 -0400	[thread overview]
Message-ID: <83C77FBE-A007-4F06-AB2B-0203710576D7@ronnatalie.com> (raw)
In-Reply-To: <FEE2FA3E-A7F8-484D-81F2-CC390B11E12D@orthanc.ca>

Of course, 4K is in the noise on a machine with 32 Gig or more of memory.

The old PDP-11 could put a 136 byte executable (assuming the standard UNIX V6 a.out header into two 64 byte chunks of memory.    Not too shabby even in those days.

> On Oct 19, 2017, at 9:31 PM, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:
> 
> 
>> On Oct 19, 2017, at 6:27 PM, Dan Cross <crossd at gmail.com> wrote:
>> 
>> macOS requires you to have a data section aligned to 4K, even if you
>> don't use it. The resulting binary is a little over 8K; again, mostly
>> zeros.
>> 
>> There are parlor tricks people play to get binary sizes down to
>> incredibly small values, but I found the results interesting. Building
>> the obvious C program on a PDP-11 running 7th Edition yields a 136
>> byte executable, stripped. Still infinitely greater than /bin/true in
>> the limit, but still svelte by modern standards.
> 
> No matter how tiny you can make the a.out, the kernel's still going to have to map in at least one page to hold it, so you're eating a minimum of 4K on any modern machine, regardless.



  reply	other threads:[~2017-10-20  2:05 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-19 14:52 /bin/true (was [TUHS] " Ron Natalie
2017-10-19 15:01 ` Pete Wright
2017-10-19 15:17   ` Chet Ramey
2017-10-19 21:23 ` Steffen Nurpmeso
2017-10-19 21:43   ` Chet Ramey
2017-10-19 23:00     ` [TUHS] /bin/true (was " Dave Horsfall
2017-10-19 23:14       ` Grant Taylor
2017-10-19 23:23         ` Lyndon Nerenberg
2017-10-19 23:27         ` Kurt H Maier
2017-10-22  4:18           ` Dave Horsfall
2017-10-20 12:10       ` Chet Ramey
2017-10-19 21:43 ` /bin/true (was [TUHS] " Dave Horsfall
2017-10-19 22:04   ` Ronald Natalie
2017-10-19 23:25     ` [TUHS] /bin/true (was " Dave Horsfall
     [not found] ` <CAEoi9W7YZ7YXUip0JTMGip3Nd0czgdjqRCMRcK2GYmDJsckuDg@mail.gmail.com>
     [not found]   ` <CAEoi9W4zdJ3+RXjK5-5rAJ6rwx_0kx6N-bn1U61=txJGyLT_mw@mail.gmail.com>
2017-10-20  1:27     ` Dan Cross
2017-10-20  1:31       ` Lyndon Nerenberg
2017-10-20  2:05         ` Ronald Natalie [this message]
2017-11-28 16:21 ` Nemo
2017-11-28 17:56   ` Warner Losh
2017-11-28 18:26     ` Dan Cross
2017-11-28 18:41       ` Warner Losh
2017-11-28 19:09         ` Dan Cross
2017-11-28 20:34           ` Clem Cole
2017-11-28 22:42           ` Ralph Corderoy
2017-11-28 18:34     ` Bakul Shah
2017-11-28 23:25     ` Ralph Corderoy
2017-10-22 23:00 Doug McIlroy
2017-10-23  1:11 ` Dan Cross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83C77FBE-A007-4F06-AB2B-0203710576D7@ronnatalie.com \
    --to=ron@ronnatalie.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).