On 12.03.2015 18:12, Laszlo Papp wrote:
It is nice that you are trying to help and I certainly appreciate it,
but why cannot you simply do that job nicely outside busybox where
*you* have to be responsible for that project? It would be an explicit
way of enforcing KISS and not putting more burden on Denys.
If you talk about development and testing, yes ... but my need is a one
system one static binary approach ... and I really want to put in that
extended functionality ... so running it as a separate project would
mean to fork the Busybox project ... public or private, does not matter
here ...
... I have an idea, to those preference questions ... may be it is of
general interest ... could even reduce some development pressure from
Denys ... may be ... but let me check some details, before I write a
message in a new thread for this, to see what other think about it ...
If you can convince the busybox community to split up the
maintainership, perhaps that would be a completely different
discussion to start with, but in all honesty, I do not like these
"monolythic" projects. I still stick by that KISS is a good thing. If
I could, I would personally replace busybox with little custom tools
on my system, but I currently do not have the resource for that.
Therefore, all the complexities and non-kiss that goes in is something
I need to accept.
... and I go the different way, hook up a complete system with a single
statically linked binary (ohps currently two, Busybox and dropbear) ...
though, peoples preferences are different ... I try to do not force
anybody else to do things in a specific way, but I don't want to be
forced by others ... and I dislike placing that stuff in (a) different
file(s), except for a very good reason (e.g. minimalist memory usage on
plug helper, and daemon - but that has to be discussed)
Asking for feedback is good, nothing wrong in there; putting this into
busybox this way is wrong on the other hand IMHO.
Peoples preferences are different, but when blocking every innovation in
Busybox you force me to do things in your way! ...
... so my possibilities would be: Either forking Busybox project or
dropping all my development forever ... both not very welcome! :(
And don't ask! It's preference, not technical, or knowledge ...
And why grumbling about a few bytes on one hand, and then throwing in
other stuff? The netlink functionality has been requested by others to,
but I see there are people who like to stay at kernel hotplug mechanism,
or even semi automatic device setup, so why shall we not enable the base
functionality for all of them, with maximum code sharing, so user may
decide which function to use or possibly opt out on config? Otherwise I
do not want to break existing setups, but was poked to clarity, that is
splitting of functions which do logically not belong into separate
commands ... no trouble for me to do this, but then we may need to do
some slight modifications to startup scripts (one or two lines or
command parameter) ... everything has it's pros & cons ... even writing
lengthy mails ... which consume the time I could otherwise use for
development ... :(
--
Harald
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
