01.07.2012 20:36, Artem Chuprina пишет: > АН> Думаю, что сравнивать рабочую ФС и её копию - не совсем корректно. В > случае > АН> бэкапа, имеется возможность сделать новый. > Если оно побилось, пока бэкап хранился (битый блок на бэкапном винте, > например), то ты это обнаружишь только во время восстановления. Когда > по постановке задачи :) сделать новый бэкап возможности уже нет. Имелось ввиду, что был создан некорректный бэкап и есть возможность пересоздать.
> АН> Хм... Да, пожалуй, это верно. > АН> Но, если система выполняет ответственные действия..? > АН> Вопрос в том совместить требования надёжности и корректности с > АН> отказоустойчивостью и возможностью восстановления после сбоя? > Кодогенерация сишного или даже ассемблерного кода на какой-нибудь agda. > Которая из тебя душу вынет, пока ты ей корректность не докажешь. > Правда, порог вхождения весьма высокий. Про Agda не слышал. Что-то небогато по ней документации, но, насколько я понял, это система автоматического доказательства теорем. Не очень понимаю, как она может быть использована, в данном контексте: тесты же должны выполняться после компиляции..? > Мне говорили о людях, которые на Haskell делают по этой схеме авионику. > Реально летающие приборы. В сам прибор хаскельную программу запихнуть > вряд ли можно - он, зараза, ленивый, и время реакции у него поэтому > негарантированное. А с кодогенерацией - и делают, и проходят > сертификацию процесса разработки, а она (сертификация эта) в авиации > довольно серьезная. Хм... Да, про Haskell знаю, что "чистый" функциональный язык. На практике я им не пользовался, поэтому для меня он не известен. Всё никак руки не доходят осилить. Только собираюсь. :-) Я думал, что на практике он серьёзно не применяется. Но ведь, правда, Haskell должен быть надёжнее, потому что, функции не имеют "внутренних" побочных эффектов (внешние по отношению к среде, всё-равно должны быть, например, запись в файл). > Любой статически типизированный функциональный язык с нормальной > системой типов, начиная с того же Haskell или Ocaml. Ocaml? Любопытно. Пожалуй, посмотрю подробнее. Для него есть какая-то IDE? И как с библиотеками? > При правильном > применении, правда, потому что они позволяют довольно легко прострелить > себе ногу. При правильном? > Если брать что-то менее мейнстримное и более строгое, типа > той же агды, то прострелить себе ногу будет сложнее. Но и библиотек > меньше. > И да, насколько я вижу тенденции, такие вещи стараются делать, сообразив > на таком языке себе DSL, и пользуясь им. Не запрещая себе пользоваться > языком общего назначения, но все-таки выражаясь в терминах абстракций > предметной области. Хм... Про это мне ещё читать и читать. :-( > >> Я скрипты, от которых хочу надежности, обычно на перле пишу, учитывая, > >> что в Debian > >> Package: perl-base > >> Priority: required > АН> o.O Perl, кажется, похож на автомат со снятым предохранителем, > направленный в ноги? > Многое зависит от наличия головы ;-) Никто не мешает писать в каждом > перловом файле use strict; и даже запускать его с -T. Ну и эта... Все > его "короткие" варианты под девизом Do The Right Thing - они для > однострочников. В скриптах, от которых требуется надежность, никто не > запрещает использовать более многословные варианты, и даже иногда > что-нибудь проверять :-) Хм... Всё-равно, особого доверия я к нему не испытываю: слишком "обширный" синтаксис. > OPT_PARAM1=${OPT_PARAM1:-value1} > и позволить пользователю переопределять именно OPT_PARAM_1, > использование которой он потом увидит, а не неочевидно с нею связанную > ENV_USER_PARAM1 Проверять наличие в окружении OPT_PARAM перед чтением конфига. И записывать во внутреннюю переменную. Затем делать подстановку переменной по умолчанию, взятой из конфига. > А почему в конфиге? Да потому что тогда это будет написано в одном > месте, а иначе придется писать в каждом скрипте, использующем этот > конфиг. Э... Так код-то один? А конфигов может быть много... > Зато, правда, тогда зачитывать этот конфиг можно будет не > только шеллом. Но поскольку по опыту ситуация, когда один и тот же > конфиг и сурсится шеллом, и читается чем-то еще, встречается крайне > редко... По-моему, тут дополнительные сложности и нарушение ортогональности... Лучший вариант - сделать единообразный формат конфига. Или сервер, отдающий конфиг в каком-либо общем формате. -- 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/4ff0a0c2.4050...@yandex.ru