You've never heard of private domain registrations?! That's what it is, there's nothing "publicly available", and nothing is "fake". Google is your friend.
You seem thoroughly confused about how copyright works. If it's derivative "enough", it means the owner of the rights of the work that is being derived from must give you permission to derive. It's doesn't take much for something to be a derivative work. I don't see how their use would be considered fair use.
Hint: Pepsico and Coca-Cola spend big bucks to ensure their trademarks are in current registration all over the world. I don't see SBB Corporation wasting money on protecting a silly clock design all over the world. It's not cheap to do so. IOW: It's a local matter, trivial to fix with a software update. Perhaps a court would slap Apple with a fine, big deal. Nothing to see here.
Whatever is in dispute, you have to choose if it's trademark or copyright, you can't have it both ways in the same jurisdiction. As far as the trademark goes, it's probably a Swiss-only trademark, not a European one (someone feel free to check), so whatever, Apple can disable that icon in Switzerland or wherever the heck the trademark is registered. Easy - peasy.
As for copyright: that design might or might not fall under copyright protection in the U.S. It'd probably be a good test case for the courts.
signum norma - Pars subsidium Signum imagine determinatae de schematis m. standard field - A field that is a part of a resource representation, as determined by the schema of the resource.
Disclaimer: I demonstrably have no clue about Latin, I have pieced it together from google translations. It actually sounds better in broken Latin. Perhaps their documentation is translated from Latin?!
It's kinda hard to fit much in the way of filters for 900MHz in a box that size. I'd have probably done a more controlled design where the incoming band (entire thing) is downconverted, filtered, upconverted and then amplified. The main problem with not-very-selective linear amps is that they can't but make the specs of the original transmitter worse. If the 6W transmitter already is close to hitting leakage limits, then the amp can't help with that without processing the signal, and that can't be done at 6W power level unless you have a couple rack units of height to work with. Anything walkman sized 50W must be the entire transmitter if you want to actually have any control over what it puts on the air, so if it's fed from another transmitter it can't reuse the signal as-is.
Heck, if that band had fixed channel allocation (I don't know if it does), then I'd have gone as far as digitally isolating individual transmitted channel in the downconverted IF (cutting the leakage) -- using an A/D and a DSP on the downconverted transmitter output. On the DAC you side you can then use all the harmonic upconversion harmonic tricks that are available, heck, you can even sample your own transmitted signal and apply linearizations in the transfer function to limit further improve the quality of signal that's put on the air. These days all that can be done for an extra 5W of power consumption for the ADC, DAC and DSP, in more-or-less quite amateur designer circumstances, for multiple channels in parallel. If you have only one tx channel to deal with, it's even simpler. Folks with money for an ASIC could do it with probably 1W.
I have dealt enough with enterprisey bullshit that their whole approach is entirely transparent to me after spending maybe 15 minutes gritting my teeth while reading the site, but it drives me nuts. There's nothing to it, pretty much. What is more important, though, is that the barrier to entry is high. I wasn't the most incompetent developer say 10-15 years ago, yet I'd have never managed to go through their "documentation" and figure out what the heck. They are actively discouraging people from participating. If you want reasonable documentation in a user-modifiable form that's still comprehensible and reasonably organized, look no further than macports. That's just one example. You want something even better, look for paper manuals for a stand-alone database system like dBase from 2 decades ago. You could take a couple pounds of paper and a luggable with you, go to an island resort with not as much as a phone connection, and be productive in a couple of days. The content on slcedu is much less than a full set of manuals for a database or a development system from 2 years ago, yet it's virtually useless without having internet and a lot of other resources at hand -- simply because they didn't feel like doing their fine homework and hiring a professional to write documentation. Just as you wouldn't trust your redneck beer buddy to do open heart surgery, you don't want a java enterprise "developer" to document anything. They always fail, it's beyond their wildest dreams that productive developers outside of the field might not operate out of an abstract facade that can be explained away in an afternoon.
As far as I can tell, the project's infrastructure has been designed by entrenched java goons who couldn't explain what is it that takes them so long at work every day if their life depended on it. They built a nice abstraction layer on top of zero functionality, and they expect that someone will pick this pile of nothing for 2 x $75k and actually make it, like, do something useful. They have a nice and clean architecture for nothing. If anyone were to actually develop a system that does something useful in this area of application, they are just as well off starting from another endpoint.
That's a shit piece of linear amp if it distorts the baseband in and of itself, never mind if it distorts more simply because it got hot. I would really like to see the spectra before-and-after the amp. Is the amp you mention a part of the transmitter?
The SLC developer "documentation" was written by bozos who have absolutely no perspective outside of their enterprise clusterfuck swamp. Here's a representative example:
resource - Under the industry standard representational state transfer (REST) software architecture, this is any meaningful concept around which a user interaction can occur.
So, yeah, I get it, a resource may be, um, an argument. Yeah, a verbal argument. I mean come on, try and argue that it's not a "meaningful concept" around which "user interaction" can occur. I mean I'm a user and I can have verbal arguments, duh. Another one:
standard field - A field that is a part of a resource representation, as determined by the schema of the resource.
Dude, a standard field is a field that's defined in the schema of the resource. That's it. Stop with the wordleaks.
The documentation is from someone who can't say what they fucking mean, someone who should have had their fingers slapped with a wooden ruler in their high school writing classes until they fucking got the message. I don't care that they are enterprise geeks who have to deal with various abominations and progress meetings day in, day out. Learn how to write or shut the fuck up.
Sorry, it's this kind of bullshit contentless drivel that drives me nuts, that equally drove Feynman nuts BTW, and for a good reason. RJF hated elaborate abstract frameworks built up around trivial ideas, used for nothing else but aggrandizing the trivial ideas. It's mental masturbation, it's done by people who don't realize (or pretend so) that there are clever folk out there who see that the king is naked, that all those abstractions are built around a single piece of poo in the loo.
Say it like it is. Use common language where such works. Don't wrap things up in abstractions for the sake of abstractions. Sure, I do understand that an API is an abstraction, but you don't have to use a yet another layer of abstraction when describing stuff for crying out loud! And don't fucking make a concept-explaining document something that's split up in a thousand html pages with a couple paragraphs on each! If I'm new to that stuff, I'll want to print it out, spread it out, and work with it. How the fuck do you work with a thousand html files? Do they think they are so fucking important that anyone who wants to touch their heavenly documentation is supposed to write fucking scripts just to collate their driver into a useful form? The only thing missing in their docs is ads. It's make it just as useless as, say, eHow.
It seems like the projects aren't particularly complex, but the barrier to entry is high because documentation sucks and unless you have first hand knowledge with enterprise mental masturbation, you'll spend tons of time figuring out the trivialities that could be spelled out in a 5 page pdf (vs. their idiotic bazillion page HTML thing only available in pieces that pretty much only lack ads to make a complete serving of typical internet barf).
Never mind that their dev website is a typical contentless bullshit "socially driven" page where you can't figure what the fuck the whole thing is about. I mean, they have a freaking twitter feed there. Who the heck needs a twitter feed and pics from, apparently, Times Square, on a dev page is beyond me, but hey, when you lack real content you're free to put up junk space fill, of course.
While I don't think that projects run by kids are anything to scoff at just because they are run by kids, indeed there's some degree of immaturity shown in the response page on xbian.org. The response repeatedly shows that the author is wholly ignorant of how copyright laws work. Namely that the installer author is the only one responsible for compliance. Those xbian folk seem to have no clue that if they redistribute, it's on THEM to comply. I think evein I knew that back in the 90s, without otherwise having a clue about copyright law, from nothing more than reading the fine license (GPL) and associated narrative (FAQs, mailing list posts).
I'm not saying what you say I do. Some people have noticed it, some didn't. There's a lot of variability in how good software developers are at noticing stuff that's not really taught or common industry practice or whatever. Heck, most desktop software people probably never learned the IEC 61131 programming languages used in PLCs, and even those have some nice concepts that make it easier to produce reliable software that reacts to events. Most desktop software people probably never learned about functional safety aspects of programmable electronic devices, subject of IEC 61508, even though said standard lays out the engineering in 'software engineering' (as opposed to hacking stuff together). And so on I could go.
They do, and to get an idea for how much energy they do generate (assuming most of it goes to heat), see how much hotter your intestines are compared to, say, your liver:) Energy doesn't magically disappear, and it usually ends up in the form of heat. Those bacteria sure do utilize energy, but it's a minuscule amount and has no real effect on your calorie budget.
The "solution" is not very simple. Your assumption that just because I notice something I need to be the one implementing it is just, um, silly. You need a paradigm shift in both programming language design and OS design. That doesn't mean that there isn't a problem. Your shout is a rather typical fallacy.
Why you think so? Any process plant is designed for a certain rate of catastrophic failures. No matter what technical means are used (passive vs. active safety, etc), it's engineered for that rate and no more. That means that no matter what devices are in use, it's not designed to be any more or less likely to cause a catastrophic event. If the failure rates used in probabilistic calculations in design diverge from real values, then you have an issue with your engineering process and passive safety is unlikely to help you fix that. Fukushima's design was a classic case of garbage in, garbage out. Nobody would have bothered with passive safety because there was no need for it. Had they identified the need, they'd have had passive safety as an option, but that's just one way to dealing with the effects of a tsunami, they might have simply put the damn backup generators and their fuel supply somewhere safe and that'd be the end of it -- with teh wicked active safety harr.
I can't but LOL when people seriously think no engineer has ever thought of that.
Safety engineering standards (like IEC 61508) define a concept of demand placed on a safety function. Typically it's broken down as low demand -- that's once a year or less frequent, high demand -- more frequent than once per year, and continuous demand. The lower the demand, the stringent the requirements for proof testing. Continuous demand systems have it relatively easy: they must monitor performance while on-line, and that's it.
TMI is an old design that should be been shut down a long time ago and replaced. That would cost a lot of money though so instead the license just keeps getting extended.
What the fuck? You can't demand that it be cheap n' easy and then change rules of the game to make it not so by demanding they are shut down on your schedule. The plants were designed to operate as long as everything holds up, there were certain aspects of their designs that were at the time unknowns, mostly related to how various materials will hold up over time in given environment simply because there wasn't 100+ years worth of engineering experience with nuclear power plants like there was with pressurized steam aspect of things. There's nothing bad about this design simply because it's old. In fact, if anything, its shortcomings, if any, are much better understood after it has been long time in operation, so certain unknown probabilistic factors that are used in doing failure mode and risk analysis have tighter bands on them, leading to streamlined inspection and refurbishment.
The plants will operate as long as it's economical to do so. There's no reason whatsoever to do otherwise.
That's only by your own imagination. Yes, it'd be "last resort before rupture" iff it was a dump done by pressure relief valve that protects a vessel or piping from mechanical over-stress. Basically, by your own admittance, you're limited to thinking about a household hot water tank. That wasn't the system in question now, was it, AC?
Here, it was a vent used to remove heat from the system. Nothing would blow up just because they woudn't dump that steam. Things would overheat and get perhaps damaged or would require costly reinspection and requalification, but there wouldn't be any explosions, not right away anyway. Protip: if you've got a source of cold water to inject into a loop to be cooled down, you eventually have to do something with the steam that accumulates in such a loop. If there's no heat exchanger capacity to recondense the steam, you vent it. That's all there's to it. Sigh.
It is entirely a figment of your imagination that fail safe implies passive safety where things don't "have to happen" for the failure to be safe. It's fucking meant to SCRAM, to have emergency cooling, and to be carefully managed. It's by design, and it works. I don't understand what is this magical bond people have with passive safety. You can design for passive safety, but it's not going to be any better than active safety because, again, you engineer it for a certain rate of catastrophic failures no matter what technical solutions you employ. The rate of catastrophic failures is given by regulatory and internal project requirements and you design for that, end of story.
A door that you mention was only fail safe when it came to a certain failure mode of the electromagnet or its control circuits (loss of power, severing of wires, short circuit in the wires). Had the control circuit stay inadvertently energized in case of a fire, it wouldn't fail safe. Had there been a stuck hinge or a chair in the way, it wouldn't fail safe. You show the typical, arrogant know-it-all approach to safety, with essentially cargo culting certain artifacts without demonstrably having a clue about the engineering process involved in actually designing functional safety into the systems.
Hint: passive safety is a tool available to those who engineer a safe system. In itself it doesn't lead to a system that's inherently any more or less safe. You do a failure mode analysis and do the probabilistic calculations that tell you how robust things need to be in order to keep catastrophic failure rates low enough. If you screw that up (like in Fukushima), passive safety isn't going to save you, because your assumptions were wrong and there will be other aspects of the system which will be likely equally screwed up -- say the spent fuel rod storage.
In Fukushima it wasn't an active mechanism that screwed up. Everything acted exactly, to the letter as designed. The plant wasn't designed to cope with a certain failure mode. The safety engineering of the site wasn't done right. That's all.
Slashdot Mirror
You've never heard of private domain registrations?! That's what it is, there's nothing "publicly available", and nothing is "fake". Google is your friend.
You seem thoroughly confused about how copyright works. If it's derivative "enough", it means the owner of the rights of the work that is being derived from must give you permission to derive. It's doesn't take much for something to be a derivative work. I don't see how their use would be considered fair use.
Hint: Pepsico and Coca-Cola spend big bucks to ensure their trademarks are in current registration all over the world. I don't see SBB Corporation wasting money on protecting a silly clock design all over the world. It's not cheap to do so. IOW: It's a local matter, trivial to fix with a software update. Perhaps a court would slap Apple with a fine, big deal. Nothing to see here.
Whatever is in dispute, you have to choose if it's trademark or copyright, you can't have it both ways in the same jurisdiction. As far as the trademark goes, it's probably a Swiss-only trademark, not a European one (someone feel free to check), so whatever, Apple can disable that icon in Switzerland or wherever the heck the trademark is registered. Easy - peasy.
As for copyright: that design might or might not fall under copyright protection in the U.S. It'd probably be a good test case for the courts.
It's not legal in many places even in Europe. You can't legally fly that way in Czech Republic IIRC.
Switzerland: the country where doing this is legal, now gets a pirate party major. When kids go to college, I'm moving there ;)
signum norma - Pars subsidium Signum imagine determinatae de schematis m.
standard field - A field that is a part of a resource representation, as determined by the schema of the resource.
Disclaimer: I demonstrably have no clue about Latin, I have pieced it together from google translations. It actually sounds better in broken Latin. Perhaps their documentation is translated from Latin?!
It's kinda hard to fit much in the way of filters for 900MHz in a box that size. I'd have probably done a more controlled design where the incoming band (entire thing) is downconverted, filtered, upconverted and then amplified. The main problem with not-very-selective linear amps is that they can't but make the specs of the original transmitter worse. If the 6W transmitter already is close to hitting leakage limits, then the amp can't help with that without processing the signal, and that can't be done at 6W power level unless you have a couple rack units of height to work with. Anything walkman sized 50W must be the entire transmitter if you want to actually have any control over what it puts on the air, so if it's fed from another transmitter it can't reuse the signal as-is.
Heck, if that band had fixed channel allocation (I don't know if it does), then I'd have gone as far as digitally isolating individual transmitted channel in the downconverted IF (cutting the leakage) -- using an A/D and a DSP on the downconverted transmitter output. On the DAC you side you can then use all the harmonic upconversion harmonic tricks that are available, heck, you can even sample your own transmitted signal and apply linearizations in the transfer function to limit further improve the quality of signal that's put on the air. These days all that can be done for an extra 5W of power consumption for the ADC, DAC and DSP, in more-or-less quite amateur designer circumstances, for multiple channels in parallel. If you have only one tx channel to deal with, it's even simpler. Folks with money for an ASIC could do it with probably 1W.
s/2 years ago/20 years ago/.
s/RJF/RPF/ Sorry Dick :(
I have dealt enough with enterprisey bullshit that their whole approach is entirely transparent to me after spending maybe 15 minutes gritting my teeth while reading the site, but it drives me nuts. There's nothing to it, pretty much. What is more important, though, is that the barrier to entry is high. I wasn't the most incompetent developer say 10-15 years ago, yet I'd have never managed to go through their "documentation" and figure out what the heck. They are actively discouraging people from participating. If you want reasonable documentation in a user-modifiable form that's still comprehensible and reasonably organized, look no further than macports. That's just one example. You want something even better, look for paper manuals for a stand-alone database system like dBase from 2 decades ago. You could take a couple pounds of paper and a luggable with you, go to an island resort with not as much as a phone connection, and be productive in a couple of days. The content on slcedu is much less than a full set of manuals for a database or a development system from 2 years ago, yet it's virtually useless without having internet and a lot of other resources at hand -- simply because they didn't feel like doing their fine homework and hiring a professional to write documentation. Just as you wouldn't trust your redneck beer buddy to do open heart surgery, you don't want a java enterprise "developer" to document anything. They always fail, it's beyond their wildest dreams that productive developers outside of the field might not operate out of an abstract facade that can be explained away in an afternoon.
As far as I can tell, the project's infrastructure has been designed by entrenched java goons who couldn't explain what is it that takes them so long at work every day if their life depended on it. They built a nice abstraction layer on top of zero functionality, and they expect that someone will pick this pile of nothing for 2 x $75k and actually make it, like, do something useful. They have a nice and clean architecture for nothing. If anyone were to actually develop a system that does something useful in this area of application, they are just as well off starting from another endpoint.
Your meter is broken or you're lying through your teeth. Seriously.
That's a shit piece of linear amp if it distorts the baseband in and of itself, never mind if it distorts more simply because it got hot. I would really like to see the spectra before-and-after the amp. Is the amp you mention a part of the transmitter?
The below is a rant. You've been warned.
The SLC developer "documentation" was written by bozos who have absolutely no perspective outside of their enterprise clusterfuck swamp. Here's a representative example:
resource - Under the industry standard representational state transfer (REST) software architecture, this is any meaningful concept around which a user interaction can occur.
So, yeah, I get it, a resource may be, um, an argument. Yeah, a verbal argument. I mean come on, try and argue that it's not a "meaningful concept" around which "user interaction" can occur. I mean I'm a user and I can have verbal arguments, duh. Another one:
standard field - A field that is a part of a resource representation, as determined by the schema of the resource.
Dude, a standard field is a field that's defined in the schema of the resource. That's it. Stop with the wordleaks.
The documentation is from someone who can't say what they fucking mean, someone who should have had their fingers slapped with a wooden ruler in their high school writing classes until they fucking got the message. I don't care that they are enterprise geeks who have to deal with various abominations and progress meetings day in, day out. Learn how to write or shut the fuck up.
Sorry, it's this kind of bullshit contentless drivel that drives me nuts, that equally drove Feynman nuts BTW, and for a good reason. RJF hated elaborate abstract frameworks built up around trivial ideas, used for nothing else but aggrandizing the trivial ideas. It's mental masturbation, it's done by people who don't realize (or pretend so) that there are clever folk out there who see that the king is naked, that all those abstractions are built around a single piece of poo in the loo.
Say it like it is. Use common language where such works. Don't wrap things up in abstractions for the sake of abstractions. Sure, I do understand that an API is an abstraction, but you don't have to use a yet another layer of abstraction when describing stuff for crying out loud! And don't fucking make a concept-explaining document something that's split up in a thousand html pages with a couple paragraphs on each! If I'm new to that stuff, I'll want to print it out, spread it out, and work with it. How the fuck do you work with a thousand html files? Do they think they are so fucking important that anyone who wants to touch their heavenly documentation is supposed to write fucking scripts just to collate their driver into a useful form? The only thing missing in their docs is ads. It's make it just as useless as, say, eHow.
It seems like the projects aren't particularly complex, but the barrier to entry is high because documentation sucks and unless you have first hand knowledge with enterprise mental masturbation, you'll spend tons of time figuring out the trivialities that could be spelled out in a 5 page pdf (vs. their idiotic bazillion page HTML thing only available in pieces that pretty much only lack ads to make a complete serving of typical internet barf).
Never mind that their dev website is a typical contentless bullshit "socially driven" page where you can't figure what the fuck the whole thing is about. I mean, they have a freaking twitter feed there. Who the heck needs a twitter feed and pics from, apparently, Times Square, on a dev page is beyond me, but hey, when you lack real content you're free to put up junk space fill, of course.
Well, that's exactly what it says, if you remove the uncalled for verbosity. It reads like something someone in early grade school would write...
While I don't think that projects run by kids are anything to scoff at just because they are run by kids, indeed there's some degree of immaturity shown in the response page on xbian.org. The response repeatedly shows that the author is wholly ignorant of how copyright laws work. Namely that the installer author is the only one responsible for compliance. Those xbian folk seem to have no clue that if they redistribute, it's on THEM to comply. I think evein I knew that back in the 90s, without otherwise having a clue about copyright law, from nothing more than reading the fine license (GPL) and associated narrative (FAQs, mailing list posts).
I'm not saying what you say I do. Some people have noticed it, some didn't. There's a lot of variability in how good software developers are at noticing stuff that's not really taught or common industry practice or whatever. Heck, most desktop software people probably never learned the IEC 61131 programming languages used in PLCs, and even those have some nice concepts that make it easier to produce reliable software that reacts to events. Most desktop software people probably never learned about functional safety aspects of programmable electronic devices, subject of IEC 61508, even though said standard lays out the engineering in 'software engineering' (as opposed to hacking stuff together). And so on I could go.
They do, and to get an idea for how much energy they do generate (assuming most of it goes to heat), see how much hotter your intestines are compared to, say, your liver :) Energy doesn't magically disappear, and it usually ends up in the form of heat. Those bacteria sure do utilize energy, but it's a minuscule amount and has no real effect on your calorie budget.
The "solution" is not very simple. Your assumption that just because I notice something I need to be the one implementing it is just, um, silly. You need a paradigm shift in both programming language design and OS design. That doesn't mean that there isn't a problem. Your shout is a rather typical fallacy.
Why you think so? Any process plant is designed for a certain rate of catastrophic failures. No matter what technical means are used (passive vs. active safety, etc), it's engineered for that rate and no more. That means that no matter what devices are in use, it's not designed to be any more or less likely to cause a catastrophic event. If the failure rates used in probabilistic calculations in design diverge from real values, then you have an issue with your engineering process and passive safety is unlikely to help you fix that. Fukushima's design was a classic case of garbage in, garbage out. Nobody would have bothered with passive safety because there was no need for it. Had they identified the need, they'd have had passive safety as an option, but that's just one way to dealing with the effects of a tsunami, they might have simply put the damn backup generators and their fuel supply somewhere safe and that'd be the end of it -- with teh wicked active safety harr.
I can't but LOL when people seriously think no engineer has ever thought of that.
Safety engineering standards (like IEC 61508) define a concept of demand placed on a safety function. Typically it's broken down as low demand -- that's once a year or less frequent, high demand -- more frequent than once per year, and continuous demand. The lower the demand, the stringent the requirements for proof testing. Continuous demand systems have it relatively easy: they must monitor performance while on-line, and that's it.
TMI is an old design that should be been shut down a long time ago and replaced. That would cost a lot of money though so instead the license just keeps getting extended.
What the fuck? You can't demand that it be cheap n' easy and then change rules of the game to make it not so by demanding they are shut down on your schedule. The plants were designed to operate as long as everything holds up, there were certain aspects of their designs that were at the time unknowns, mostly related to how various materials will hold up over time in given environment simply because there wasn't 100+ years worth of engineering experience with nuclear power plants like there was with pressurized steam aspect of things. There's nothing bad about this design simply because it's old. In fact, if anything, its shortcomings, if any, are much better understood after it has been long time in operation, so certain unknown probabilistic factors that are used in doing failure mode and risk analysis have tighter bands on them, leading to streamlined inspection and refurbishment.
The plants will operate as long as it's economical to do so. There's no reason whatsoever to do otherwise.
That's only by your own imagination. Yes, it'd be "last resort before rupture" iff it was a dump done by pressure relief valve that protects a vessel or piping from mechanical over-stress. Basically, by your own admittance, you're limited to thinking about a household hot water tank. That wasn't the system in question now, was it, AC?
Here, it was a vent used to remove heat from the system. Nothing would blow up just because they woudn't dump that steam. Things would overheat and get perhaps damaged or would require costly reinspection and requalification, but there wouldn't be any explosions, not right away anyway. Protip: if you've got a source of cold water to inject into a loop to be cooled down, you eventually have to do something with the steam that accumulates in such a loop. If there's no heat exchanger capacity to recondense the steam, you vent it. That's all there's to it. Sigh.
It is entirely a figment of your imagination that fail safe implies passive safety where things don't "have to happen" for the failure to be safe. It's fucking meant to SCRAM, to have emergency cooling, and to be carefully managed. It's by design, and it works. I don't understand what is this magical bond people have with passive safety. You can design for passive safety, but it's not going to be any better than active safety because, again, you engineer it for a certain rate of catastrophic failures no matter what technical solutions you employ. The rate of catastrophic failures is given by regulatory and internal project requirements and you design for that, end of story.
A door that you mention was only fail safe when it came to a certain failure mode of the electromagnet or its control circuits (loss of power, severing of wires, short circuit in the wires). Had the control circuit stay inadvertently energized in case of a fire, it wouldn't fail safe. Had there been a stuck hinge or a chair in the way, it wouldn't fail safe. You show the typical, arrogant know-it-all approach to safety, with essentially cargo culting certain artifacts without demonstrably having a clue about the engineering process involved in actually designing functional safety into the systems.
Hint: passive safety is a tool available to those who engineer a safe system. In itself it doesn't lead to a system that's inherently any more or less safe. You do a failure mode analysis and do the probabilistic calculations that tell you how robust things need to be in order to keep catastrophic failure rates low enough. If you screw that up (like in Fukushima), passive safety isn't going to save you, because your assumptions were wrong and there will be other aspects of the system which will be likely equally screwed up -- say the spent fuel rod storage.
In Fukushima it wasn't an active mechanism that screwed up. Everything acted exactly, to the letter as designed. The plant wasn't designed to cope with a certain failure mode. The safety engineering of the site wasn't done right. That's all.