[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Несколько вопросов вразброс



01.07.2012 13:48, Artem Chuprina пишет:
> Вот скажем, у меня на одной из работ
> электростатика такая, что неудачно коснувшись клавиатуры недобука, можно
> огрести полный завис системы.
o.O

> Вот у тебя там выше по треду было "если один файл в бэкапе побился, то
> проще выкинуть весь бэкап".  На практике это не так.  Ценность остальных
> обычно довольно высока.
...
> При каждом таком зависе обычно fsck
> находит и удаляет несколько orphaned inodes (т.е. файловая система
> оказывается битой).  Ценной информации при этом не потерялось ни разу.
> Стоит ли ему, обнаружив один orphaned inode, удалять всю файловую
> систему нафиг?
Думаю, что сравнивать рабочую ФС и её копию - не совсем корректно. В случае
бэкапа, имеется возможность сделать новый. Согласен, что лучше неполный, чем
ничего. Но лучше полный: если в бэкапе побился один файл, неизвестно, что ещё
побилось, и как пройдёт восстановление.
Если что-то побилось в ФС - есть либо, неработающая система, либо работающая
система, которую проще проверить, чем восстанавливать "с нуля". Если побилось
много - очевидно, проще из бэкапа, даже с потерей последних изменений.

> Так вот, система обычно нужна в первую очередь выполняющая свои функции.
> Может быть, с огрехами, но выполняющая.  Надежность - требование никак
> не первое, и скорее всего, не второе.
> Система, при подъеме которой несколько скриптов обломались, обычно
> все-таки поднимается, и можно что-то сделать с полученным
> недорезультатом.  А зависимостей у шелла, особенно какого-нибудь
> статически собранного dash - минимум.  Соответственно, шансов получить
> надежную, но не загружающуюся систему, тоже минимум.
Хм... Да, пожалуй, это верно.
Но, если система выполняет ответственные действия..?
Вопрос в том совместить требования надёжности и корректности с
отказоустойчивостью и возможностью восстановления после сбоя?

>  АН> Уж, если оффтопить, то по полной. :-)
>  АН> Что для создания надёжных систем больше всего подходит?
>  АН> И практически применимо (по опыту)?
> Любой язык с полноценными ручками к fork/exec и обработкой исключений.
> У шелла, собственно, первое есть - второго нет.
Я так не думаю. C++? ObjectC?
В том плане, какие языки имеют встроенную проверку корректности (семантической,
естественно) и средства для повышения надёжности..?
Знаю только про Ada. Но, т.к. слышал про неё лишь краем уха, ничего особо не
понятно. Плюс, языки предметной области... Вопрос, какой должен быть баланс
между созданием языка предметной области и "прямым" использованием языка общего
назначения? Как должен быть организован процесс, начиная с проектирования, хотя
бы..?
Даже тот же TDD... У меня получилась, что тесты - треть кода. Это мало
приемлемо. Т.е., надо определить степень покрытия тестами. В маленьком проекте
(таким, как этот "игрушечный" скрипт), видимо, её надо уменьшать (ну размер
проекта может быть достаточным, относительно "маленьким"). В больших..? Блин,
сложно всё как-то... Фигня в башке вертится. :-(

> Я скрипты, от которых хочу надежности, обычно на перле пишу, учитывая,
> что в Debian
> Package: perl-base                       
> Priority: required
o.O Perl, кажется, похож на автомат со снятым предохранителем, направленный в ноги?

>  >> Чтобы пользователь мог переопределить - это надо внутри конфига делать
>  >> подобные проверки.  На предмет чего у шеллов (у всех sh-derived) есть
>  >> прекрасная подстановка ${parameter:-word}, чтобы так длинно не писать.
>  АН> Почему внутри конфига?
> 
> Чтобы пользователь мог переопределить одну из пятнадцати переменных,
> определенных в этом конфиге, а в остальных четырнадцати положиться на
> конфиг.
Так причём тут проверка в конфиге?
Достаточно проверки в загрузчике конфига:
config:
OPT_PARAM1=123

Скрипт:
. config
OPT_PARAM1=${ENV_USER_PARAM1-:OPT_PARAM1}


Reply to: