Только если люк открывает воздушным потоком, то тем, кто его ставил нужно руки отрывать с корнем, ибо взлетевший люк вообще-то смертельно опасная вещь и прецеденты тяжелых травм и смертей есть (по этому если в этом случае сразу-же приедут представители владельца люка, то это хорошо, полиции можно будет их установить так скажем по горячим следам).
Cкажите, пожалуйста, Ваши инструменты CppCat или PVS-Studio умеют для анализа прозрачно притворяться компилятором cl?
Чтобы можно было, например, добавить путь к этой обертке в PATH, запустить сборку проекта, а потом почитать готовый отчет?
Вы о чем?
Диагностика несогласованных перемещений уже есть! Но вместо того, чтобы использовать ее для лишения гарантии производитель вымогает деньги за обслуживание прикрываясь законом, который не требует совершенно ничего подобного.
При гарантированно ненадежных средах использует CRC смотрим на CD и DVD.
Если CD или DVD в момент между извлечением диска из коробки и установкой в привод может бесследно исчезнуть, то да, его можно сравнивать с TCP. Но раз диск есть всегда и нужно только убедиться правильная ли информация считалась или нет, то механизмы типа CRC подойдут, а с учетом того, что диск все-же обычно не исчезает, то я бы его отнес к возможно ненадежным системам (данные в каком-то виде есть, а не может быть есть, а может быть и нет).
Начали скатываться на достоверность данных у хранилища. Чего как раз таки нет у TCP.
Если данные доставлены получателю, они достоверны с вероятностью отсутствия коллизии контрольной суммы.
Возможно не надежна. Иначе бы избыточности закладывали больше в том числе и CRC
Гарантировано ненадежна. Да, обычно данные доходят, но мы гарантировано знаем, что они могут и не дойти (совсем, а не прийти битые).
Избыточность увеличивает накладные расходы и никак не спасает от повторных передач. Кроме того, в сетях, в отличие от дисков основной процент отказов — недоставка пакета, а любой уровень избыточности кодирования пакета бесполезен, если пакет не был доставлен (даже контрольную сумму у него не посчитать).
Фишка как раз в том что ни черта он не знает как выяснилось из-за этого начали городить новые алгоритмы работы tcp в случае перегрузки и потерь.
Все эти алгоритмы направлена на лучшее предсказание поведения среды, а не на базовые принципы обеспечения надежности.
О том что у него там за среда передачи он ничего не знает.
Ошибаетесь. TCP точно и однозначно знает, что нижележащая среда принципиально ненадежна. В противном случае TCP был бы не нужен.
Дублирование передачи — тоже метод исправления ошибки, по этому TCP имеет функциональность и выявления ошибок, и их исправления, а также механизм предсказания поведения среды, который основываясь на особенностях поведения сетей позволяет так менять свое поведение, чтобы попытаться уменьшить вероятность возникновения ошибки в будущем (контроль перегрузки).
Эм. Как вам сказать в случае tcp это не так. tcp вообще ничего не знает о надежности среды. Фактически предполагается что среда надежна.
Это не верно.
TCP изначально создавался как протокол, обеспечивающий надежность передачи или выявление ошибки (возможно, по таймауту) по среде с принципиальной ненадежностью.
Какие риски в цене? Вы о чем? Нарушили условия предоставления гарантии — все, гарантии нет и покупатель ремонтируется за свой счет в случае чего, но покупателю же может и повести? И скорее всего статистически везет чаще, чем не везет.
В примере мейнфреймов было сказано о потере гарантии — совершенно нормальной ситуации для такой техники.
Такое оборудование покупается с сервисным контрактом.
Закон запрещает экспортировать в некоторые страны, а производитель прикрываясь якобы законом принуждает покупать и оплачивать сервисный контракт. Схема стара как мир.
Если станок был продан, а не сдан в аренду — диверсия.
Хотите сделать защиту от дурака — делаете большую красную надпись «критические отклонения параметров площадки, продолжение работы влечет потерю гарантии и возможности заключения сервисных контрактов», большую кнопку «ВЫКЛ» и маленькую «продолжить на свой страх и риск».
А когда станок блокируется без возможности самостоятельной разблокировки, то разумных объяснений этому нет. Ну точнее есть — принуждение к оплате сервисных контрактов, так как на этих контрактах завод изготовитель легко может зарабатывать больше, чем на самих станках.
при КЗ в буфере диска образовался мусор который и был записан в итоге на диск
Судя по объему поврежденных данных буфер диска (это который в диске или RAM? Если второй, то он вряд-ли бы успел куда либо записаться) должен был измеряться гигабайтами, что в том железе было невозможно :) Так что я все-же склонен считать, что посыпались не самые новые диски, а ZFS видимо таким образом «восстановилась» увидев местами битые данные, ну а суммарно — звезды так сошлись (Не часто N-лет работающие PDU вдруг коротят где-то внутри)… Хотя кто его знает. Это сейчас уже не проверишь. Уж пара лет минула с тех пор и нет в тех краях никаких Solaris.
Если бы оно не прочиталось — это было бы значительно лучше, так как проблема была бы сразу видна, а не куча сообщений о битых библиотеках и бинариках.
Полярный лис был достаточно велик, но я надеялся получить какую-то диагностику о том, что случилась какая-то нехорошая вещь прямо вот сразу, а не после того, как увидел, что случилось с системой. Так как приход пушного зверя сопровождался аварией на чистом питании (КЗ), то была перезагрузка, а после нее solaris при загрузке начал ругаться на битость библиотек и исполняемых файлов и загрузиться не смог. Согласитесь, это не является ожидаемой диагностикой повреждения ФС? Я бы предпочел чтобы сервер не загрузился ругаясь на консоль страшными словами о повреждении ФС с предложением что-нибудь сделать или грузиться на свой страх и риск.
TCP в случае бульдозериста не выдал бы мусор и можно было-бы отследить таймаут приема/передачи или разрыв соединения.
На сколько я помню, он был включен, а данные жили на двух дисках (маленький сервер был).
К слову диски практически окончательно почили в бозе на попытке сделать полный дамп для последующего анализа и доставания того, что появилось после последнего бекапа, так что может быть полярный лис был слишком велик, чтобы быть как-то скомпенсирован.
А что zfs?
Я лично сталкивался с ситуацией, когда zfs в solaris 10 рассыпалась (часть файлов пустые, часть с мусором, возможно часть пропала) из-за внезапно возникших проблем с дисками.
А вообще, очень хорошо, что такие интересные технологии у нас в Перми разрабатывают!
Чтобы можно было, например, добавить путь к этой обертке в PATH, запустить сборку проекта, а потом почитать готовый отчет?
Вы о чем?
Диагностика несогласованных перемещений уже есть! Но вместо того, чтобы использовать ее для лишения гарантии производитель вымогает деньги за обслуживание прикрываясь законом, который не требует совершенно ничего подобного.
Если CD или DVD в момент между извлечением диска из коробки и установкой в привод может бесследно исчезнуть, то да, его можно сравнивать с TCP. Но раз диск есть всегда и нужно только убедиться правильная ли информация считалась или нет, то механизмы типа CRC подойдут, а с учетом того, что диск все-же обычно не исчезает, то я бы его отнес к возможно ненадежным системам (данные в каком-то виде есть, а не может быть есть, а может быть и нет).
Если данные доставлены получателю, они достоверны с вероятностью отсутствия коллизии контрольной суммы.
Гарантировано ненадежна. Да, обычно данные доходят, но мы гарантировано знаем, что они могут и не дойти (совсем, а не прийти битые).
Избыточность увеличивает накладные расходы и никак не спасает от повторных передач. Кроме того, в сетях, в отличие от дисков основной процент отказов — недоставка пакета, а любой уровень избыточности кодирования пакета бесполезен, если пакет не был доставлен (даже контрольную сумму у него не посчитать).
Все эти алгоритмы направлена на лучшее предсказание поведения среды, а не на базовые принципы обеспечения надежности.
Ошибаетесь. TCP точно и однозначно знает, что нижележащая среда принципиально ненадежна. В противном случае TCP был бы не нужен.
Дублирование передачи — тоже метод исправления ошибки, по этому TCP имеет функциональность и выявления ошибок, и их исправления, а также механизм предсказания поведения среды, который основываясь на особенностях поведения сетей позволяет так менять свое поведение, чтобы попытаться уменьшить вероятность возникновения ошибки в будущем (контроль перегрузки).
Это не верно.
TCP изначально создавался как протокол, обеспечивающий надежность передачи или выявление ошибки (возможно, по таймауту) по среде с принципиальной ненадежностью.
В примере мейнфреймов было сказано о потере гарантии — совершенно нормальной ситуации для такой техники.
Это совершенно не связанный с обсуждаемым вопрос.
Закон запрещает экспортировать в некоторые страны, а производитель прикрываясь якобы законом принуждает покупать и оплачивать сервисный контракт. Схема стара как мир.
Хотите сделать защиту от дурака — делаете большую красную надпись «критические отклонения параметров площадки, продолжение работы влечет потерю гарантии и возможности заключения сервисных контрактов», большую кнопку «ВЫКЛ» и маленькую «продолжить на свой страх и риск».
А когда станок блокируется без возможности самостоятельной разблокировки, то разумных объяснений этому нет. Ну точнее есть — принуждение к оплате сервисных контрактов, так как на этих контрактах завод изготовитель легко может зарабатывать больше, чем на самих станках.
Судя по объему поврежденных данных буфер диска (это который в диске или RAM? Если второй, то он вряд-ли бы успел куда либо записаться) должен был измеряться гигабайтами, что в том железе было невозможно :) Так что я все-же склонен считать, что посыпались не самые новые диски, а ZFS видимо таким образом «восстановилась» увидев местами битые данные, ну а суммарно — звезды так сошлись (Не часто N-лет работающие PDU вдруг коротят где-то внутри)… Хотя кто его знает. Это сейчас уже не проверишь. Уж пара лет минула с тех пор и нет в тех краях никаких Solaris.
Если бы оно не прочиталось — это было бы значительно лучше, так как проблема была бы сразу видна, а не куча сообщений о битых библиотеках и бинариках.
TCP в случае бульдозериста не выдал бы мусор и можно было-бы отследить таймаут приема/передачи или разрыв соединения.
К слову диски практически окончательно почили в бозе на попытке сделать полный дамп для последующего анализа и доставания того, что появилось после последнего бекапа, так что может быть полярный лис был слишком велик, чтобы быть как-то скомпенсирован.
Нет Я не отрицаю, что эти механизмы там есть, но спасают они не всегда.
Я лично сталкивался с ситуацией, когда zfs в solaris 10 рассыпалась (часть файлов пустые, часть с мусором, возможно часть пропала) из-за внезапно возникших проблем с дисками.
Намеренный вывод из строя купленного оборудования его производителем — диверсия.