[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: Sime makelike wrapper scripts support
From:       Eli Schwartz <eschwartz () archlinux ! org>
Date:       2020-01-15 16:50:56
Message-ID: 479b5209-4ff9-421d-200b-7430cf86843c () archlinux ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]

[Attachment #4 (multipart/mixed)]


On 1/14/20 4:46 PM, Jody Bruchon wrote:
> The tools patch and diff make sense to include because they're simple
> text manipulation utilities that can be handy in embedded
> environments. "Make" and similar programs are universally meant to be
> a component of a compilation toolchain, something which is well
> outside the scope of BusyBox.

diff and patch are universally meant to be a component of a source code
development, distribution, and compilation toolchain. Just like make.

Sure, you could use all three of them for other purposes, and many do.
make is pretty easily (ab)used for all sorts of things, diff/patch less
so (I use diff for crude revision comparison of prose text in addition
to source code, patch could be used to binary patch updates??? but you
could also use xxd, assuming you made busybox xxd support some common
options that actually allow this).

I'd consider it just as reasonable to remove the diff and patch applets
as to add a make applet, and I'm not strongly attached to either approach.

At least "it's exclusively intended to be useful in a development
environment" is a useful objection to inclusion, which I could get
behind. The problem is that this is currently not the case...

> Anything that's complex beyond a
> certain arbitrary point doesn't belong in BusyBox. That's why
> Dropbear (ssh), Perl, Python, Lua, Git, and several other extremely
> common programs are not present, despite the fact that their presence
> might be useful to some people. If you need make, build GNU make and
> distribute it alongside the BusyBox binary. Same for your favorite
> programming or scripting language. It's not hard to do.

This is not even remotely comparable... there are brutally obvious
reasons not to include a program that represents an actively-developed
moving target, which all of these are except for dropbear, because by
definition they become useless or no longer work after a couple of years
unless you constantly track upstream.

Moreso for a programming language like python, which documents the
availability of a GUI windowing toolkit...

Moreso given that the standard perl distribution on my system is 56 MB,
and python is 151.84 MB.

It is possible to build python implementations for embedded systems
which are much smaller (micropython), but those are also useless for
average use, because they implement the syntax without the stdlib. It
also froze the language. So any scripts you write for this have to be
targeted specifically to the implementation, and are not
cross-compatible with the mainstream language. This is approximately
what you can expect of trying to embed a giant programming language.

perl supposedly has microperl as something you can build from the
official source distribution, but its goal seems to be "test perl with
minimal configurations as a single executable", which doesn't
necessarily translate to size efficiency, and also it's one person's toy
which doesn't actually build, so RIP. That would be the other approach
to trying to embed a giant programming language.

> A lot of people seem to think that there's zero penalty for including
> another program in something like BusyBox. I question the knowledge
> level of such people, because anyone who touches any remotely sizable
> programming project will quickly see that isolating portions is
> nearly impossible. Whenever you add an applet and there's a problem
> with it, someone has to fix it. If the maintainer decides to update
> the internal interfaces for something like getopt, then every applet
> has to be updated to fit that new interface, including your mim/make
> applet. There are maintenance and fix chores that will force other
> people to poke at your applet. You do not incur zero penalty for
> adding it to BusyBox.

If you'd get off your high horse for a second, no one has suggested
that. Although, personally, I did suggest that disabling it by default
would produce a "zero-byte installation footprint penalty" for people
who don't want to enable it.

Have we somehow gone from claims of a zero-byte installation footprint
penalty to claims of "if you add this code, you can then forget it
forever and ever, and never edit the source code", without me noticing?

Your argument boils down to "code adds complexity, therefore never add
new code". It's not a new argument. This is why *any* new applet,
including any proposed "make" applet, would be potentially "worth
considering", not "the idea is so utterly ludicrous how dare you even
think about mentioning it".

Consideration, obviously, involves considering. For example, considering
how maintainable it is, how much additional code it requires adding, and
how useful it might be.

It's certainly possible the answer to all these are "not very", "too
much", and "not really". But I'm skeptical the answer is "you're a moron
for even asking, go away".

> The bottom line is that Make programs are a type of program that very
> clearly do not belong in BusyBox for philosophical and scope reasons,

I don't see either the philosophical or scope reason with any clarity,
if your python comparison was meant to prove this then it was a
miserable flop.

Personally, I'd rather this thread discuss whether a make implementation
is suitable for inclusion, instead of "please include my useless
boutique mim.sh shellscript which does things specialized to my personal
needs and I just invented today".

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User


["signature.asc" (application/pgp-signature)]

_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


[prev in list] [next in list] [prev in thread] [next in thread]