Bloat: How and Why UNIX Grew Up (and Out) - Rusty Russell,Matt Evans

A good article a while back looked at common unix utilities, comparing the size of commands like cp from the 1980's to the present. Most of the bloat had to do with features that almost nobody ever uses. That was actually a talk called "Bloat: How and Why UNIX Grew Up (and Out)": ▶ this video Well worth a viewing.

There was an interesting talk on this at Linux.conf.au a couple of years ago, trying to figure out why modern binaries are so large. ▶ this video > Bloat: How and Why UNIX Grew Up (and Out) - Rusty Russell, Matt Evans > The 'ls' binary on the original release of Unix (version 6) was 4920 bytes long. Thirty six years later, 'ls' on Ubuntu is 105776 bytes. Is this the laziness of modern coders? Increasing features? Does 'cat' really now do 313 times more stuff, or is there something else going on?

Now you just need to design a balanced ternary computer which uses lambda calculus instead of Boolean logic and you will be a quarter of the way to getting rid of the gunk left over from the birth of computers when people were arguing if relays or vacuum tubes were the way of the future. The one thing I have noticed all the people with "philosophical" objections to bloat have in common is that they are largely ignorant of the real hardware and software they are coding on. This was brought nowhere better to the front than in this video ▶ this video where they showed that the tools written because gnu tools were too big when measured in a running computer take up just as many resources.

>This was brought nowhere better to the front than in this video ▶ this video where they showed that the tools written because gnu tools were too big when measured in a running computer take up just as many resources. At what time in the video does that happen? I didn't have time to watch the whole thing, but it doesn't appear that what you are suggesting was even brought up much less demonstrated?