05-30-09 09:59 AM
50 12
tools
  1. jason1332's Avatar
    spaciorek;2680793]No no no you must downgrade to .65 before upgrading


    I heard that if you downgrade before you upgrade you can get flick scrolling.

    Posted from my CrackBerry at wapforums.crackberry.com
    05-29-09 11:02 PM
  2. cyberxen's Avatar
    you are incorrect



    i hope you are being funny and not actually asking any questions....
    Really? Because I compile code with debug symbols quite often, as do many other software engineers.

    Posted from my CrackBerry at wapforums.crackberry.com
    05-29-09 11:04 PM
  3. DeaconBlue's Avatar
    spaciorek;2680793]No no no you must downgrade to .65 before upgrading


    I heard that if you downgrade before you upgrade you can get flick scrolling.

    Posted from my CrackBerry at wapforums.crackberry.com
    You have to create a hybrid with .65/.75/.148 for that. It's the snappiest!
    05-29-09 11:05 PM
  4. suby723's Avatar
    Bud... you can say that till you're blue in the mouth. They just won't get it.
    I was just putting that out there...do i think it will be the same? most likely yes. But just for the argument, if i place 5.0 files into the .148 it still shows os version .148 platform .181.
    05-29-09 11:06 PM
  5. Accidental Post's Avatar
    Capt I am doing well trying to survive until 2012 if you know what I mean

    Posted from my CrackBerry at wapforums.crackberry.com
    05-29-09 11:06 PM
  6. DeaconBlue's Avatar
    Capt I am doing well trying to survive until 2012 if you know what I mean

    Posted from my CrackBerry at wapforums.crackberry.com
    It's the end of the world as we know it...and Party like it's 2011?
    05-29-09 11:07 PM
  7. jason1332's Avatar
    You have to create a hybrid with .65/.75/.148 for that. It's the snappiest!
    Running .75 = driving 1980 ford escort hatchback.

    Posted from my CrackBerry at wapforums.crackberry.com
    05-29-09 11:07 PM
  8. howarmat's Avatar
    I was just putting that out there...do i think it will be the same? most likely yes. But just for the argument, if i place 5.0 files into the .148 it still shows os version .148 platform .181.
    the version you see is controlled by the radio (SFI) file, not the COD files which are the 5.0 files you are using
    05-29-09 11:07 PM
  9. GpCaptMandrake's Avatar
    Capt I am doing well trying to survive until 2012 if you know what I mean

    Posted from my CrackBerry at wapforums.crackberry.com
    ROFL you and me both bud!!!!!!
    05-29-09 11:08 PM
  10. GpCaptMandrake's Avatar
    Running .75 = driving 1980 ford escort hatchback.
    I literally busted out laughing when I read that.

    Thanks! Wine up my nose and all over my keyboard!!
    05-29-09 11:10 PM
  11. jason1332's Avatar
    ROFL you and me both bud!!!!!!
    3rd the motion.

    Posted from my CrackBerry at wapforums.crackberry.com
    05-29-09 11:10 PM
  12. jason1332's Avatar
    I literally busted out laughing when I read that.

    Thanks! Wine up my nose and all over my keyboard!!
    Glad to be of service. Your missing browser statement had me laughing here.

    Posted from my CrackBerry at wapforums.crackberry.com
    05-29-09 11:12 PM
  13. txaggie84's Avatar
    am I better off going with going with the leaked .148 or the official .148. or possibly take the tax credit and get the hybrid??
    05-29-09 11:14 PM
  14. jason1332's Avatar
    am I better off going with going with the leaked .148 or the official .148. or possibly take the tax credit and get the hybrid??
    Give them time and our reps in DC will find a way to tax leaked OS's next. Get while its free.

    Posted from my CrackBerry at wapforums.crackberry.com
    05-29-09 11:17 PM
  15. stillborn86's Avatar
    I had a Verizon rep tell me that the official .148 is coming out on Sunday and that I should definitely get it. When I told him I already had it, he said I should downgrade until Sunday before they shut my phone down.

    I laughed in his face...
    05-29-09 11:18 PM
  16. suby723's Avatar
    the version you see is controlled by the radio (SFI) file, not the COD files which are the 5.0 files you are using

    true true, your right..i dont know where i was going with that haha

    It really wont matter to me at all. My OS is better then the .148 anyways.
    05-29-09 11:19 PM
  17. txaggie84's Avatar
    I had a Verizon rep tell me that the official .148 is coming out on Sunday and that I should definitely get it. When I told him I already had it, he said I should downgrade until Sunday before they shut my phone down.

    I laughed in his face...
    lmao...those meenies....
    05-29-09 11:20 PM
  18. techitrucker's Avatar
    damnit people, they dont make any changes. they make a build, 155 lets say, any other coding changes done to it and it will no longer be 155, it will become a different number.

    THERE IS NO ACTUAL CODING CHANGES AT ALL!!

    That is true but I don't believe that is what the previous poster was saying so here I will translate in English. In the world of programming and beta testing the programmer will send out various build. In those builds during the beta process, often times, but not always there are additional elements added to the build for use in debugging as well as logging findings in the build. They are almost always well hidden and gotten to use commands that are not at all obvious or easily gotten at. Once a build has passed beta testing, these elements, which have nothing to do with the actual operation of the build are stripped and the build is packaged in its final version for release. This is almost universal in the world of programming and extraordinarily common with Java programming since it strips out unnecessary code from releases after testing that can affect performance. Just because a beta is functionally identical to a release does not mean the leaks do not have this additional code since the leaks are beta. Like the previous poster said, the best way to check would be to compare uncompressed file size. Most of the Java debugging and reporting tools would be at least a couple of megabytes so it would be easy to tell. A very small change, say in the 10 of kb's probably would only indicate a larger or smaller vendor file.

    It would be surprising if there are no debugging or reporting tools in the leak by the way, since this is a generally accepted practice for testing beta builds of all software. It actually flys in the face of reason that they would release a beta to testing without any way for the software to send reports, probably in the backround without any user input I may add. Its much more efficient than word of mouth surveys that everyone seems to think is all they use when testing the betas and it could be the reason for the hard to pin down erratic behavior of the betas.

    By the way, since Blackberries run Java in a protected mode for security, debuging and reporting tools cannot be run as a program seperate from the kernel layer to get valid information, so these programs if there would need to be installed with the OS and as part of it to get the kind of root access needed. Adding the programs to the application layer would give them insufficient priveleges to get the kind of data necessary to make proper changes to code in future builds.

    This is all conjecture though since debugging and reporting may happen in the alpha stage and they very well could just use dumb surveying in the beta stage but hopefully this long, long post explains enough about how programming and debugging generally works to keep people from the same ask question or make comment/receive multiple flames cycle we seem to be on here when it comes to this subject on a hundred different boards. The questioners can't know because they aren't writing or testing the software but by the same token, neither can the flamers or experts. All we can do is compare file sizes of the before and after and draw conclusions from that.

    Id like to think we can close this subject now but I give the odds of that as fat chance or below.
    05-30-09 03:28 AM
  19. mattmext's Avatar
    This thread made my day. Thanks!!
    05-30-09 03:32 AM
  20. rip14's Avatar
    OK, to recap for everyone.

    The leaked .148 and offical .148 are the same, except for the following:

    The accelerometer is so much faster on the offical .148 Now the ******* phone will explode when you actually use it. (Source - nyr2k2)

    If you downgrrade to .65 first, you get flick scrolling. (Source - jason1332)

    For the snappiest OS, you must create a hybrid with .65/.75/.148 for that. (Source - DeaconBlue)

    If you still run .75, verizon will buy you a 1980 ford escort hatchback. (Source - jason1332)

    The offical .148 will give you a tax credit, and a brand new hybrid Civic. (Source - txaggie84)

    You must shut your phone down until Sunday to receive the offical .148 (Source - stillborn86 / VZW)

    The leaked version does not include a browser. You must have the offical to have internet abilities. (Source - GpCaptMandrake)

    Only those with the offical .148 will survive the end of the world at 2012 (Source - Nostradamus)
    05-30-09 09:06 AM
  21. gtstang462002's Avatar
    That is true but I don't believe that is what the previous poster was saying so here I will translate in English. In the world of programming and beta testing the programmer will send out various build. In those builds during the beta process, often times, but not always there are additional elements added to the build for use in debugging as well as logging findings in the build. They are almost always well hidden and gotten to use commands that are not at all obvious or easily gotten at. Once a build has passed beta testing, these elements, which have nothing to do with the actual operation of the build are stripped and the build is packaged in its final version for release. This is almost universal in the world of programming and extraordinarily common with Java programming since it strips out unnecessary code from releases after testing that can affect performance. Just because a beta is functionally identical to a release does not mean the leaks do not have this additional code since the leaks are beta. Like the previous poster said, the best way to check would be to compare uncompressed file size. Most of the Java debugging and reporting tools would be at least a couple of megabytes so it would be easy to tell. A very small change, say in the 10 of kb's probably would only indicate a larger or smaller vendor file.

    It would be surprising if there are no debugging or reporting tools in the leak by the way, since this is a generally accepted practice for testing beta builds of all software. It actually flys in the face of reason that they would release a beta to testing without any way for the software to send reports, probably in the backround without any user input I may add. Its much more efficient than word of mouth surveys that everyone seems to think is all they use when testing the betas and it could be the reason for the hard to pin down erratic behavior of the betas.

    By the way, since Blackberries run Java in a protected mode for security, debuging and reporting tools cannot be run as a program seperate from the kernel layer to get valid information, so these programs if there would need to be installed with the OS and as part of it to get the kind of root access needed. Adding the programs to the application layer would give them insufficient priveleges to get the kind of data necessary to make proper changes to code in future builds.

    This is all conjecture though since debugging and reporting may happen in the alpha stage and they very well could just use dumb surveying in the beta stage but hopefully this long, long post explains enough about how programming and debugging generally works to keep people from the same ask question or make comment/receive multiple flames cycle we seem to be on here when it comes to this subject on a hundred different boards. The questioners can't know because they aren't writing or testing the software but by the same token, neither can the flamers or experts. All we can do is compare file sizes of the before and after and draw conclusions from that.

    Id like to think we can close this subject now but I give the odds of that as fat chance or below.
    Let me explain the way RIM does things. They run everything on simulators until they are satisfied. Then they compile the build only to find a bug or 2 show up on the device that didn't show up on the simulator. If it is a minor bug they will send it it to carriers for testing and it is up to the carrier to accept or reject that build. Meanwhile back at the lab they are programming on the previous code to try and figure out where that bug showed up at during the compilation process. When the next build gets run through it's paces on the simulator and given the they go for compilation again. Thus moving from say 4.7.0.147 to 4.7.0.148. Every time there is a build compiled it gets a new number. So that being said .148 is .148 is .148.
    05-30-09 09:41 AM
  22. DeaconBlue's Avatar
    Nice wrap-up!
    05-30-09 09:50 AM
  23. winste's Avatar
    Let me explain the way RIM does things. They run everything on simulators until they are satisfied. Then they compile the build only to find a bug or 2 show up on the device that didn't show up on the simulator. If it is a minor bug they will send it it to carriers for testing and it is up to the carrier to accept or reject that build. Meanwhile back at the lab they are programming on the previous code to try and figure out where that bug showed up at during the compilation process. When the next build gets run through it's paces on the simulator and given the they go for compilation again. Thus moving from say 4.7.0.147 to 4.7.0.148. Every time there is a build compiled it gets a new number. So that being said .148 is .148 is .148.
    So what you are saying is that when RIM releases a build to a carrier, it has gone through any programming changes testing it would. The carrier cannot alter it. If the carrier rejects or needs something changes, RIM changes and gives them a new build thus going from .141 to .148.

    But if VZ accepts and releases .148, it's the same?

    Why has nobody ever explained that?
    05-30-09 09:54 AM
  24. gtstang462002's Avatar
    Nice wrap-up!
    The problem here i believe is everyone relates RIM programming with the way Microsoft programs. If everyone did everything like Microshaft we would never get a secure OS.
    05-30-09 09:56 AM
  25. gtstang462002's Avatar
    So what you are saying is that when RIM releases a build to a carrier, it has gone through any programming changes testing it would. The carrier cannot alter it. If the carrier rejects or needs something changes, RIM changes and gives them a new build thus going from .141 to .148.

    But if VZ accepts and releases .148, it's the same?

    Why has nobody ever explained that?
    Hey your getting it. There is one file that the carrier is allowed to alter and that is the vendor.xml file that tells the device manager what OS the phone is allowed to load.
    05-30-09 09:59 AM
50 12
LINK TO POST COPIED TO CLIPBOARD