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