Seriously guys? On Maemo with its constant swapping you are worrying about damaging flash with shell history? Really?

Most "power" users run at least one swap on SD.
I also wish to reduce flash wear as best as I can, not promote it.

But if you put that new split-off binary with the '-power' features into /opt/.../whatever, while it might not cause problems for users using relative stock devices, it causes problems for any busybox-power user that uses busybox-power features at early-boot stages, such as my /sbin/preinit shell prompt thing - I see later down in the log this got brought up, and I even got mentioned by name, so I see my main concern isn't likely to be a problem with this setup, but then, if we're okay with 100/150kB size increase, saying we're not okay with 500kB is pretty arbitrary - especially when other rootfs-located files are larger by orders of magnitude and some of those can be safely optified on the vast majority of devices. (Edit: and by this I mean most likely all devices, I just can't bring myself to speak in absolutes unless I am damn certain there aren't exceptions, on principle.)

I do appreciate the fact that everyone in that log, in their own way, is trying to make sure users are happy. But at the same time, after reading the log I still see very little merit to the arguments presented against inclusion of busybox power as-is (maybe it's because I actually pay attention to what unoptified packages cram my rootfs after install, and go through the trouble of optifying the biggest offenders? I actually have shell scripts saved for optifying GCC, G++, libc-dev, Ruby, PHP, so I don't have to manually do it every time an N900 requires reflashing....). The whole thing seemingly boils down to "it got compiled in with new features, so the 500kB of extra size is bad" - but if that same 500kB of extra space came from upstream bugfixes and code improvements only, I somehow don't think anyone would be arguing against it as much - mainly because CSSU has happily updated other system packages in a way that by now has probably netted far more rootfs consumption than busybox-power could.

If we want to optimize things to conserve rootfs space, there's plenty of libraries in rootfs, and more-over other standard linux/unix directories that currently map to rootfs that other packages tend to install things into, that don't really need to be in rootfs, and could safely be moved and symlinked over by CSSU, that are vastly less likely to be desirable in a rootfs-mounted-only state, than busybox-power commands. Even things like httpd in busybox-power are likely to be more useful to someone than, say, having the microb-engine or the nokia-maps files in rootfs, because how likely are you to be browsing the internetz with microb or using maps when only rootfs is mounted? And these are optifications known to be completely harmless since the N900 was fairly new - and who's impact on performance is negligible. (And just optifying either of those by default leaves far more free space in rootfs than 500kb extra of busybox-power does.) If either of these optifications have been made standard in CSSU installs and I haven't noticed, I apologize for missing it, but I don't think they have? (And if they have, then we're already far into net gain for rootfs space, even with busybox-power.)

I also somehow I don't think if, for example, mohammadAG (who if I recall correctly helped get the CSSU organized to the point of finally being released initially) had decided to upgrade the busybox package with the features of current busybox-power, any one of the CSSU maintainers would have blinked at just making it the default busybox or even thought too hard about allowing user choice to preserve that 500kB.

(As I said in my prev. post though, I think user choice is wonderful, but I think the greatest advantage to the greatest amount of users, with the least choices forced upon the user, is in this case to make the standard CSSU busybox, busybox-power, and a less feature-filled busybox for space-conservation can be limited to those who really want the rootfs space. Failing that, I am undecided as to whether separate packages are really worse than one that splits the -power features into opt, since two packages might inconvenience some users minutely, but one package will greatly inconvenience a small amount of users. Yes, I might only care for a few specific tools that -power brings, for /sbin/preinit - but we sure can't use me as the standard for what -power features ought to stay in rootfs, because I am hardly the epitome of shell-scripting skill.)

Meh. Worse case scenario, some users be where we are now anyway (having to manually redo things with busybox after every official update) while most others are hopefully happy or at least happier, with the new predicament.

- Edit 2 -
Yes I know I forgot to really address the whole issue of thorough testing being needed before CSSU inclusion of busybox upstream fixes, let alone busybox-power, that's mainly because I am tired, although in short I consider countless users booting without noticed problems countless times to be a very good test - it's not a rigorous test, but to reject it as being insufficient until enough manpower/hours is spent on complete code coverage of initscripts or whatever the proper terminology is simply 'perfect solution fallacy'. And as an aside I feel like that's a pragmatic issue which is to be considered only after the more principle-relevant issue of whether or not (and how) busybox-power or some subset thereof ought to be included into cssu.

Thanks Mentalist, that is exactly my thinking.
So just want to second to your argumentation.

+1 one to that. Glad to have you back, I am a bit jalous how well you can elaborate and support your reasonable opinion (and the opinion of others, incl me). Thanks!

I'm absolutely glad, that so many respectable users opt for busybox-power in CSSU. hoever, I would suggest pasting those posts to CSSU-testing thread - I got sneaky suspicions, that CSSU maintainers doesn't have habit of reading this thread. Really!

The biggest reason to include power in cssu is that programs that are dependant on power can be easily distibuted to everyone thru the repositories, and for scriptdevelopers, no need to worry about if a command is a powercommand or not...
The same with discussions in the forums, no need to worry about powercommands when helping someone.
The whole function of powerbusybox is to add functionality and useroptions that are vastly more powerful than portraitmode.
-So, if it is important to save space, then remove portrait support and let that portrait busybox be distributed in the repositories, since that doesnt matter where it is distributed.

Edit:
CSSU should focus on internal stuff inside the system, add functionality that other programs can rely on, and that developers and other people can safely assume that they are there for everyone.

And not as it is now to add bells n whistles that can be distributed elswhere without any difference.
Powerbusybox adds functionality that can be used by other programs, while portraitmode and other themes, only wastes some space and processingpower on a *theme* without any added functionality at all to the system itself.
-Just let those who wants portraitmode to install it themselves, and dont distribute it thru cssu, since it doesnt belong there at all.

Thanks for the pretty good explanation on why bbp is not any helpful in rootfs and mandatory CSSU.
a) if your package really *needs* bbp commands in early boot where /opt isn't yet available, you have a problem anyway and should consider how to solve it locally in your pkg
b) if packages generally want to use bbp commands, they can DEPEND on bbp and use proper FQN to the binary, to invoke those commands.
c) IF we'd provide bbp to 'everyone', where would all those packages live that actually exploit those extended functions? In extras? In extras-devel? In CSSU-testing, as optional packages? There's no way a package in extras(-*) repo could DEPEND on CSSU stuff.

As a general rule, CSSU isn't inclined to sacrifice backward compatibility to stock maemo, for convenience of lazy (script-)coders

/j

ps: portrait support in bb-basic is a 2char patch that adds ZERO in bytesize to what bb binary will use - pretty easy both to verify patch sanity as well as considering storage space requirements in rootfs.

But why to talk about it again? It's already clear, that busybox-power will be in CSSU, if iDont will waste commit time to separate it into two packages. I though, that opinion of both busybox-power author, and CSSU maintainers, is already 100% clear, and advocates from outside CSSU "team" - like me or joerg - have nothing to do anymore, in this case?
---

Going back on topic - iDont, have I missed something, or Your latest update haven't made it into cssu-thumb, and thumb equivalent is one version into the past? Is it just forgotten, delayed, or I just got confused?

/Estel

I figured I would push a new version of busybox-power pretty quickly after the last (intermediate) version, hence I skipped sending the sources to freemangordon for inclusion in community-thumb. However, I was wrong, evidently.

Since it looks like it can take a little while longer to get a response over at BusyBox' bugzilla (re the terminating signal handler), I'll probably just go ahead and include my patch in busybox-power and keep that build in extras-devel until I've got some upstream response. I'll make sure freemangordon received the appropriate sources for the new build as well.

Thanks for this. There's not much more to be said with regards to busybox-power & CSSU (it's up to me now), so I'd prefer to let the subject rest as well for now.