Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
aschouela said:
Yes that is exactly what I see. OK so it is not exactly a black screen.

I guess it all depends on what hardware you're running and if you've got an hacks running at startup.

For example, I installed iScroll2 and got that (it was before the update; great product). I removed the offensive files and everything worked fine. Maybe there's some 3rd party programs you installed that loads in the beginning that you might be able to disable (mv <file(s)> ~)
 
coolfactor said:
1) is your computer awake at 3am to perform its nightly maintenance?
-or-
2) or do you manually run maintenance tasks using an app such as OnyX?

Yes and yes - generally I let my iMac sleep until I need it, there's only been a few times it has been turned off for more than a day or so...

Do you need OnyX to do daily/weekly/monthly maintenance? I use "sudo daily..." etc. commands in the terminal when I think it's missed a maintenance activity (I also read somewhere that one of the recent Tiger updates added updating pre-binding to the regular maintenance schedule). Last time I looked at OnyX it seemed pretty much like a GUI for these commands (and a crashy one at that)...

[Edit]: My original question remains - I'm asking whether or not there's been some sort of 32-bit bottleneck on my iMac for the past few days that would be causing extra beachballing and apps in general to open (albeit a tad, but just enough to be noticable) slower.
 
suntzu said:
I guess it all depends on what hardware you're running and if you've got an hacks running at startup.

For example, I installed iScroll2 and got that (it was before the update; great product). I removed the offensive files and everything worked fine. Maybe there's some 3rd party programs you installed that loads in the beginning that you might be able to disable (mv <file(s)> ~)

I have iscroll2 as well. Which were the offending files? :)
 
aschouela said:
Yes that is exactly what I see. OK so it is not exactly a black screen.
That's the TBOD.

Transparent Bezel of Death.

(There's something to be said for an OS where a significant number of users have never even SEEN what a crash looks like :) )
 
nagromme said:
That's the TBOD.

Transparent Bezel of Death.

(There's something to be said for an OS where a significant number of users have never even SEEN what a crash looks like :) )

I completly agree!! It all worked out in the end I just reset the firmware.

Thanks for all your help.
 
Lacero said:
That's like someone punching you in the nose and you thank them for handing you a tissue to soak up the blood. :rolleyes:


Ha Ha Ha. Exactly!


After the first patch (I haven't updated to the new patch) I had sound problems, and keyboard non-responsiveness.

Now how about the fact that it breaks 64-bit code. Proves that nothing is running on 64 bit in the OS. 64 bit = hype.

Using an old powermac 8500 right now on OS 9 and it is pretty fast and everything works. More than I can say for my brand new Dual G5.
 
AidenShaw said:
I'd hate to be the manager of Apple's OSX QA group....

Introducing a bug like this shows a clear lack of proper QA procedures - specifically that there are *NO* 64-bit tests anywhere inside or outside of Apple on the final build.

Perhaps there were no 64-bit tests on any of the builds.

Hole, Truck, Drive Through.... :mad:
You're making a gross assumption about Apple's QA procedures. Where I work, we do separate QA and production builds of our software, and it's entirely possible for something to be working in QA and be broken in production. It's rare, but it does happen. Typically, this sort of thing happens when someone slips in a last-minute fix that makes it into QA but doesn't make it into the files used for the production build, or when someone misconfigures the production build environment.
 
shamino said:
How about the QA people who apparently don't have any 64-bit apps in their regression testing suite?
That's a gross assumption. As I said elsewhere, it's entirely possible this was working in QA and got broken in production. Some companies (like mine) do separate QA and production builds of software, and that leaves room for errors like this.
 
Process is broken?

LionMage said:
That's a gross assumption. As I said elsewhere, it's entirely possible this was working in QA and got broken in production. Some companies (like mine) do separate QA and production builds of software, and that leaves room for errors like this.

Well, either Apple's QA doesn't have 64-bit apps, or their release process is somewhat broken because they can release things that didn't go through QA.

Doing separate builds for QA and production is brain-dead and a waste of time. If you're going to QA a debug build that's different from the release build, well, you might as well have two sets of QA people, one for debug, one for release.

All kinds of things are different when you build a production build. If you're assuming that after you QA a debug build you can just flip a switch, rebuild for production, and ship, well, that's just sort of ridiculous.

You test what you ship.
 
I believe Apple issues this update just to prove me correct. That's why I buy Apple products. They are always looking out for me personally!

I notice that nobody who installed 2005-007 is complaining that installing 2005-007 v1.1 is going to ruin their "uptime", so let me be the first to do so. :)
 
nate13 said:
im personally wondering how many apps this affected, seems like most standard apps wouldnt use 64, so this mustive been a very isolated situation in terms of apps wise. with all the G5s now, im glad they fixed it promptly, and for all you G5 users, did any of you accually notice this?
64-bit application code is not something most people need.

It is needed for apps that require more than 4G of memory (64-bit memory pointers), and it is very useful for apps that do a lot of 64-bit integer arithmetic (scientific applications, simulations, maybe some games.)

Mathematica fits this bill. I can easily see media apps (like Photoshop, Final Cut, Logic, etc) benefitting to various degrees.

For your mainstream apps (mail, web, news, etc.), there is going to be almost no benefit. Which is why mainstream apps are not generally 64-bit, and why you didn't find a lot of users affected by this bug.
 
only broke apps that required 64-bit libSystem

Perhaps reason this was missed was because it only broke applications that *required* the presence of the 64-bit libSystem. The build of Mathematica that broke obviously assumed that it would be there (since it was for Tiger), and required it. Maybe other apps didn't break because they just fell back to the 32-bit version of libSystem.
 
usarioclave said:
Well, either Apple's QA doesn't have 64-bit apps, or their release process is somewhat broken because they can release things that didn't go through QA.

Doing separate builds for QA and production is brain-dead and a waste of time. If you're going to QA a debug build that's different from the release build, well, you might as well have two sets of QA people, one for debug, one for release.

All kinds of things are different when you build a production build. If you're assuming that after you QA a debug build you can just flip a switch, rebuild for production, and ship, well, that's just sort of ridiculous.

You test what you ship.

As it has been suggested elsewhere, it is possible that they simply misconfigured the Software Update server, so that it served the 32 bit version not only to all G4 owners but also to to G5 owners which were supposed to get a slightly different version.
 
Mudbug said:
*goes to write a cron script to check Software Update every 10 seconds*
Ah yes. So Apple can detect your constant queries and classify you as the source of a DoS attack and block your IP altogether.
 
Makes no sense either

manu chao said:
As it has been suggested elsewhere, it is possible that they simply misconfigured the Software Update server, so that it served the 32 bit version not only to all G4 owners but also to to G5 owners which were supposed to get a slightly different version.

The thing is, it's not that simple.

A package has to be created for both QA and software update. If it's possible for SU to get a package that hasn't been through QA, that's a major problem.

It's not like the SU servers (of which there are many) just were pointed at the wrong package. It doesn't work that way. Packages are submitted.

Maybe it was just a way for Apple to see if anyone is building 64-bit apps.
 
LionMage said:
That's a gross assumption. As I said elsewhere, it's entirely possible this was working in QA and got broken in production. Some companies (like mine) do separate QA and production builds of software, and that leaves room for errors like this.
If your QA department doesn't test the builds you ship to customers, but only tests internal pre-release builds, then your procedures are broken.

I wouldn't be proud of having procedures like that.

Any company worth its salt should, in addition to QA testing, have an automated regression testing suite that covers all key parts of the system, and includes specific tests for as many fixed bugs as possible. Every developer should run his code through the suite before submitting it to the CM system, to make sure he doesn't re-introduce any old bugs. And every patch, no matter how minor, should be run against that suite prior to release.

It is clear that either Apple has no such system in place, or that system has no 64-bit application tests in it. Either way, it's a bad thing.
 
shamino said:
Any company worth its salt should, in addition to QA testing, have an automated regression testing suite that covers all key parts of the system, and includes specific tests for as many fixed bugs as possible.


Seeing as how most of our stuff is cheap and comes from China where they get made for $.10, QA would be a godsend! :D
 
Mudbug said:
you can't be serious...

*goes to write a cron script to check Software Update every 10 seconds*

You can't win. Either people complain that macrumors shouldn't post software updates because they're not rumors, or you get people saying you don't post them quickly enough.

I of course never complain about anything ever. :)

Doctor Q said:
I notice that nobody who installed 2005-007 is complaining that installing 2005-007 v1.1 is going to ruin their "uptime", so let me be the first to do so. :)

Good one. That's the best laugh I've had all week. :D
 
Need Help!

Guys, I'm having a huge problem with my system after this update. It has reset all my programs as well as settings on almost every application! What the hell is wrong with my computer! I can't even change my desktop background right now. Can someone tell me how to revert my computer back to the old version before installing this piece of Shhh.
 
nashstradamus said:
Guys, I'm having a huge problem with my system after this update. It has reset all my programs as well as settings on almost every application! What the hell is wrong with my computer! I can't even change my desktop background right now. Can someone tell me how to revert my computer back to the old version before installing this piece of Shhh.

First thing: Go in your hard drive, to /users -- are there "extra" folders in there? That is, you should have one for every account, and a shared folder. Sometimes, people have reported their account sort of being replaced by another one, which doesn't have access to ~/library, and so can't read preferences.

And second: have you repaired permissions and rebooted? ;)

And unrelated: do I understand correctly that the 1.1 version has no impact at all on G4s? So if I don't need the 64 bit version of that lib whatever it was, then I don't have to care? I just hate constantly rebooting. :D
 
mkrishnan said:
First thing: Go in your hard drive, to /users -- are there "extra" folders in there? That is, you should have one for every account, and a shared folder. Sometimes, people have reported their account sort of being replaced by another one, which doesn't have access to ~/library, and so can't read preferences.

And second: have you repaired permissions and rebooted? ;)

And unrelated: do I understand correctly that the 1.1 version has no impact at all on G4s? So if I don't need the 64 bit version of that lib whatever it was, then I don't have to care? I just hate constantly rebooting. :D

It didn't mess with any of the folders at all on my system. It just made every application and anything stored (cookies, web things) reset themselves. I want to preform a system restore to a few days ago. Is that at all possible?

No, I haven't repared the permissions (How do I do that?) but I have rebooted from the update. I'll try again and see what happens.

Thanks for any help.
 
nashstradamus said:
It didn't mess with any of the folders at all on my system. It just made every application and anything stored (cookies, web things) reset themselves. I want to preform a system restore to a few days ago. Is that at all possible?

No, I haven't repared the permissions (How do I do that?) but I have rebooted from the update. I'll try again and see what happens.

Thanks for any help.

Heh... preferences on Macs are stored in a folder called "Library" in your home directory. That's why I was asking.

Now then. Open the applications folder, and then the utilities folder inside it. Run the program "disk utility," and click on the hard drive in the left column, then the repair permissions button. When it's done, reboot. That's a sort of first rule out. Whatever it does, it will not delete or move files. It will just make sure you are able to access what you should be able to access.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.