Notices


Reply
Thread Tools
pichlo's Avatar
Posts: 6,445 | Thanked: 20,981 times | Joined on Sep 2012 @ UK
#21
Originally Posted by king Ralphred View Post
Anything that adds functonality to the phone should be included.
That's debatable (and, in fact, debated in this very thread ). One might argue that e.g. Whatsapp or whatever it's called "adds funcionality to the phone" but for me it's nothing more than useless piece of <expletive deleted>, along with Facebook, Twitter and other social <another expletive deleted>. I would definitely object to having extra stuff like that included in CSSU by default.

Replacing stock stuff with FOSS alternatives is acceptable as long as they do not break existing functionality and are proven bug-free. This is the point on which I sadly have to disagree with some FUSS advocates: In my experience, most open-source SW still has a long way to go to catch up with equivalent commercial offerings, especially in terms of the UI, usability and documentation (and, sadly, sometimes stability too).

I'm sorry but I suggest let's tidy up CSSU first before we embark on the FOSS crusade.
 

The Following 6 Users Say Thank You to pichlo For This Useful Post:
Posts: 3,074 | Thanked: 12,960 times | Joined on Mar 2010 @ Sofia,Bulgaria
#22
@pichlo - no matter if I agree with the "tidy-up", the brutal truth is that we just lack the needed resources to do that right now .
__________________
Never fear. I is here.

720p video support on N900,SmartReflex on N900,Keyboard and mouse support on N900
Nothing is impossible - Stable thumb2 on n900

Community SSU developer
kernel-power developer and maintainer

 

The Following 7 Users Say Thank You to freemangordon For This Useful Post:
nokiabot's Avatar
Posts: 1,974 | Thanked: 1,834 times | Joined on Mar 2013 @ india
#23
Originally Posted by sixwheeledbeast View Post
This I have also mentioned as I also think stable-thumb is the future. Having CSSU-thumb replace CSSU would involve forcing EVERYONE to upgrade there kernel to KP or KCSSU. Replacing a kernel has more issues than replacing packages. For starters we don't know everybody's setup and this may result in unbootable devices. Personally I feel many still use the N900 for it's UI. The purpose of CSSU is to prolong the use of our devices by providing updates and bugfixes not UI.
got it was just expressing my thoughts . Thumb is way faster and better in my device and about the ui i like it thats why i like the n900 but the bars seem too thick do you know a way how increase dpi or resoution
 
qwazix's Avatar
Moderator | Posts: 2,622 | Thanked: 5,447 times | Joined on Jan 2010
#24
Originally Posted by freemangordon View Post
@sixwheeledbeast: replacing the kernel is not that scary as it seems. We know about 3 things that will break if we replace omap1 with KP-clone:

1. fcam
- repaired by installing fcam drivers built against the kernel, we may even put such a build in the repo
2. joikuspot
- not sure about that one, there are a couple of FOSS alternatives
3. powertop
- this one is tricky, it doesn't stop to work, but gives some bogus info about CPU frequencies. And it was decided that OC patch will not go into kcssu-to-be on the first round.

Correct me if I am wrong, but I don't see any of ^^^ being a showstopper.
For fcam we just need to promote the drivers in -devel to extras. They work just fine with KP.
__________________
Proud coding competition 2012 winner: ρcam
My other apps: speedcrunch N9 N900 Jolla –– contactlaunch –– timenow

Nemo UX blog: Grog
My website: qwazix.com
My job: oob
 

The Following 2 Users Say Thank You to qwazix For This Useful Post:
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#25
If it's that simple, can we just release it as part of the kcssu/kp release process?
 

The Following 2 Users Say Thank You to Android_808 For This Useful Post:
joerg_rw's Avatar
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#26
Originally Posted by qwazix View Post
Choice is king but this argument can work the same until we ship empty phones and leave everybody create their distro from scratch.[...]
Not all their users have the time or even think about to break the metapackage and test alternatives to see for themselves that they are better. Let's use our collective wisdom to provide them with a better product. It's not depriving them of choice, they can always revert.
Sorry, you either missed some important detail or you lost me on your argumentation chain. I always stated that freedom of choice is an indispensable property of FOSS and particularly CSSU, and that the CSSU team is not really happy with replacing the forced-by-Nokia selection by any other forced-by-whomever selection.
Metapackage (in the form we got it now) is a synonym for NO-CHOICE, since it links a set of apps hard and user has the only choice of "take it or leave it" (I lately opted for the latter for my daily phone).
Breaking up the old metapackage is mandatory and it's not meant to get done by user (my opting for "leave it" above results from me doing such breaking the old metapackage to get stuff I needed, and thus any new update would revert all the breaks to metapackage I have done). Rather it is the developers and CSSU-maintainers who need to get sh*t sorted and replace the old locking-in MP by a CSSU version that allows depending on provided features rather than package names and precise revisions - in short, fix the buggy old MP so users are free to replace CSSU FOSS versions by stock versions(!!) whenever they like - for each single package separately and without messing up their system so badly that it either won't update on next CSSU release or reverts all the choices the user made to customize his system (CSSU -> stock camera/mediaplayer/whatever).
Nobody ever suggested to require users to opt in for every single CSSU package, I'd consider this extremely silly and would strictly vote against it. Rather we should have 2 or even more alternative new fixed MP (or other similar gear) to allow users to choose from a number of reasonable presets (already been suggested before in this thread as "bugfix" and "FOSS" repos - though we won't probably use different repos for that) - again, PRESETS that user is free to modify to his liking in the limits that a working system allows. For example there's no reason why users can't uninstall modest (mail) all together, even when they never need it. This is a BUG in stock maemo, and it needs to get fixed. I think it's a thoroughly broken philosophy to force a new replacement for a stock app onto users and not give them the option to revert or completely uninstall that package - in my book such a new package still has same bug as the old package: it can't get uninstalled. Buggy packages shouldn't get into CSSU.

Please don't try to find arguments why we need to force a certain set of apps onto users, no matter what the particular set.

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

Last edited by joerg_rw; 2013-08-07 at 22:01.
 

The Following 4 Users Say Thank You to joerg_rw For This Useful Post:
joerg_rw's Avatar
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#27
Originally Posted by freemangordon View Post
[...]He/she will have the option to either keep the current setup (sorry, no CSSU for you ) or to fix it in a way to be compatible with CSSU and kcssu.
What is the option for those that already have CSSU with KCSSU-incompatible kernel? Seems their only options are: never again receive CSSU updates (when CSSU depends on a certain kernel), or get rid of whatever they installed. Neither of both options sounds like CSSU maintainers are treating their userbase right.
__________________
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; 2013-08-07 at 22:07.
 

The Following User Says Thank You to joerg_rw For This Useful Post:
joerg_rw's Avatar
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#28
Originally Posted by king Ralphred View Post
I don't even know what FOSS means. However, would it be possible to include a community decided set of programs in cssu? So that when you reflash your n900, you install 1.3 and then cssu and then you phone is set up. A cssu with nitdroid would be good. I installed nitdroid useing the beta 3 installer on my main phone and did exactly the same thing on my second but got guru meditation and reboot loop.
Things I use
OMWeather
Cutetube
OMP
H-E-N
Qcpufreq
Mobile hotspot
Transission
The tramps treasure (for obvious reasons)

Anything that adds functonality to the phone should be included.
This is a rather nice through-ball for me. I suggested several times now to publish tailored-to-fit (stripped) osso-backup files that simply open up a list with apps and all of them are checkmarked for restoring errr installation. User however can uncheckmark every single app and then let HAM take care about the rest in one batch.
THIS sounds like a better alternative to messing around with replacing app-A by app-A' in metapackage


[edit]
Again, in short, on example of alarmclock:

a) remove alarmclock from MP a.1) maybe introduce a dependency to a "PROVIDES: alarmclockfunction" to MP
b) create a wrapper mini-"meta"package "Nokia-alarmclock" that simply "DEPENDS (stock, Nokia) alarmclock", and "PROVIDES: alarmclockfunction" - this is needed since HAM doesn't see the original alarmclock package, it's in group system.
c) create a (real, with binary) package "FOSS-alarmclock" that also "PROVIDES "alarmclockfunction"

Now users can install either of both packages

d) offer a number of osso-backup (the default backup app) backup-files that have different nice selections preset for the user: one of them might be "stock CSSU" and include the "Nokia-alarmclock" package among other similar stock apps' 'meta'packages. Another one maybe "CSSU finest" that has all the FOSS-packages incl "FOSS-alarmclock", "camera-ui2", "OMP", plus "orientation-lock-applet" etc.
User chooses one that most closely meets his preferences, and deselects in checkmark-list the few packages she nevertheless still doesn't want.

Obviously a) is the most important one. And yes, I know there's actually no package alarmclock, but that doesn't matter to make my point.


/j
__________________
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; 2013-08-07 at 23:05.
 

The Following 2 Users Say Thank You to joerg_rw For This Useful Post:
qwazix's Avatar
Moderator | Posts: 2,622 | Thanked: 5,447 times | Joined on Jan 2010
#29
Originally Posted by joerg_rw View Post
Sorry, you either missed some important detail or you lost me on your argumentation chain. I always stated that freedom of choice is an indispensable property of FOSS and particularly CSSU, and that the CSSU team is not really happy with replacing the forced-by-Nokia selection by any other forced-by-whomever selection.
Metapackage (in the form we got it now) is a synonym for NO-CHOICE, since it links a set of apps hard and user has the only choice of "take it or leave it" (I lately opted for the latter for my daily phone).
Breaking up the old metapackage is mandatory and it's not meant to get done by user (my opting for "leave it" above results from me doing such breaking the old metapackage to get stuff I needed, and thus any new update would revert all the breaks to metapackage I have done). Rather it is the developers and CSSU-maintainers who need to get sh*t sorted and replace the old locking-in MP by a CSSU version that allows depending on provided features rather than package names and precise revisions - in short, fix the buggy old MP so users are free to replace CSSU FOSS versions by stock versions(!!) whenever they like - for each single package separately and without messing up their system so badly that it either won't update on next CSSU release or reverts all the choices the user made to customize his system (CSSU -> stock camera/mediaplayer/whatever).
Nobody ever suggested to require users to opt in for every single CSSU package, I'd consider this extremely silly and would strictly vote against it. Rather we should have 2 or even more alternative new fixed MP (or other similar gear) to allow users to choose from a number of reasonable presets (already been suggested before in this thread as "bugfix" and "FOSS" repos - though we won't probably use different repos for that) - again, PRESETS that user is free to modify to his liking in the limits that a working system allows. For example there's no reason why users can't uninstall modest (mail) all together, even when they never need it. This is a BUG in stock maemo, and it needs to get fixed. I think it's a thoroughly broken philosophy to force a new replacement for a stock app onto users and not give them the option to revert or completely uninstall that package - in my book such a new package still has same bug as the old package: it can't get uninstalled. Buggy packages shouldn't get into CSSU.

Please don't try to find arguments why we need to force a certain set of apps onto users, no matter what the particular set.

cheers
jOERG
I don't disagree. I just view the metapackage as a seperate bug, not as a bug in each of the included applications. Now we could argue which has the highest priority, fixing the metapackage or fixing the bugs in included apps (by replacing them with FOSS ones).
__________________
Proud coding competition 2012 winner: ρcam
My other apps: speedcrunch N9 N900 Jolla –– contactlaunch –– timenow

Nemo UX blog: Grog
My website: qwazix.com
My job: oob
 

The Following User Says Thank You to qwazix For This Useful Post:
joerg_rw's Avatar
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#30
Originally Posted by qwazix View Post
I don't disagree. I just view the metapackage as a seperate bug, not as a bug in each of the included applications. Now we could argue which has the highest priority, fixing the metapackage or fixing the bugs in included apps (by replacing them with FOSS ones).
That's rather easily and already answered: ``buggy packages shall not go into CSSU'' - IOW you never ship a package you already know has bugs you could fix. This applies to arbitrary app pkgs as well as for metapackage. And the MP needs to get edited/touched anyway for a new CSSU release, so why would we introduce a new (app) package that maybe fixes some bugs in the binary (or just is better because FOSS while not any other advantages) and we would same time introduce a new bug into CSSU that is "this new package gets forced onto users simply because somebody didn't care to edit MP the right way"?

BTW my explanation above is slightly simplified and thus might have a few flaws, but we discussed all this first time ~18 months ago and over and over again since, and I think merlin1991 knows some more details of how to handle it. There's also a chanlog of a public discussion on a CSSU meeting back when, where we agreed on basically exactly this solution (after thoroughly pondering how to best tackle the whole issue. And verified by review by other maintainers/packaging-experts). There been some fringe issues regarding HAM regarding visibility and or handling conflicts iirc, but those are no blocker in any way, since apt can handle all this and you simply add a "fix the MP" package that has nothing but a postinstall script that calls apt-get install for all the packages that are not (yet) available via HAM. you're no way worse with such package than you are today with broken old MP. But you allow users to do apt-get purge on any of those new packages.
/j
__________________
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; 2013-08-08 at 01:17.
 

The Following 4 Users Say Thank You to joerg_rw For This Useful Post:
Reply


 
Forum Jump


All times are GMT. The time now is 20:48.