On Wed Feb 1, 2023 at 6:58 AM CET, Dominique Martinet wrote:
> Laurent Bercot wrote on Wed, Feb 01, 2023 at 04:49:47AM +:
> > > It should be fairly easy to do something like coreutils'
> > > --enable-single-binary without much modification
> >
> > The subject has come up a few times recently,
>
> I believe I did my homework looking first -- are there other discussion
> channels than this list that one should be aware of?
>
> > so, at the risk of being
> > blunt, I will make it very clear and definitive, for future reference:
> >
> > No. It will not happen.
>
> Well, thanks for the clear answer, I'm glad I asked first!
>
> I'm a sore loser though, so I'll develop a bit more below. You've
> probably got better to do so feel free to just say you're not changing
> your mind or pointing me at the other discussions and I'll stop bugging
> you.
>
> > The fact that toolchains are becoming worse and worse is not imputable
> > to execline, or to the way I write or package software. It has always
> > been possible, and reasonable, to provide a lot of small binaries.
> > Building a binary is not inherently more complicated today than it was
> > 20 years ago. There is no fundamental reason why this should change; the
> > only reason why people are even thinking this is that there is an
> > implicit assumption that software always becomes better with time, and
> > using the latest versions is always a good idea. I am guilty of this
> > too.
> >
> > This assumption is true when it comes to bugs, but it becomes false if
> > the main functionality of a project is impacted.
> > If a newer version of binutils is unable to produce reasonably small
> > binaries, to the point that it incites software developers to change
> > their packaging to accommodate the tool, then it's not an improvement,
> > it's a recession. And the place to fix it is binutils.
>
> I definitely agree with this, I reported the problem in the bz I linked,
> and the reception has been rather good -- I trust we'll get back to
> smaller binaries in the next version or otherwise near future.
>
> > Multicall binaries have costs, mostly maintainability costs.
> > Switching from a multiple binaries model to a multicall binary model
> > because the tooling is making the multiple binaries model unusably
> > expensive is basically moving the burden from the tooling to the
> > maintainer. Here's a worse tool, do more effort to accommodate it!
>
> I guess it isn't completely free, but it certainly isn't heavy if the
> abstraction isn't done too badly.
>
> I'd go out a limb and say if you only support single-binary mode, some
> of the code could be simplified further by sharing some argument
> handling, but it's hard to do simpler than your exlsn_main wrapper so
> it'll likely be identical with individual programs not changing at all,
> with just an extra shim to wrap them all; it's not like busybox where
> individual binaries can be selected so a static wrapper would be dead
> simple.
>
> > Additionally to maintainability costs, multicall binaries also have a
> > small cost in CPU usage (binary starting time) and RAM usage (larger
> > mappings, fewer memory optimizations) compared to multiple binaries.
> > These costs are paid not by the maintainer, but by the users.
>
> Hmm, I'd need to do some measurements, but my impression would be that
> since the overall size is smaller it should pay off for any pipeline
> calling more than a handful of binaries, as you'll benefit from running
> the same binary multiple times rather than having to look through
> multiple binaries (even without optimizing the execs out).
>
> Memory in particular ought to be shared for r-x pages, or there's some
> problem with the system. I'm not sure if it'll lazily load only the
> pages it requires for execution or if some readahead will read it all
> (it probably should), but once it's read it shouldn't take space
> multiple times, so multiple binaries is likely to take more space when
> you include vfs cache as soon as you call a few in a row; memory usage
> should be mostly identical to disk usage in practice.
>
> Anyway, I'll concede that in doubt, let's call it a space vs. speed
> tradeoff where I'm favoring space.
>
> > Well, no. If having a bunch of execline binaries becomes more expensive
> > in disk space because of an "upgrade" in binutils, that is a binutils
> > problem, and the place to fix it is binutils.
>
> I shouldn't have brought up the binutils bug.
> Even almost 1MB (the x86_64 version that doesn't have the problem,
> package currently 852KB installed size + filesystem overhead..) is
> still something I consider big for the systems I'm building, even
> without the binutils issue it's getting harder to fit in a complete
> rootfs in 100MB.
>
> Just looking at the s6 suite (s6, s6-rc, execline, skalibs,
> s6-linux-init) I'm looking at a 3MB increase (because I won't be able to
> get rid of openrc for compatibility with user scripts it'll have to live
> in compat
