Артём Н. -> debian-russian@lists.debian.org @ Sun, 01 Jul 2012 14:35:40 +0400:
>> Вот у тебя там выше по треду было "если один файл в бэкапе побился, то
>> проще выкинуть весь бэкап". На практике это не так. Ценность остальных
>> обычно довольно высока.
АН> ...
>> При каждом таком зависе обычно fsck
>> находит и удаляет несколько orphaned inodes (т.е. файловая система
>> оказывается битой). Ценной информации при этом не потерялось ни разу.
>> Стоит ли ему, обнаружив один orphaned inode, удалять всю файловую
>> систему нафиг?
АН> Думаю, что сравнивать рабочую ФС и её копию - не совсем корректно. В случае
АН> бэкапа, имеется возможность сделать новый.
Если оно побилось, пока бэкап хранился (битый блок на бэкапном винте,
например), то ты это обнаружишь только во время восстановления. Когда
по постановке задачи :) сделать новый бэкап возможности уже нет.
>> Так вот, система обычно нужна в первую очередь выполняющая свои функции.
>> Может быть, с огрехами, но выполняющая. Надежность - требование никак
>> не первое, и скорее всего, не второе.
>> Система, при подъеме которой несколько скриптов обломались, обычно
>> все-таки поднимается, и можно что-то сделать с полученным
>> недорезультатом. А зависимостей у шелла, особенно какого-нибудь
>> статически собранного dash - минимум. Соответственно, шансов получить
>> надежную, но не загружающуюся систему, тоже минимум.
АН> Хм... Да, пожалуй, это верно.
АН> Но, если система выполняет ответственные действия..?
АН> Вопрос в том совместить требования надёжности и корректности с
АН> отказоустойчивостью и возможностью восстановления после сбоя?
Кодогенерация сишного или даже ассемблерного кода на какой-нибудь agda.
Которая из тебя душу вынет, пока ты ей корректность не докажешь.
Правда, порог вхождения весьма высокий.
Мне говорили о людях, которые на Haskell делают по этой схеме авионику.
Реально летающие приборы. В сам прибор хаскельную программу запихнуть
вряд ли можно - он, зараза, ленивый, и время реакции у него поэтому
негарантированное. А с кодогенерацией - и делают, и проходят
сертификацию процесса разработки, а она (сертификация эта) в авиации
довольно серьезная.
>> АН> Уж, если оффтопить, то по полной. :-)
>> АН> Что для создания надёжных систем больше всего подходит?
>> АН> И практически применимо (по опыту)?
>> Любой язык с полноценными ручками к fork/exec и обработкой исключений.
>> У шелла, собственно, первое есть - второго нет.
АН> Я так не думаю. C++? ObjectC?
Скажем так, чистый C в этом смысле (ну да, если понимать, что такое
исключение в случае C) будет лучше. Но годятся и эти. Я видел людей,
которые пишут работающие программы на C++ не сильно медленнее, чем я -
перловый скрипт. Но ты спрашивал про опыт. Мой опыт - perl, tcl,
python даже был.
АН> В том плане, какие языки имеют встроенную проверку корректности
АН> (семантической, естественно) и средства для повышения надёжности..?
АН> Знаю только про Ada. Но, т.к. слышал про неё лишь краем уха, ничего особо
не
АН> понятно. Плюс, языки предметной области... Вопрос, какой должен быть баланс
АН> между созданием языка предметной области и "прямым" использованием языка
общего
АН> назначения? Как должен быть организован процесс, начиная с проектирования,
хотя
АН> бы..?
Любой статически типизированный функциональный язык с нормальной
системой типов, начиная с того же Haskell или Ocaml. При правильном
применении, правда, потому что они позволяют довольно легко прострелить
себе ногу. Если брать что-то менее мейнстримное и более строгое, типа
той же агды, то прострелить себе ногу будет сложнее. Но и библиотек
меньше.
И да, насколько я вижу тенденции, такие вещи стараются делать, сообразив
на таком языке себе DSL, и пользуясь им. Не запрещая себе пользоваться
языком общего назначения, но все-таки выражаясь в терминах абстракций
предметной области.
>> Я скрипты, от которых хочу надежности, обычно на перле пишу, учитывая,
>> что в Debian
>> Package: perl-base
>> Priority: required
АН> o.O Perl, кажется, похож на автомат со снятым предохранителем,
направленный в ноги?
Многое зависит от наличия головы ;-) Никто не мешает писать в каждом
перловом файле use strict; и даже запускать его с -T. Ну и эта... Все
его "короткие" варианты под девизом Do The Right Thing - они для
однострочников. В скриптах, от которых требуется надежность, никто не
запрещает использовать более многословные варианты, и даже иногда
что-нибудь проверять :-)
>> >> Чтобы пользователь мог переопределить - это надо внутри конфига делать
>> >> подобные проверки. На предмет чего у шеллов (у всех sh-derived) есть
>> >> прекрасная подстановка ${parameter:-word}, чтобы так длинно не писать.
>> АН> Почему внутри конфига?
>>
>> Чтобы пользователь мог переопределить одну из пятнадцати переменных,
>> определенных в этом конфиге, а в остальных четырнадцати положиться на
>> конфиг.
АН> Так причём тут проверка в конфиге?
АН> Достаточно проверки в загрузчике конфига:
АН> config:
АН> OPT_PARAM1=123
АН> Скрипт:
АН> . config
АН> OPT_PARAM1=${ENV_USER_PARAM1-:OPT_PARAM1}
Можно. Но обычно удобнее в конфиге написать
OPT_PARAM1=${OPT_PARAM1:-value1}
и позволить пользователю переопределять именно OPT_PARAM_1,
использование которой он потом увидит, а не неочевидно с нею связанную
ENV_USER_PARAM1
А почему в конфиге? Да потому что тогда это будет написано в одном
месте, а иначе придется писать в каждом скрипте, использующем этот
конфиг. Зато, правда, тогда зачитывать этот конфиг можно будет не
только шеллом. Но поскольку по опыту ситуация, когда один и тот же
конфиг и сурсится шеллом, и читается чем-то еще, встречается крайне
редко...
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txxr30bq....@wizzle.ran.pp.ru
