Приливное взаимодействие очень важно, благодаря им, например, и Меркурий синхронизировал своё вращение.
В системах тесных двойных звёзд при расчёте кривых блеска (график «время» «звёздная величина») важно учитывать раздутие атмосфер звёзд из-за приливных эффектов.
Замена слов «ядерное» на слова «атомные» произошло после аварии на ЧАЭС. Тогда же Ядерный Магнитный Резонансный (ЯМР) томограф начали называть Магнитно-Резонансной Терапией (МРТ).
Это связано с паникой людей при слове «ядерная» после ЧАЭС.
Обожаю словосочетание «критическая масса», оно такое неправильное. Хуже только называть ядерную бомбу «атомной». Словосочетание для запутывания шпионов: «критическая масса» зависит от множества внешних факторов.
А свежий плутоний, если я правильно помню, почти не светит в гамма-лучах, а alpha и beta при попадании на кожу не так опасны: проникающая способность гораздо ниже.
Да, в этом случае, MySQL «надёжнее» FS на которую она опирается. Однако это не-ГОСТовый смысл.
Вам, видимо, достаточно сообщения об ошибке. Я считаю, что ошибка, даже с сообщением (и тем более без) — это уже отказ. ГОСТ, видимо, про сообщениях об ошибках ничего не знает.
То есть когда девушка разворачивается и уходит или говорит «нет, потому что ...» (EBUSY) — это отказ и так и так. Только в одном случае причина понятна, и с ней можно бороться (найти другой экземпляр девушки), а в другом — нет.
В общем, я согласен, что MySQL иногда говорит об ошибках лучше, чем FS. Однако не считаю, что это делает его надёжнее (однако позволяет сделать более очевидным отказ приложения опирающегося на MySQL, по сравнению с приложением на FS).
А надёжность современных компьютерных программ пренебрежимо мало отличается от 1. Настолько мало, что меряются уже -log(1-надёжность).
Вы хотите сказать, что надёжность MySQL не зависит от надёжности FS? Да, в специальном случае когда вы пишите в raw-device. Но даже в этом случае какая-то FS может порушить стэк VFS и это приведёт к краху MySQL.
Что бы исправить ошибку связанную с конкретной FS достаточно иногда записать в другое место, но это уже другой экземпляр FS, и вероятности отказа будут считаться иначе.
Странно, что MySQL'ю Вы прощаете незакоммиченые транзакци, а FS — не прощаете не до конца записанные файлы. То, что транзакция была отправлена но не была записана — это отказ.
И если вы внезапно удалить устройство (физически), на которое пишется БД, то отказ у FS и у MySQL/InnoDB/device будет одинаковым. И тот и другой сообщат об ошибке, но это будет отказ в обоих случаях.
Ну и не надо путать Юпитер с Землёй, размеры «немножко» разные.
В системах тесных двойных звёзд при расчёте кривых блеска (график «время» «звёздная величина») важно учитывать раздутие атмосфер звёзд из-за приливных эффектов.
Кстати, у луны центр тяжести смещён в нашу сторону, именно поэтому вращения синхронизировались.
Это связано с паникой людей при слове «ядерная» после ЧАЭС.
А свежий плутоний, если я правильно помню, почти не светит в гамма-лучах, а alpha и beta при попадании на кожу не так опасны: проникающая способность гораздо ниже.
2) И знания, и опыт, могут быть приобретены.
Общество потребления.
Нужная фича? Напиши!
Вам, видимо, достаточно сообщения об ошибке. Я считаю, что ошибка, даже с сообщением (и тем более без) — это уже отказ. ГОСТ, видимо, про сообщениях об ошибках ничего не знает.
То есть когда девушка разворачивается и уходит или говорит «нет, потому что ...» (EBUSY) — это отказ и так и так. Только в одном случае причина понятна, и с ней можно бороться (найти другой экземпляр девушки), а в другом — нет.
В общем, я согласен, что MySQL иногда говорит об ошибках лучше, чем FS. Однако не считаю, что это делает его надёжнее (однако позволяет сделать более очевидным отказ приложения опирающегося на MySQL, по сравнению с приложением на FS).
Вы хотите сказать, что надёжность MySQL не зависит от надёжности FS? Да, в специальном случае когда вы пишите в raw-device. Но даже в этом случае какая-то FS может порушить стэк VFS и это приведёт к краху MySQL.
Что бы исправить ошибку связанную с конкретной FS достаточно иногда записать в другое место, но это уже другой экземпляр FS, и вероятности отказа будут считаться иначе.
В основном, имелось ввиду, что если на устройстве кончится место, то и MySQL откажет (потому-что FS откажет), и FS.
И если вы внезапно удалить устройство (физически), на которое пишется БД, то отказ у FS и у MySQL/InnoDB/device будет одинаковым. И тот и другой сообщат об ошибке, но это будет отказ в обоих случаях.