[HN Gopher] Investigation report on the OVH data centre fire in ...
___________________________________________________________________
Investigation report on the OVH data centre fire in Strasbourg on
2021-03-10
Author : speedgoose
Score : 26 points
Date : 2022-06-08 20:41 UTC (2 hours ago)
(HTM) web link (lafibre.info)
(TXT) w3m dump (lafibre.info)
| nraynaud wrote:
| I can't imagine the phone call to Germany: "Hi, it's the clown
| neighbor again, we are sending you smoke, probably laced with
| lead. Sweet Dreams."
| Kuinox wrote:
| Well that's fair, they send us their coal fumes all the year.
| sofixa wrote:
| It'd be funny if it weren't so tragic. Germany really should
| have shut down coal (i know it's easier said than done and
| there's a significant industry around it, all the more reason
| to start with it and not postpone) before nuclear.
| adamredwoods wrote:
| Interesting read (Google translated).
|
| >> Safety lessons in building design
|
| >> In the field of building design, we will retain two safety
| lessons.
|
| >> First of all, the requirements applicable to battery charging
| rooms, when they are located inside a building, require a
| sufficient degree of fire resistance to prevent its propagation
| to the rest of the building. The existing regulations already
| seem complete to us, and the OHV accident does not call their
| technical relevance into question.
|
| >> However, two configurations, in the current state of the
| regulations, deserve particular attention:
|
| >> - When the batteries used are not likely to generate hydrogen
| during charging (if lead batteries are now mainly used in energy
| storage in data centers, lithium technology offers one more
| alternative more competitive which tends to develop);
|
| >> - Or when these load rooms are located outside.
|
| >> On the first point, the BEA-RI considers that the prescription
| relating to the constructive provisions should also concern the
| other battery technologies for which electrical failure and
| thermal runaway cannot be physically ruled out. This type of
| failure can lead to major fires and justify specific construction
| measures.
|
| >> On the second point (outdoor charging rooms), the BEA-RI
| recalls the recommendations issued in its report MTE-
| BEARI-2021-004 on the battery container fire in Perles and
| Castelet (09)
|
| >> Finally, the report points out that protecting the battery
| room is not sufficient, given the outbreak of fire at the level
| of the inverter:
| speedgoose wrote:
| > Could a water leak on an electronic board of an inverter be the
| cause of the beginning of the disaster?
|
| The report is in French, but you can look at the pictures or use
| an online translator.
|
| https://deepl.com usually provides much more convincing French-
| English translations compared to Google Translate.
| naniwaduni wrote:
| Note that "more convincing" isn't necessarily a _good_ thing;
| the deception of fluency can totally be used to convince you of
| something _wrong_.
| lucb1e wrote:
| I've had good experiences with deepl, but certainly a good
| point. Translating definitely has an interpretation aspect to
| it. I'd be curious if anyone tried tricky texts on different
| translators and how they fared. I'm not enough of a linguist
| myself to know of different categories of tricks (to give a
| fair assessment rather than things randomly coming to mind),
| or what even the jargon for such things would be to look them
| up.
| naniwaduni wrote:
| Well, this went around my circles the other day:
| https://twitter.com/Xythar/status/1405660710382706694
|
| It turns out that the "tricks" don't necessarily have to
| get very sophisticated, because, well, the target user of
| machine translation services can't understand the source
| text.
|
| (I mean, the fr-en language pair is probably better off
| than ja-en, but I don't know enough French to know whether
| it can be trusted!)
| Mordisquitos wrote:
| I'm not sure what to make of this.
| [deleted]
| mananaysiempre wrote:
| As an aside, there seems to have been a dramatic change
| in Google Translate's underlying approach several years
| ago: before it, the fr>en and zh>en pairs were reasonable
| (if stilted and occasionally ungrammatical) while both
| de>en and ja>en absolutely sucked (just made no sense
| whatsoever over groups of more than three or so words); I
| suspect the difficulty being the "global" transformations
| needed to translate SOV to SVO word order. It would be
| very interesting to know what they did (there are old-
| style statistical approaches that involve learning pairs
| of corresponding syntax trees, but I didn't get the
| impression they were practical?).
| lucb1e wrote:
| > in truth it's like 10 times more likely to just make
| complete shit up if it doesn't understand the source
|
| I use this to learn German. Instead of translating a text
| EN->DE and not practicing any writing skills, I'll write
| my best attempt at German and see if it's understandable
| by running it through the DE->EN or DE->NL translator.
| (In cases where I care about the quality, I'll then patch
| up the English/Dutch if necessary, run it NL/EN->DE, and
| use that version.)
|
| For this purpose, I'm glad that it makes a best guess at
| what my broken German must mean, and it usually does a
| fair job (easy to say because I know what I meant, so no
| validation issues there). Of course this is not great for
| every use-case, for example it would be better if it
| additionally displayed confidence (e.g. slightly graying
| out subsentences below 80% confidence), but it also has
| advantages to make a good guess at the meaning of the
| source.
|
| And when I put in something unintelligible,
| unintelligible stuff comes out. It's not _really_ just
| making something up, at least not in my experience with
| EN /DE/NL. No idea what happened there with that Japanese
| example.
___________________________________________________________________
(page generated 2022-06-08 23:00 UTC)