A question of philosophy
David Collier
from_busybox_maillist at dexdyne.com
Mon Feb 7 14:07:00 UTC 2011
Denys,
I have no word of complaint about you changing busybox... I think it's a
great project, and I approve of the direction it's moving in.
I'm just highlighting the fact that no improvement you do to the current
build can fix what I encounter on existing computers.
On top of that I find that for simplicity I need a constant shell
environment
I really don't want to face trying to write scripts without functions..
and as far as I can see the ash syntax is incompatible with the bash one,
and vice-versa.
So at this moment I'm tempted to bundle busybox with my application, and
get it to use only the bundled busybox. That gives me back the control I
need.
D
In article <201102042324.25855.vda.linux at googlemail.com>,
vda.linux at googlemail.com (Denys Vlasenko) wrote:
> *From:* Denys Vlasenko <vda.linux at googlemail.com>
> *To:* busybox at busybox.net, from_busybox_maillist at dexdyne.com
> *CC:* Andrew at dexdyne.com, jeredb at dexdyne.com
> *Date:* Fri, 4 Feb 2011 23:24:25 +0100
>
> On Thursday 03 February 2011 11:45, David Collier wrote:
> > Denys,
> >
> > your suggestion above for fixing tar to work with stdin is
> > wonderful -
> > and I'm sure it will work.
> >
> > But it illustrates the different world-views that you and I have.
> > In an
> > illuminating way.
> >
> > You think/speak as if busybox is infinitely mutable, and an issue
> > can be
> > changed by improving it.
>
> Of course, that's what developers do: they change software.
>
> However, I do not change busybox in a random way. I generally try
> to make
> busybox tools more similar to tools available on "big Linux",
> so that people can use the same scripts and expect the same
> behavior.
>
> In this particular example, "tar -T -" is supported by GNU tar,
> therefore I made busbox tar to do the same.
>
>
> > I think of the busybox version I find on
> > existing computers as part of the fixed background, and am
> > looking at
> > ways to work with any/all of them without changing them.
> >
> > If I need to do something to my application, I would like it to
> > work on
> >
> > the systems I have in the field running feature-lite busybox
> > 0.60 ( Good Lord )
> > the ATNGW-clones which run 1.13 non-desktop
> > the dev sys on my desk running 1.17 desktop
> > the PCEngines board which has Debian,
> > but for some reason also has busybox 1.10 lying around.
> >
> > I have now understood that
> > O different revisions of busybox have made different choices
> > - the standard columns output by ps have changed over time.
> > O even the same issue level of busybox may have been built with
> > or without many options - so the ps command may, or may not,
> > support the -o option to customise it's output.
> > Therefore I can't depend on the field order, nor on the presence
> > of an
> > option to alter it
> > I've solved that by poking around in /proc ... but heaven help
> > us, that
> > may not even exist on some computers, so I will need yet another
> > level of
> > complexity for full portability :-(
>
> Well, world is full of computer systems, and their upgrade cycles
> can be wildly different (and sometimes really haphazard).
>
>
> > Without risking breaking those boxes, which are sitting in fields
> > in Peru
> > and other places, and I CANNOT afford to go and reboot them.
> >
> > Now you might WELL say to me that I'm looking at it wrong. You
> > may say
> > that when I install my updated s/w I should also install a new
> > busybox
> > exe, on whatever machine, and use it.
>
> No, I understand you might have no control over that.
>
>
> > You might even say that all of my s/w should use "busybox ps", or
> > set a
> > path at start-up so that busybox is preferred to any Debian
> > utilities
> > lying around.
> >
> > Maybe that is the right approach, and I should get used to the
> > idea that
> > busybox is actually part of my app, not part of the system.
> > Except there
> > are things in /etc/init.d that use busybox too. Maybe I need to
> > download
> > and update EVERY script on the system with my app. Better find
> > them all
> > first.
> > And if anything else I don't update is doing system() calls I'd
> > better
> > pray the new busybox works the same.
> >
> > Perhaps I should set up myapp/sbin myapp/bin myapp/usr/bin and
> > myapp/usr/sbin and stick those on the front of the path, and set
> > links so
> > my app sees my latest busybox, but any existing s/w on the
> > machine sees
> > the environment it was used to...
> >
> > Do you, or does anyone else here, know how to square this circle?
>
> You will need to test your scripts on every deployed config
> and try to write scripts so that they work on all configs
> you support. If this is impossible, sometimes you will need
> to have several version of a script.
>
> To reduce amount of PITA, try to minimize the number
> of deployed configurations.
>
> --
> vda
>
More information about the busybox
mailing list