41–50 of 279 posts
Wow, you could actually lose the data with this bug. Glad it was fixed in 12.3. I remember the last time something like this happened (4-5 years ago?) it would only crash the phone.
You only lose data if you’re not backing up your phone - it’s not a corruption bug that breaks the ability to restore backups (like one of the iOS iOS 11 developer betas did).
Earlier quoted context omitted.
Technical terms have meaning defined by actual technical usage regardless of common misuse by the less informed. Your entire tower isn't a cpu, a user recoverable device isn't bricked and if tomorrow most people start calling kidneys livers they will still be kidneys. Reducing bricked to a subjective statement about the users ability to use their device robs the term of all utility in the same way as calling a comput…
"Bricked" isn't a technical term; its basically just slang.
Since a restore works it cannot be called a brick though?
Earlier quoted context omitted.
It's a sliding scale which depends on the user's competence and not just the hardware. To a completely non-technical person, a hard lock-up is "bricked" even if it could be fixed by pressing buttons. To a normal user, a borked ROM is "bricked" even if it could be fixed by plugging into a computer and re-flashing. To a power user, a busted bootloader is "bricked" if it stops them flashing a ROM, even if it could be fi…
This is a good way to describe the reality of "bricked", and I think you could extend this to consider price, too. Even to the EE, the cost of parts and time to repair may exceed the cost of replacement, much like a car in a relatively minor accident can still be considered "totaled" if the repair cost exceeds its value. "Bricked" may still not be the right term, but the difference is irrelevant at that point. Anothe…
Earlier quoted context omitted.
It's a sliding scale which depends on the user's competence and not just the hardware. To a completely non-technical person, a hard lock-up is "bricked" even if it could be fixed by pressing buttons. To a normal user, a borked ROM is "bricked" even if it could be fixed by plugging into a computer and re-flashing. To a power user, a busted bootloader is "bricked" if it stops them flashing a ROM, even if it could be fi…
A device that crashed isn't bricked. We already have a term for that.
Earlier quoted context omitted.
Because it's now fixed. The window is to allow the vendor to issue a fix.
Yeah but maybe it would be nice for users to keep that extra time in order to maximize the probability that they have actually updated software at disclosure time. Disclosing in advance is a bad policy, it will just incentive good behaving vendors that update fast to delay full description of their changelog for security reasons because you put their users at unnecessary risks.
I'll use URL to this bug in my next comment-holywars to prove this point.
Yes, it takes much less code to throw an exception in hope some code will catch it, but while compiler (not runtime) doesn't check it - this technique is not safe. So we should return errors, check them and handle - sometimes it means returning error further, but in some function we'll write code to handle this case without crashing the system (or, at least, it will shutdown everything gently, without panicking).
Earlier quoted context omitted.
It's almost like the author of the above comment (zaroth) didn't read the parent comment. Put another way, bricking is in the eye of the beholder.
Technical terms have meaning defined by actual technical usage regardless of common misuse by the less informed. Your entire tower isn't a cpu, a user recoverable device isn't bricked and if tomorrow most people start calling kidneys livers they will still be kidneys. Reducing bricked to a subjective statement about the users ability to use their device robs the term of all utility in the same way as calling a comput…
See prescriptivist vs descriptivist.
Earlier quoted context omitted.
Because it's now fixed. The window is to allow the vendor to issue a fix.
Yeah but maybe it would be nice for users to keep that extra time in order to maximize the probability that they have actually updated software at disclosure time. Disclosing in advance is a bad policy, it will just incentive good behaving vendors that update fast to delay full description of their changelog for security reasons because you put their users at unnecessary risks.
Like, repeatedly.
goto fail, Facetime surveillance, empty password grants root access, and now this.
As much as Apple touts privacy and security, this is not a great track record.
The more resources a company has, the less forgivable serious bugs like this are.
I need to keep reminding myself: Apple is a hardware company, not a software company.