Normally I'd have marked the entire subthread offtopic, but hutzlibu's comment deserves to be at the top, even if it does use the word "bricked" wrong.
"Unbricking" will hopefully work automatically, because there is no other option. But that can also fail and there is no way to know, or influence it.
I use bricking in the definition of mobile phone tinkerers .. there are many results for unbricking btw, but I just checked and with the first result it seems that Apple now uses unbricking for activating a new device. Because technically before, it is also just a brick - but here I would agree, that it is not a appropriate term, but rather should be for somehow broken devices.
The JPL doco (>>36941433 >>36942321 ) calls it "Command Loss".
It may have seemed that way to you, but actually no. "Bricked" has generally referred to devices that are likely straightforwardly recoverable, but for a lack of documentation from the manufacturer.
Precisely. 'Bricking' something means it is unrecoverable and is irreversible.
No idea at what point in time the definition was changed to mean 'temporarily not working'.
In other words it was effectivly a brick to me.
But since it was not a surface pro (I considered buying instead of that one), I could open it and disconnect the battery.
And in effect, unbricking it. Quite trivial fix sure, but nearly impossible with many modern devices, where the battery is glued in.
My point is, not every mode of operation is desired, especially if you cannot change it. Then you might as well have a brick in terms of usefulness.
It was not making its own decisions, to achieve some goal.
What is bricked vs recoverable has always greatly depended on time and effort, individual skill level, available hardware/software tools, documentation, crypto keys, physical access, willingness to replace individual parts etc.
Sometimes, even within an org, some teams e-waste expensive devices that aren't bricked deeper than what other teams recover from as part of everyday workflow.
Taking a typical network device as an example, where do you draw the line? Driving to a remote location to plug the cable into another port, pressing a reset button, booting from USB, flashing a new firmware with TFTP, plugging in an external or internal console cable, opening the case and soldering a header to get access to the console, doing the same with no documentation, or an unknown (but maybe Google-able or reverse engineerable) password, flashing firmware with JTAG, shipping the device back to the engineers (or shipping an engineer to the device)...? It's always been arbitrary.
Also, it's not a technical term with a rigid definition, hence "soft-bricking"
If you are able to fix it then it is not bricked.
One device may be bricked to one person but not to another. But that must still be the definition, right? Otherwise the word has no meaning.
An embedded device with a failed bootloader update is considered “bricked”, even if you can open it up and reflash it with a valid bootloader.
I don’t know why folks are so insistent on gatekeeping the word, as if doing so demonstrates some superior personal knowledge.
I remember when bricking something meant it was totally unrecoverable. Now it means "temporarily not working but will automatically heal".
Most folks don't really know how to use say Android fastboot or recovery modes either, yet we wouldn't call a device with a wiped system partition "bricked".
Most "bricks" are things like a bootloader getting erased. Reflashing that through the standard process of JTAG or another debug protocol is a straightforward action (after all, the manufacturer has to get the first bootloader on there to begin with). The port pinout and config info just hasn't been publicly documented by the manufacturer, which is what pushes it into the domain of "experts".
Then "totally unrecoverable" is rare and the term bricked has always been relative. Your bricked device may be as good as new to someone who has a JTAG adaper and knows how to use it.
I would love to see a picture of your computer pulling itself up by the straps on its physical boots the next time you press reset. Bleeding when a process is "killed".
Even something as superficially similar to real-world behaviour a "queueing" is implmented in a very different way in software, for the most part.
Weird discussion since we're talking about a piece of hardware that is working fine and doing exactly what it was told to do. They just pointed it in the wrong direction and need to wait for it to recover, which it is set up to do.
We wouldn't say a server with the router IP address misconfigured was "bricked." (or maybe we would... I guess the jargon changes, but that would seem pretty crazy to me)