![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Operation Yellow Ribbon
Jul. 13th, 2014 02:57 amИстория про то как Канадцы принимали самолеты из/в США, после того как FAA "закрыло небо" 9/11.
http://en.wikipedia.org/wiki/Operation_Yellow_Ribbon
Я правда не понял из статьи чья идея была, FAA или канадцев, но сработали хорошо.
"About 500 flights were en route to the U.S. at the time of the attacks. Transport Canada instructed NAV CANADA to give permission for flights that were at least halfway towards their destination to land at the nearest Canadian airport, depending on their point of origin and remaining fuel. Planes were entering Canadian airspace at a rate of one to two planes per minute."
"Gander International Airport, which was the first North American airport on the transatlantic route, took in 39 wide-body aircraft, mostly heading for U.S. destinations. The total number of passengers and crew accommodated at Gander was about 6,600. The total population of Gander at the time was fewer than 10,000 people. Jean Chrétien, Canadian Prime Minister, claimed that there were more people at the airport than in the town." (бггг)
http://en.wikipedia.org/wiki/Operation_Yellow_Ribbon
Я правда не понял из статьи чья идея была, FAA или канадцев, но сработали хорошо.
"About 500 flights were en route to the U.S. at the time of the attacks. Transport Canada instructed NAV CANADA to give permission for flights that were at least halfway towards their destination to land at the nearest Canadian airport, depending on their point of origin and remaining fuel. Planes were entering Canadian airspace at a rate of one to two planes per minute."
"Gander International Airport, which was the first North American airport on the transatlantic route, took in 39 wide-body aircraft, mostly heading for U.S. destinations. The total number of passengers and crew accommodated at Gander was about 6,600. The total population of Gander at the time was fewer than 10,000 people. Jean Chrétien, Canadian Prime Minister, claimed that there were more people at the airport than in the town." (бггг)
https://shine.yahoo.com/parenting/getting-your-kids-off-the-ipad-is-worth-the-fight-191447400.html
Research suggests that kids of parents who set limits on digital device screentime experience positive results, including improved sleep, better grades, less aggressive behavior and lower risk of obesity
А еще, мне кажется, надо тупо отключать интернет. Доступность свежего контента должно пагубно влиять на творческие способности.
Research suggests that kids of parents who set limits on digital device screentime experience positive results, including improved sleep, better grades, less aggressive behavior and lower risk of obesity
А еще, мне кажется, надо тупо отключать интернет. Доступность свежего контента должно пагубно влиять на творческие способности.
Не то, чтобы я нашел конкретную книжку, но вот материалы с которыми может быть полезно ознакомиться:
A Fresh Graduate's Guide to Software Tools and Development
http://www.comp.nus.edu.sg/~seer/book/2e/
Книжку пишут бывшие и настоящие студенты университета Сингапура, состоит из нескольких глав по разным темам. Книжке не хватает глубины, но если вы не знаете что гуглить - это очень полезная книжка. Из нее я например узнал про Paxos algorithm и получил наглядное представление об облачных сервисах от Google и Amazon ("Chapter 06: Scalability", "Chapter 01: Cloud Computing"). Другие главы тоже могут быть полезны вне контекста сабжа, возможно доберусь до них позже.
Autopilot: Automatic Data Center Management
http://research.microsoft.com/pubs/64604/osr2007.pdf
Тоже достаточно поверхностное описание как Майкрософт строит свои датаценты, какие проблемы решает их софт для выпаски и мониторинга десятков тысяч машин. Там нет конкретных решений, but it just may get you thinking. Описана, например, базовая логика, которая позволяет обслуживать машины в датацентрах не 24/7, а 8/5.
Everything You Always Wanted to Know About Synchronization but Were Afraid to Ask
http://sigops.org/sosp/sosp13/papers/p33-david.pdf
Достаточно близкая к железу статья на тему распараллеливания софта. Анализируется несколько архитектур, включая Xeon'ы. Анализируются накладные расходы на когерентность кэшей в многопроцессорных машинах. Так я например узнал, что треды попавшие на соседний сокет (процессорный сокет), могут давать до 7.5 бОльший оверхед. Т.е., скажем, атомарные операции на многопроцессорной машине могут внезапно начать работать почти в 10 раз медленнее, только за счет того, что ядро выперло парочку тредов на соседний процессор. Даже при использовании memory fences (блоки памяти вокруг переменных изменяемых атомарно, чтобы эти атомарные переменные не кучковались рядом на одном кэш-лайне).
Это не полный список, я ощущаю что надо почитать что-то еще, но, например, MongoDB, насколько я понял, является единственной открытой БД, в которой реализован Paxos. При этом оно таки eventually consistent. В итоге, я пришел к выводу, что лучше использовать традиционные реляционные СУБД для "обычных данных" (в моем случае не так часто изменяемых), используя master-slave репликацию (и просто переключать все в read-only при отказе мастера). И использовать монгу для обработки тяжелых клиентских запросов, для которых не нужна жесткая согласованность между инстансами БД.
Еще есть вариант выпереть всякий веб в облако, а железный кластер оставить "реальным" для тяжелой математики, но не уверен, что паранойя позволит это сделать.
A Fresh Graduate's Guide to Software Tools and Development
http://www.comp.nus.edu.sg/~seer/book/2e/
Книжку пишут бывшие и настоящие студенты университета Сингапура, состоит из нескольких глав по разным темам. Книжке не хватает глубины, но если вы не знаете что гуглить - это очень полезная книжка. Из нее я например узнал про Paxos algorithm и получил наглядное представление об облачных сервисах от Google и Amazon ("Chapter 06: Scalability", "Chapter 01: Cloud Computing"). Другие главы тоже могут быть полезны вне контекста сабжа, возможно доберусь до них позже.
Autopilot: Automatic Data Center Management
http://research.microsoft.com/pubs/64604/osr2007.pdf
Тоже достаточно поверхностное описание как Майкрософт строит свои датаценты, какие проблемы решает их софт для выпаски и мониторинга десятков тысяч машин. Там нет конкретных решений, but it just may get you thinking. Описана, например, базовая логика, которая позволяет обслуживать машины в датацентрах не 24/7, а 8/5.
Everything You Always Wanted to Know About Synchronization but Were Afraid to Ask
http://sigops.org/sosp/sosp13/papers/p33-david.pdf
Достаточно близкая к железу статья на тему распараллеливания софта. Анализируется несколько архитектур, включая Xeon'ы. Анализируются накладные расходы на когерентность кэшей в многопроцессорных машинах. Так я например узнал, что треды попавшие на соседний сокет (процессорный сокет), могут давать до 7.5 бОльший оверхед. Т.е., скажем, атомарные операции на многопроцессорной машине могут внезапно начать работать почти в 10 раз медленнее, только за счет того, что ядро выперло парочку тредов на соседний процессор. Даже при использовании memory fences (блоки памяти вокруг переменных изменяемых атомарно, чтобы эти атомарные переменные не кучковались рядом на одном кэш-лайне).
Это не полный список, я ощущаю что надо почитать что-то еще, но, например, MongoDB, насколько я понял, является единственной открытой БД, в которой реализован Paxos. При этом оно таки eventually consistent. В итоге, я пришел к выводу, что лучше использовать традиционные реляционные СУБД для "обычных данных" (в моем случае не так часто изменяемых), используя master-slave репликацию (и просто переключать все в read-only при отказе мастера). И использовать монгу для обработки тяжелых клиентских запросов, для которых не нужна жесткая согласованность между инстансами БД.
Еще есть вариант выпереть всякий веб в облако, а железный кластер оставить "реальным" для тяжелой математики, но не уверен, что паранойя позволит это сделать.
Файербол в Монреале
Nov. 3rd, 2013 03:40 pmhttp://www.youtube.com/watch?v=34r6RGF2JLA
Из объяснений в треде на реддите, я понял, что в высоковольтных линиях бывает такое, когда молния или замыкание из-за веток дерева ионизирует воздух между проводами и воздух перестает быть изолятором, становясь проводником. Возникает дуга между проводами, которая перемещается по проводам из-за того что окисленные дугой провода проводят электричество хуже. Ну и, собственно, дойдя до трансформатора, это дело радостно взрывается, как на этом видео.
Задетектить эту беду мешает то, что нагрузка такой дуги обычно не превышает нормальное потребление на линии, соответственно защита не срабатывает.
Из объяснений в треде на реддите, я понял, что в высоковольтных линиях бывает такое, когда молния или замыкание из-за веток дерева ионизирует воздух между проводами и воздух перестает быть изолятором, становясь проводником. Возникает дуга между проводами, которая перемещается по проводам из-за того что окисленные дугой провода проводят электричество хуже. Ну и, собственно, дойдя до трансформатора, это дело радостно взрывается, как на этом видео.
Задетектить эту беду мешает то, что нагрузка такой дуги обычно не превышает нормальное потребление на линии, соответственно защита не срабатывает.
Сегодня вдруг обнаружил,
Oct. 30th, 2013 10:31 pmчто не знаю как внутри RAID5/6 данные распределены. Ну, то есть понятно было, что они там дублируются, но мне почему-то казалось, что просто избыточные данные раскиданы по дискам в равных долях (тот факт, что для простого дублирования нужно почти в два раза больше места, упорно от меня ускользал).
Оказывается, в RAID5/6 данные с дисков ксорят между собой последовательно, и результат записывают в специальные parity блоки. Соответственно, если любой из дисков выпадает - данные можно восстановить имея все данные соседних дисков и этот самый блок четности.
Вот тут http://blog.open-e.com/how-does-raid-5-work/ первое найденное толковое описание.
Оказывается, в RAID5/6 данные с дисков ксорят между собой последовательно, и результат записывают в специальные parity блоки. Соответственно, если любой из дисков выпадает - данные можно восстановить имея все данные соседних дисков и этот самый блок четности.
Вот тут http://blog.open-e.com/how-does-raid-5-work/ первое найденное толковое описание.
http://en.wikipedia.org/wiki/Halifax_Explosion
Мне все-таки любопытно, почему они не открыли кингстоны, когда покидали корабль? Т.е. вряд ли конечно корабль удалось бы затопить достаточно быстро, но, тем не менее.
Мне все-таки любопытно, почему они не открыли кингстоны, когда покидали корабль? Т.е. вряд ли конечно корабль удалось бы затопить достаточно быстро, но, тем не менее.
