Originally Posted by woody14619

Is it fair to silently overclock people's devices without telling them? Is it fair to make changes that affect several peoples devices, telling them you're doing one thing when you're in fact not, but doing another entirely?

I am in fact noting that some of what's being done does work. Enabling SR2 (and SR1) can save lots of battery. Doing so in ways that are known to cause some people's devices to go into reboot loops is not. And not being able to explain what you're doing, and what effect it's having (or claiming effects that are counter to or not related to what you're doing) is also not good.

And no, it's not fair. But then it's not about being fair.

PART4 : FAQS

1-)
Q-) I cannot change max frequency with qcpu or any other gui cpu freq changer!!!!

A-) To change the max cpu frequency you need to edit the max freq at :
/usr/share/kernel-power-settings/overclock with any text editor ex:
Code:

sudo gainroot
apt-get install leafpad
leafpad /usr/share/kernel-power-settings/overclock

and then change the maxfreq to anything you want down than save and quit
IMPORTANT !!! IF YOU HAVE AN UNSTABLE N900
IT'S RECOMMENDED TO DISABLE VDD1 ... CHANGE IT TO 0
IF YOU WANT TO OVERCLOCK MORE THAN 805
AS BATTERYPATCH MAXFREQ IS 805

Originally Posted by woody14619

Nice assumption you're making there. You're assuming that no other package, in any repository, anywhere, is modifying or creating a .bashrc or .profile. (There are a few that do...) You're also assuming the owner didn't make their own changes.

Originally Posted by woody14619

And tell me how, exactly, the backed up ones have speedpatch changes? Oh, right.. because you're not doing it right. You see, the right way to do this is to have a script that *injects* what you need into the files. Then on an uninstall, you can use another script (or sed/awk) to remove those lines.

Originally Posted by woody14619

Instead you copy files into a backup file, without checking to see if they already exist. So if someone re-configures their speedpatch (which you tell them to do if they update the kernel) it copies the speedpatch version over top of their existing backup, causing an issue on restore. It also obliterates their backup in the process. So much for not making permanent changes...

Originally Posted by woody14619

I would say this is funny, but it's not. You're WRONG.

From the script "cpu_normal", part of the deb in the repository (where most will probably get it from):

Code:

if [ "`dbus-send --system --print-reply --dest=com.nokia.csd.Call /com/nokia/csd/call/1 com.nokia.csd.Call.Instance.GetStatus | tail -1 | sed 's/.* //'`" != "0" ]; then
...
kernel-config load overclock-call
else
...
kernel-config load overclock
fi

You're parsing the value here and using overclock-call (7X0-850) when it's not 0. GetStatus returns 0 for not in a call, 1-5 for call ringing, 8 for ongoing call, and >8 while the call is hanging up. The code as it stands right now, is overclocking for the duration of the call, because it's 8 (not 0) for the duration of the call. Don't believe me? Open an xterm, place a call (or answer it) and run that command.

The fact that you don't know that is sad. The fact that your putting other people's devices in danger because you're severely overclocking them for the duration of a call when you think it's not... that's worse.

**** ------------------------------------------------------------- ****



I'm sure they do, since you're severely overclocking the device. This also explains why some people get random reboots when people try to call them with your patches installed. Their systems can't handle SR1 enabled at 720Mhz, and you're running it at that every time the phone is about to ring!

Originally Posted by woody14619

Yes, but you leave it enabled in KP 43-44-45-49, and all <K42, where it is still unstable! Try reading what I write...

Originally Posted by woody14619

Again... This isn't about you and just your device. This is something going on to several people's devices. It's fine to say "it may not work on your device", just like the KP overclock stuff says. But you're not saying that. You're saying this is safe for all devices, when what you're doing has historically been proven to not be stable on all devices.

Originally Posted by woody14619

WHERE ARE YOU TELLING PEOPLE YOU ARE OVERCLOCKING THEIR DEVICES?[/SIZE][/B]

IMPORTANT !!! IF YOU HAVE AN UNSTABLE N900
IT'S RECOMMENDED TO DISABLE VDD1 ... CHANGE IT TO 0
IF YOU WANT TO OVERCLOCK MORE THAN 805
AS BATTERYPATCH MAXFREQ IS 805

Originally Posted by woody14619

Except for the things you already mentioned, like it changing the default kernel config

Originally Posted by woody14619

.... Oh... And overclocking your device without telling you.

Originally Posted by woody14619

And on speed patch: removing any .profile and .bashrc file the user or any other app may have created, and not restoring those at uninstall, and overwriting their backups on a reconfig...

Originally Posted by woody14619

I call those permanent changes. I also call overclocking the device for the duration of every call to (750-850), and the heat/wear/damage that can potentially cause, a permanent change. One that I'll note one last time, you NEVER warn the user about, anywhere.

Originally Posted by karam

omg man !! did you bothered your self checking the first post before posting some b*llshit ?

Originally Posted by karam

eh you think am assuming this ?

Originally Posted by karam

well i will explain *harder*

Originally Posted by karam

so when uninstall (if i configured prerm to restore the backed up)
it will cause xterm message to appear !

Originally Posted by karam

noob users will have no problem with it
power users will deal with their backed up .profile and .bashrc well

Originally Posted by karam

why don't you ssh your phone and see your self what happens

Originally Posted by karam

really !! ? well is their any official KP version that is >42
the one in extras is 42 the one in devel is 49 !! + i have never heard of KP v43 !

Originally Posted by karam

here [is where I'm telling people the deb in the repository overclocks]

+ any one with a been brain sized can understand that overclock profile OVERCLOCKS HIS DEVICE

Originally Posted by karam

already mentioned (backed up are *.bak) + no restore on uninstall because
power users know how to when need to and noob users will have no problems with it

Originally Posted by karam

i call this miss *noticing from you* from 1st post and ssh your phone to check the call OC

Originally Posted by karam

i'll note one last time that i have warn the users about many times + 1st post proves in FAQS section

Originally Posted by karam

PS: waiting you to pick up something new about speedpatch and batterypatch

Originally Posted by karam

PS2: what happened with those tests seker_94?

Originally Posted by woody14619

You mean the one that you edit almost daily? Yes... I did. You note there that you load a profile called overclock about 3-pages down in the first post. But it's not highlighted, just in plane simple text, and most people won't read that far simply because of all the technical crap and jargon you have before it.

Line one of that top post should read, in clear bright bold letters "BatteryPatch uses kernel Overclocking, and overclocks your device." The same warning should be in the description of the package.

We're not talking about the potential to overclock (like KP, which has such warnings), or that you can change settings to enable overclock, like other apps that overclock (which all have said warning). There's no clear and concise notice that you're overclocking their device (as witnessed by at least one person posting that it was not obvious to them.)

There's also no notice at all that you're enabling a very unstable, still in testing setting (SR1), that may cause system instability. There's also no indicator that you're overclocking with min frequency set >700Mhz, which is beyond bogus, even for a short time, yet alone a full call.



I do... Your deb package replaces existing files, after renaming the originals as a "backup". If another package sets a variable in .profile (like say SET MAADE_ENV=N900), your postinst moves that to a backup file and replaces the .profile with your settings. Now any package that put stuff into the .profile the right way will cease to function. And if they uninstall speedpatch, it doesn't restore the backup, leaving that application still broken! THAT'S A PERMANENT SYSTEM CHANGE, why can't you understand that simple fact?



It's not *harder* that you need to explain it. The way you're doing this is simply wrong. Period. When dealing with shared resource files (like .profile) you can't just replace them with your content. You must inject the content, and remove it when you're done. Look at deb files from any other debian-based distro system and you'll see them doing that.



YES! Because you're doing it WRONG! I told you why you were getting that message. In fact, I can show you exactly how to reproduce that message:

• Edit your .profile and add a simple line: SET FOO=1
• Now run the package reconfigure command. The .profile with SET FOO is moved to .profile.speedpatch and your package profile is put into .profile.
• Now run that reconfigure again. SET FOO is now completely GONE. And if you were to restore during uninstall, you'd get a copy of your package's .profile, which is what's generating the error you were seeing!

The solution here is not to just not restore the files. The solution is to FIX YOUR DAMN STUPID INSTALLER SCRIPT so that you don't over-write an existing backup file! Minimally, all you would have to do is this:

Code:

if [ ! -e /home/user/.profile.speedpatch.bak ]; then
mv /home/user/.profile /home/user/.profile.speedpatch.bak 
fi

See those two red lines? That's all you have to add to accomplish the ability to restore the original file. If a backup pre-exists on the users system, don't overwrite it. Basic scripting rules. Done... two lines, but that's apparently too hard for you to figure out?

The correct way to do this, is to inject your script block into the .profile in postinst, like this:

Code:

echo "#Next X lines are from SPEEDPATCH" >> /home/user/.profile
echo "echo $$ >/dev/cgroup/.....  " >> /home/user/.profile
...

Then in your prerm, you can use sed to find your tag (SPEEDPATCH) and remove that line and the X below it from .profile. Done. It's that freaking simple. You could even use grep to remove them, since they all contain the word speedpatch! Like this:

Code:

cp /home/user/.profile /home/user/.profile.sp.uninst
grep -v -i speedpatch </home/user/.profile.sp.un >/home/user/.profile

Is that so complex? Clearly too much you to understand and fix, I mean this is tough scripting code... not nearly as easy as scripting an entire system to add in cgroups, right? Instead, you'd rather break other people's installs by replacing the .profile with your own stuff, to hell with anyone else.



Because noob users will totally know if any package they've already installed has a .profile change? Nope. And they will have a problem with it, because YOUR PACKAGE DOESN'T RESTORE THE BACKUP FILES ON UNINSTALL!

Want to see an example of a noob who's system broke because of your speedpatch? There's lots of them in threads you've already read. Trish02 for example.



I DID... You know what?
IT WAS OVER CLOCKED THE WHOLE CALL!

Maybe you should take your own advice? Underclock profile is not loaded during the call. It's loaded after the call finishes, after the user has hung up. The whole time the call is going on, it has the overclock-call profile loaded.

You may have some special version on your device that doesn't. But the one in the repository overclocks for the duration of the call. I quoted the very line of script that showed you exactly where the error was. Did you think I didn't ssh into my device to get that? Where did you think it came from?



There are KP versions from the 30s on up, which have all been in the repository at some point. Just because they're not in the repository as the default item today doesn't mean they never existed. There are lots of people out there running PR1.1 still! Did it not occur to you that someone may still be running KP38, or KP41, or KP43? Did you think they just randomly skipped release numbers?

If you rely on a specific version of a package, you should be putting that in the dependency settings for your package. It's quite easy to do! You just specify you require KP49 or better, and viola, it will either install the newer version, or refuse to install your package because it can't get the latest KP.

The repeating point here is you're doing things wrong. The proper way to do this is to assume they have a system/kernel that is older and can't handle SR1. Then test for the version by number and copy the SR1 enabled file into place only when you have determined it can be used by the kernel on the system. You're doing the opposite, which will cause *lots* of people's systems to break when they install your package. All because you couldn't be bothered to properly, logically think about this and do it the right way.



You're assuming a lot. You're assuming someone is coming to this thread, and reading the entire first post. First off, lots of people just install things from the repository based on the description of the package. Nowhere in the description do you say you're overclocking. And then, even if they find this thread, most people won't read that enormous first post! After the first page of speedpatch technical lies (btw, you still never addressed how you lie about making 3 cgroups when you really only make 1!), most will go "yeah yeah! it tweaks things.. next page". They won't make it to the battery patch section, where you mention you load an overclock profile way down in the mumbo-jumbo techincal details. And even there, you're never telling people how drastically you're overclocking!



Yes... you did entirely miss my point about how you're doing it in the completely wrong way. And that the error you get on uninstall was caused by your lack of doing backups correctly. That the warning you were getting was caused entirely by your inability to think logically or write two lines of script to check to see if you already did that step.



Take your own advice.



And I'll note again: Most people don't read FAQ or posts. There are third party site (like mymaemo.com) that link to the repositories here, and offer NO details about where to find this forum, or your FAQ, or this thread! People installing from there rely on the package description to tell them information.



What? That you rolled a new version, and didn't put it into the repository? That's wonderful... Frankly I'm not inclined to got get it and dissect it again. Why bother? So I can point out more errors in your scripts? It's all pretty much crap. Why would I want to do this whole thing over, when the clear point has already been made:

You have no idea what you're doing, and you lack even the basic scripting talent to make a proper install/uninstall package for a set of shell scripts. If you can't even get the install scripts right (which are only like 4 or 5 lines of script), what confidence should I have that all the other scripts you wrote for these packages are any better? Or that I should let you make new scripts every other day to run on my device, breaking it in random ways? No, thanks...



That's great. Tell me, can you explain why any of that happened? You clearly don't even know what you're doing, since you claim to have made 3 separate cgroups, when the script you posted only creates 1!

Be sure to document which of the 500 versions of speedpatch you released that he tested. And also note that you still leave permanent system changes when you install and uninstall.

Again: I never said these patches do nothing. I said they made permanent changes than an uninstall didn't undo, which is true. I also said they don't do anything that would seem cause anything but shell scripts to speed up. And since you've yet to even being to explain how or why the single additional cgroup (not groups, group, you make 1, not 3) do anything at all, there's little to talk about on that topic.

Originally Posted by mohd012z

i think beter u disscuss with karam & Muhammad AG to rectify all the script.

just my 2 cent

Originally Posted by karam

damit woody i'm so bored from you
i said many times why not restoring *.bak

Originally Posted by karam

also when you say i didn't mention
i show you that i mention
then you say most people don't read

Originally Posted by karam

and as wetnesses

Originally Posted by karam

keep telling people this b*llshit
but speedpatch and batterypatch will stay at the repository

Originally Posted by karam

damit woody i'm so bored from you
i said many times why not restoring *.bak
also when you say i didn't mention
i show you that i mention
then you say most people don't read

WTF

and as wetnesses
see seker_94's post
and Mohammed Muid' post

and you you know what !!? keep telling people this b*llshit
but speedpatch and batterypatch will stay at the repository