Active Topics

 


Reply
Thread Tools
joerg_rw's Avatar
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#281
Originally Posted by Estel View Post
False - busybox power brings tons of upstream bugfixes and optimizations. Obviously, without breaking anything
well, then i hope those bugfixes are in that CSSU bugfix of standard busybox as well (though, not really, see two § below). Otherwise don't blame me but the one who missed to include them. However that argument is irrelevant regarding inclusion of busybox-power to CSSU.
Also, it's funny, that You started to care for few kb in root space - then, you should be major advocate of bringing thumb2 support to CSSU, as it saved *much* root space.
The really funny thing is your effort to turn my words against me by perverting their meaning. CSSU is conservative, and quality of paramount importance (basically both one same thing) and thus we won't lightheaded consider swapping a whole distro to a different toolchain and build options (means 'new' untested program versions for basically everything) just for getting the new property of saved bytes in rootfs, while same time we won't include busybox-power not only because of introducing changes and thus risks that are not justified by general need (since everybody has the option to get busybox-power from default extras-* repos, something that per definition excludes inclusion to CSSU), but also we don't waste kilobytes of rootfs for this (regarding CSSU) absolutely useless improvement (maybe to stop shitstorms: it's useless just for CSSU, in the sense that nothing in CSSU depends on busybox-power improvements)

Now, waiting for You to bring "compatibility with scripts relying on bugs" argument, that You have used on IRC...

/Estel
Your wish be my order, this single time: We already know since ages that maemo initscripts are all but posix-safe, and that you might get a bootloop by overriding/replacing busybox by proper bash for default shell, and unix-tools. This is clearly a bug in initscripts that in turn only works since busybox also has a bug (as otherwise - if busybox was 100% compatible to bourne shell as it's supposed to be, there wouldn't be that weird bug in the scripts). Now replacing stock 'Nokia' busybox by busybox-power (or a 'bugfixed' normal busybox, see above ref to here) with "a lot of upstream bugfixes" might as well fix that bug in busybox that's needed to make initscripts work. Are you going to analyze all the initscripts to spot those locations where such problem might happen? If yes, please come up with a proper work package done incl complete analysis result report *) and patches to initscripts - if not, please stop arguing at this poor and pretty insulting level.

/j



*) to simplify this task for you, it might actually be sufficient to find out what were the problematic commands in initscripts (back in pre-1.2 times iirc) and just check if the syntax and output (and semantics) of these busybox commands has changed due to the applied upstream fixes, and if the current initscripts still have those defective
lines.
In fact THAT would be some much appreciated contribution to CSSU, as opposed to your constant questioning of qualifications, motivations and decisions of CSSU team which doesn't really help much for anything
__________________
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member

EX Hildon Foundation approved
Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/

IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N

Last edited by joerg_rw; 2012-08-25 at 21:01.
 
joerg_rw's Avatar
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#282
Originally Posted by peterleinchen View Post
We are talking about 500k !
Not really meesing up rootfs space, or?

I, personally, can not imagine "living" with standard busybox and its limitations anymore. But can also live with ""optional"" installation, but would/do see this package as an (default) enhancement, also to CSSU.
Hi peterleinchen,
as you already noticed you can "live with" optional installation of busybox-power. That's your freedom of choice. You also mentioned that you "can't live" without busybox-power. Now maybe other users "can't live" without those 500k rootfs storage space. Keeping busybox-power optional is about their freedom of choice to keep those 500k free, as much as it is about yours to install busybox-power on top of CSSU.
That's one of highest principles in CSSU, not to force anything on users that they as well might decide on by themselves.
It about freedom of choice.

cheers
Joerg
__________________
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member

EX Hildon Foundation approved
Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/

IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N
 

The Following 2 Users Say Thank You to joerg_rw For This Useful Post:
Estel's Avatar
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#283
First of all, it is not place to discuss CSSU ideals, IMO. Fortunately, for what I know, both busybox-power and cssu-thumb - mentioned here - are on their perfect way for inclusion into CSSU, despite attempts by "some vocal ones with almost no (if any) actual coding contribution (to CSSU) for the last 2 years". I'm glad, that it's time, when people more active in contributing to Maemo (outside IRC) during last years, start to decide more and more how CSSU should look like.
---

As for busybox itself, I don't necessary understand, why busybox-power upstream patches should be extracted and included into another incarnation of busybox project, in Your opinion. Busybox-power is *all* of upstream patches, so why to clone it? You just don't like anything with "power" in name, or what?

Last but not least, busybox-power is well tested (and nothing from standard Maemo "busybox-aware" scripts gets broken), both by developer, and by countless users - I would risk to say that more, than CSSU have or will ever have. No matter of the above, it's definitely better tested, that parts of CSSU have been (swapping return with kp_enter)

Kudos to IDont for all great work put into busybox-power - don't get distracted completely minor thumbs down, based on non-merit reasons. We all keep thumbs, both up and kept ( ) for busybox-power (and again set of thumbs-up for merlin1991, for, basically, deciding to include busybox-power in CSSU, sooner or later).

/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 

The Following User Says Thank You to Estel For This Useful Post:
joerg_rw's Avatar
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#284
dream on dreamer!
Those who know to read will judge you on your words. And as much as you try to suggest, you're neither maintainer nor any form of active contributor of CSSU, nor any active council member anymore despite what your signature tells, and thus not in a position to define what's criteria for merit to have a word on CSSU. It's actually like it's you who is trying to push "own prefferences" and "ideology", but we've seen that pattern a lot with you accusing others for what you currently are doing yourself.

PS: since it's not been me who started that nonsense here, I only can say I'll not further contribute to this (don't feed the troll). And just a suggestion to others: don't believe the lies estel continuously spreads! every second sentence of him includes an implicit lie. Quotes? sure! >>and again set of thumbs-up for merlin1991, for, basically, deciding to include busybox-power in CSSU, sooner or later<<
__________________
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member

EX Hildon Foundation approved
Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/

IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N

Last edited by joerg_rw; 2012-08-26 at 04:38.
 
electroaudio's Avatar
Posts: 381 | Thanked: 336 times | Joined on Jan 2011 @ Stockholm, Sweden
#285
Originally Posted by joerg_rw View Post
CSSU is conservative, and quality of paramount importance (basically both one same thing)
So why even bother with such useless features as portrait mode in busybox then!?...

Wouldnt it be *much* better to spend time on bugfixing or cleaning up annoyances with hildon for example, or even to have a life, rather than to spend a lot of time and effort to introduce such an annoying *bug* as a rotating terminal?
__________________
Deskypplet , a desktop for N900 *RIP*
 

The Following 7 Users Say Thank You to electroaudio For This Useful Post:
Posts: 1,397 | Thanked: 2,126 times | Joined on Nov 2009 @ Dublin, Ireland
#286
Originally Posted by joerg_rw View Post
replacing busybox by busybox-power eats rare precious space in rootfs (due to larger binary size of busybox-power), since busybox is needed during early boot and thus has to live in rootfs. I.E. it can't get optified.
Busybox-power however doesn't - by default - bring anything new that might justify indiscriminate waste of rootfs space for it, on all CSSU installs.
It's absolutely reasonable to keep busybox-power optional for those users who think they need it and want to accept the rootfs penalty it comes with.

/j
500 Kb of rootfs is by no means a valid reason to ban busybox-power from CSSU. And if rootfs space was so important to even care so much about 500 Kb, we should then jump right now to Thumb2 to fix that incredibly important limitation.

You have commented a lot of times that CSSU is here to provide updates and fixes for packages that can't be distributed via Extras. OK, then busybox-power, that can't be really distributed in a very clean way (it needs to replace original binary!!), is a perfect example of something that should be distributed by CSSU. Otherwise, you could argue that everything can be distributed providing binary replacements instead of upgrading packages (let's include Qt4.7.4 in Extras as a substitution of .so files!!).

If busybox-power is in Extras, it's simply because it was packaged before CSSU started. It was such an important need for users that it was one the first replacements to original Nokia software. Also it comes with tons of fixes not available in CSSU, not simply new features.

Last edited by ivgalvez; 2012-08-27 at 09:08.
 

The Following 7 Users Say Thank You to ivgalvez For This Useful Post:
Posts: 1,397 | Thanked: 2,126 times | Joined on Nov 2009 @ Dublin, Ireland
#287
Originally Posted by iDont View Post
A general notice: next CSSU release will ship a new version of Maemo's default BusyBox; one with portait mode support. This means that your /bin/busybox will be changed to CSSU's version.

Simply reinstalling busybox-power (either graphically or via the terminal) will get you busybox-power again. I'll make sure to incorporate all patches from CSSU's busybox in busybox-power so you won't miss out on any new functionality or bugfixes.

There is one important detail, however! If you've made manual modifications to Maemo's critical scripts (e.g. /sbin/preinit) that made those dependant on busybox-power during boottime, you will have to revert those prior to updating CSSU. Otherwise you could risk a boot loop.

Lastly, upon removal or reinstallation of busybox-power, busybox-power will detect and warn you if /bin/busybox has been changed. You can safely ignore this warning, as we know what has caused it (CSSU update changing /bin/busybox).

The above message will be included in the first post of this thread.

Edit: I've updated the warning message mentioned above in busybox-power 1.20.2power1. It now states why /bin/busybox could've been modified, and explicitly mentions CSSU as a possible cause. Just to comfort users who may have missed this post .
To help people that might not be aware of this problem, you could simple bump busybox-power version after next CSSU's update to provide a reinstallation. The issue, however, will appear again when that update makes it's way into CSSU Stable (for those using that flavour of CSSU).

However, this is by no means a solution to the root cause of this problem, which is that bb-power shouldn't be distributed via Extras as a replacement of a system binary.
 

The Following 5 Users Say Thank You to ivgalvez For This Useful Post:
Posts: 385 | Thanked: 426 times | Joined on Dec 2009 @ Gothenburg, Sweden
#288
If true, I'm kinda of curious, why in the world would anyone want a busybox with portrait mode support when the hardware keyboard only makes sense in landscape mode.
This would only irritate people if the terminal keeps rotating all the time (like many other applications usually do when they most of the time shouldn't).
On top of that, CSSU would in such case replace the busybox-power (which is much improved compared to the stock one) with this rotating atrocity. So how's that for freedom of choice?
Well at least to me, that would be the worst crap feature of the year.
Where's that thread discussing this matter, I'd really like to know who came up with the "brilliant" idea.
 

The Following 3 Users Say Thank You to Larswad For This Useful Post:
Posts: 1,100 | Thanked: 2,797 times | Joined on Apr 2011 @ Netherlands
#289
I thinks it is best that the behaviour of this potrait mode feature is explained in more detail by the ones involved.

Right now, I do not see any change in behaviour with the latest busybox. But I would expect the xterminal to be adapted for that.

If we get a proper proper portrait virtual keyboard (looks like it is arriving), I would not mind that option. It should switch back to landscape if the keyboard is open.

Until I have seen more info about this, I can't really judge it.
 

The Following 2 Users Say Thank You to ade For This Useful Post:
Posts: 385 | Thanked: 426 times | Joined on Dec 2009 @ Gothenburg, Sweden
#290
Originally Posted by ade View Post
I thinks it is best that the behaviour of this potrait mode feature is explained in more detail by the ones involved.

Right now, I do not see any change in behaviour with the latest busybox. But I would expect the xterminal to be adapted for that.

If we get a proper proper portrait virtual keyboard (looks like it is arriving), I would not mind that option. It should switch back to landscape if the keyboard is open.

Until I have seen more info about this, I can't really judge it.
Yes, I shouldn't say too much about it until I know how it will be, but just by hearing about it I really really can't see any valid point in introducing that.
One of the reasons to stick with the N900 is that the terminal is so GOOD with the phys. keyboard. Why would I then start typing on a virtual keyboard, that indeed would SHRINK like half of the screen in portrait mode (the whole thing is actually kind of laughable).
Ok, if it wouldn't rotate when the keyboard is out, I wouldn't mind that much (even if it makes no sense to rotate it even if the keyboard is in), but if it forces itself to install over the busybox-power it really irritates me even if I can reinstall busybox-power.

I just hope the CSSU team doesn't add things to the CSSU just because they can code them.
 

The Following 3 Users Say Thank You to Larswad For This Useful Post:
Reply


 
Forum Jump


All times are GMT. The time now is 13:27.