Автор пишет, что хаотичность и ненадежность софта в целом применяется только к алгоритмическим системам, и Брукс подразумевал только их, не рассматривая другие возможные вычислительные модели. Показывает, что есть сложные вычислительные системы (электроника), где количество багов (и трудность разработки вообще) не растет экспоненциально со сложностью.
More importantly, notice the specific claim that Brooks is making. He asserts that the unreliability of a program comes from the difficulty of enumerating and/or understanding all the possible states of the program. This is an often repeated claim in the software engineering community but it is fallacious nonetheless. It overlooks the fact that it is equally difficult to enumerate all the possible states of a complex hardware system. This is especially true if one considers that most such systems consist of many integrated circuits that interact with one another in very complex ways. Yet, in spite of this difficulty, hardware systems are orders of magnitude more robust than software systems (see the COSA Reliability Principle for more on this subject).
Чукча. "Что вижу — то пою".
Эмулятор среднего процессора пишется студентом за пару месяцев.
Ну, пусть не студентом и за пол-года — чтоб достичь такой-же степени безбаговости.
Теперь понятна степень сложности процессоров и софта?
Для программ тоже есть методики доказательства их корректности, правда не настолько сильно развитые, в силу их невостребованности.
А невостребованность проистекает из стоимости разработки таких программ. Она даже не на порядок, на два, на три порядка дороже.
Вы сейчас за винду сколько платите? 100 баксов. Платите 100 килобаксов, и будет вам щастье.
Здравствуйте, mkizub, Вы писали:
M>Эмулятор среднего процессора пишется студентом за пару месяцев.
Ты видимо не читал статью или не понял о чем речь.
Автомат, выполняющий инструкции процессора, не есть процессор.
Вот если бы он сэмулировал в виде объектов отдельные транзисторы, или отдельные логические устройства, и достиг той же степени надежности, что и в железе (звуковуха может глючить, но ничто остальное не затронет) — тогда да.
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, mkizub, Вы писали:
M>>Эмулятор среднего процессора пишется студентом за пару месяцев.
Кё>Ты видимо не читал статью или не понял о чем речь.
Кё>Автомат, выполняющий инструкции процессора, не есть процессор.
Кё>Вот если бы он сэмулировал в виде объектов отдельные транзисторы, или отдельные логические устройства, и достиг той же степени надежности, что и в железе (звуковуха может глючить, но ничто остальное не затронет) — тогда да.
Для корректной работы процессора нам не нужно знать из каких транзисторов он состоит, фактически контрактом являются напряжения на ножках этого процессора (суть входы/выходы), которые есть по сути реализация эмулятора. И этот контракт жёстко зафиксирован и соблюдение его гарантируется (хотя помнится были и процессоры с багами).
А теперь возьми, к примеру Windows, где нет строгого "контракта". Попробуй описать все возможные входы/выходы, с учётом того, что тут появятся продукты "3-х лиц", драйверы и устройства, которые возможно тоже не свободны от багов.
И попробуй сравнить мощности моделей.
Здравствуйте, Курилка, Вы писали:
К>Для корректной работы процессора нам не нужно знать из каких транзисторов он состоит, фактически контрактом являются напряжения на ножках этого процессора (суть входы/выходы), которые есть по сути реализация эмулятора. И этот контракт жёстко зафиксирован и соблюдение его гарантируется (хотя помнится были и процессоры с багами).
Эмуляция процессора состоит из эмуляции отдельных команд, между которыми нет никаких зависимостей, и которые сами по себе простые. Исправь баги в каждой команде — и готово. Простые компоненты без зависимостей — это совсем не похоже ни на современный софт, ни на железо, на этом примере ничего по теме не доказать.
К>А теперь возьми, к примеру Windows, где нет строгого "контракта". Попробуй описать все возможные входы/выходы, с учётом того, что тут появятся продукты "3-х лиц", драйверы и устройства, которые возможно тоже не свободны от багов.
У general-purpose вещей контракта нет по определению. Его нет и у персонального компьютера. Но у любого компонента Windows — есть. И что получается? Сбойный драйвер ломает всю систему. Неожиданное исключение из недр используемой библиотеки аварийно завершает весь алгоритм. Кусочек плохого кода сразу низводит надежность алгоритма до его надежности, независимо от того, насколько он вообще нужен.
Например, если сбойнет запись в лог, или обновление индикатора прогресса, это вообще не значит, что задача не может быть выполнена, но вы не станете с этим ничего сделать (Именно так — можете, но не станете. Не анализировать же полдня каждую функцию на все возможные исходы?). В противоположность этому, сбойное устройство обычно ломает только то, что зависит от него, и это не меняется с ростом числа устройств — и это поведение системы по умолчанию, для этого вокруг устройства не надо ставить дополнительные ловушки исключений.
Здравствуйте, Кодёнок, Вы писали:
Кё>Например, если сбойнет запись в лог, или обновление индикатора прогресса, это вообще не значит, что задача не может быть выполнена, но вы не станете с этим ничего сделать (Именно так — можете, но не станете. Не анализировать же полдня каждую функцию на все возможные исходы?). В противоположность этому, сбойное устройство обычно ломает только то, что зависит от него, и это не меняется с ростом числа устройств — и это поведение системы по умолчанию, для этого вокруг устройства не надо ставить дополнительные ловушки исключений.
Типа, если в CPU навернётся декодер комманд или блок ALU, то процессор отряхнётся и дальше будет работать?
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, Курилка, Вы писали:
К>>Для корректной работы процессора нам не нужно знать из каких транзисторов он состоит, фактически контрактом являются напряжения на ножках этого процессора (суть входы/выходы), которые есть по сути реализация эмулятора. И этот контракт жёстко зафиксирован и соблюдение его гарантируется (хотя помнится были и процессоры с багами).
Кё>Эмуляция процессора состоит из эмуляции отдельных команд, между которыми нет никаких зависимостей, и которые сами по себе простые. Исправь баги в каждой команде — и готово. Простые компоненты без зависимостей — это совсем не похоже ни на современный софт, ни на железо, на этом примере ничего по теме не доказать.
О как, у нас и регистры вдруг пропали вдруг из процессора, да? И память тоже не используется? (хотя, безусловно, это внешний ресурс, если не говорить про кэш)
К>>А теперь возьми, к примеру Windows, где нет строгого "контракта". Попробуй описать все возможные входы/выходы, с учётом того, что тут появятся продукты "3-х лиц", драйверы и устройства, которые возможно тоже не свободны от багов.
Кё>У general-purpose вещей контракта нет по определению. Его нет и у персонального компьютера. Но у любого компонента Windows — есть. И что получается? Сбойный драйвер ломает всю систему. Неожиданное исключение из недр используемой библиотеки аварийно завершает весь алгоритм. Кусочек плохого кода сразу низводит надежность алгоритма до его надежности, независимо от того, насколько он вообще нужен.
Контракт "любого компонента" можно? Который бы не включал зависимости от других частей системы?
Кё>Например, если сбойнет запись в лог, или обновление индикатора прогресса, это вообще не значит, что задача не может быть выполнена, но вы не станете с этим ничего сделать (Именно так — можете, но не станете. Не анализировать же полдня каждую функцию на все возможные исходы?). В противоположность этому, сбойное устройство обычно ломает только то, что зависит от него, и это не меняется с ростом числа устройств — и это поведение системы по умолчанию, для этого вокруг устройства не надо ставить дополнительные ловушки исключений.
А если у тебя от записи в лог будет зависеть другие части системы? Точно также будут ломаться зависимые части.
Просто в рамках (современного) компьютера и ОС получить неявные зависимости гораздо проще, но с этим борются (как пример — software isolated processes), правда прогресс усложнения ПО по ходу дела идёт быстрей, чем прогресс у тех, кто борется.
Здравствуйте, mkizub, Вы писали:
M>Типа, если в CPU навернётся декодер комманд или блок ALU, то процессор отряхнётся и дальше будет работать?
Сломается все, что от них зависит, но ничто остальное. Если весь процессор зависит — то весь процессор, но никогда — сетевая карта. В алгоритме непредусмотренный сбой ломает все и насовсем.
Я еще раз повторяю, что процессор это плохой пример, от него зависит всё. Возьми сетевую карту, CD-ROM, звуковуху.
Здравствуйте, Курилка, Вы писали:
Кё>>Например, если сбойнет запись в лог, или обновление индикатора прогресса, это вообще не значит, что задача не может быть выполнена, но вы не станете с этим ничего сделать (Именно так — можете, но не станете. Не анализировать же полдня каждую функцию на все возможные исходы?). В противоположность этому, сбойное устройство обычно ломает только то, что зависит от него, и это не меняется с ростом числа устройств — и это поведение системы по умолчанию, для этого вокруг устройства не надо ставить дополнительные ловушки исключений.
К>А если у тебя от записи в лог будет зависеть другие части системы?
Для обоих плохо читающих, я выделил жирным. Никто не говорит о чудесах. Как можно обсуждать статью, если такие элементарные вещи не даются?
Еще раз, тезис статьи:
1. Непредусмотренный сбой в алгоритме ломает его весь. В современных системах есть способы поймать любой сбой (catch(...)), но они используются редко, считаются плохой практикой почти везде кроме нескольких исключительных мест (вроде message loop), и вы точно никогда не станете заполнять ими все свои программы, хотя бы потому, что все равно не знаете, что делать с любой ошибкой.
2. Непредусмотренный сбой в устройстве не дает возможности им пользоваться, но операции, которые от устройства не зависят, продолжаются как ни в чем не бывало. Устройство можно выключить или перезапустить, если такое предусмотрено.
Тезис ничем не отличается от подхода Singularity, которую вы, насколько я помню, горячо поддерживали. Интересно, что изменилось? Разница в том, что Singularity реализует это в рамках процессов системы, деление на которые производт сам программист, а этот парень мечтает все свести на уровень железа, вплоть до элементарных операций, чтобы даже сами такие процессы конструировались из других.
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, mkizub, Вы писали:
M>>Типа, если в CPU навернётся декодер комманд или блок ALU, то процессор отряхнётся и дальше будет работать?
Кё>Сломается все, что от них зависит, но ничто остальное. Если весь процессор зависит — то весь процессор, но никогда — сетевая карта. В алгоритме непредусмотренный сбой ломает все и насовсем.
Кё>Я еще раз повторяю, что процессор это плохой пример, от него зависит всё. Возьми сетевую карту, CD-ROM, звуковуху.
Какие-то двойные стандарты получаются
Кстати чем software isolated processes и т.п. идеи не есть отображение того, чтоб ломалось только "по зависимостям"?
Кстати, аналогии про телевизоры и т.п. ещё Таненбаум давно продвигал, собственно независимость отдельных частей друг от друга (за счёт микроядра) есть один из краеугольных камней в его Minix 3.
Здравствуйте, Кодёнок, Вы писали:
Кё>Еще раз, тезис статьи:
Кё>1. Непредусмотренный сбой в алгоритме ломает его весь. В современных системах есть способы поймать любой сбой (catch(...)), но они используются редко, считаются плохой практикой почти везде кроме нескольких исключительных мест (вроде message loop), и вы точно никогда не станете заполнять ими все свои программы, хотя бы потому, что все равно не знаете, что делать с любой ошибкой.
Кё>2. Непредусмотренный сбой в устройстве не дает возможности им пользоваться, но операции, которые от устройства не зависят, продолжаются как ни в чем не бывало. Устройство можно выключить или перезапустить, если такое предусмотрено.
Кё>Тезис ничем не отличается от подхода Singularity, которую вы, насколько я помню, горячо поддерживали. Интересно, что изменилось? Разница в том, что Singularity реализует это в рамках процессов системы, деление на которые производт сам программист, а этот парень мечтает все свести на уровень железа, вплоть до элементарных операций, чтобы даже сами такие процессы конструировались из других.
Вы (выделенное) — это я лично? Тогда плохо помнишь, апологеты сингулярити тут есть, но я к ним не отношусь.
Что значит "всё свести на уровень железа" как-то выше моего понимания.
Здравствуйте, Курилка, Вы писали:
К>Кстати чем software isolated processes и т.п. идеи не есть отображение того, чтоб ломалось только "по зависимостям"? К>Кстати, аналогии про телевизоры и т.п. ещё Таненбаум давно продвигал, собственно независимость отдельных частей друг от друга (за счёт микроядра) есть один из краеугольных камней в его Minix 3.
Это оно и есть. Только SIP или ерланговские процессы конструируются из маленьких алгоритмов, т.е. внутри себя потенциально все еще страдают от тех же проблем (хотя в таком масштабе они вполне могут быть незаметны).
А автору захотелось отбросить алгоритмы (и концепцию Тьюринг-машины) вообще, правда что-то не ясно, как именно
Здравствуйте, Кодёнок, Вы писали:
Кё>В противоположность этому, сбойное устройство обычно ломает только то, что зависит от него, и это не меняется с ростом числа устройств — и это поведение системы по умолчанию, для этого вокруг устройства не надо ставить дополнительные ловушки исключений.
Это так, только при условии что ни аппаратная ни программная часть (драйвер) сбой не заметила. Тогда "сломавшееся" молча устройство _возможно_ ничего не затронет. Если устройство коротнёт и сожжёт всех соседей — ваше утверждение неверно. Если устройство засбоит, и нарушит работу программной части — операционная система мгновенно завершит работу (BSOD, Kernel Panic, etc.).
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, Курилка, Вы писали:
К>>Кстати чем software isolated processes и т.п. идеи не есть отображение того, чтоб ломалось только "по зависимостям"? К>>Кстати, аналогии про телевизоры и т.п. ещё Таненбаум давно продвигал, собственно независимость отдельных частей друг от друга (за счёт микроядра) есть один из краеугольных камней в его Minix 3.
Кё>Это оно и есть. Только SIP или ерланговские процессы конструируются из маленьких алгоритмов, т.е. внутри себя потенциально все еще страдают от тех же проблем (хотя в таком масштабе они вполне могут быть незаметны).
Ужасно нравятся мне такие абстрактные разговоры.
Что за "те же проблемы" на примере эрланга?
Понятие алгоритма и наличие зависимостей — вещи совершенно разные (причём зависимости — вещь неизбежная, т.к. программа без I/O никому не нужна)
Кё>А автору захотелось отбросить алгоритмы (и концепцию Тьюринг-машины) вообще, правда что-то не ясно, как именно
Мешок хорошего плана спасёт отца нерусской демократии
(хотя по ходу спасает уже во всю)
Здравствуйте, Кодёнок, Вы писали:
Кё>Я еще раз повторяю, что процессор это плохой пример, от него зависит всё. Возьми сетевую карту, CD-ROM, звуковуху.
Угу. Неужели ты думаешь, что если звуковуха начнет гадить в шину, то все остальные "отряхнутся и продолжат работать"?
Автор статьи также рассказывает о том, как мало багов он видел в процессорах.
Открытое издевательство:
1. Баги в процессорах находят на регулярной основе.
2. Стоимость разработки современного процессора — крайне высока. Если вкладывать по три-четыре миллиарда долларов в каждый софтный проект, то надежность софта резко улучшится.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IID, Вы писали:
Кё>>В противоположность этому, сбойное устройство обычно ломает только то, что зависит от него, и это не меняется с ростом числа устройств — и это поведение системы по умолчанию, для этого вокруг устройства не надо ставить дополнительные ловушки исключений.
IID>Это так, только при условии что ни аппаратная ни программная часть (драйвер) сбой не заметила. Тогда "сломавшееся" молча устройство _возможно_ ничего не затронет. Если устройство коротнёт и сожжёт всех соседей — ваше утверждение неверно. Если устройство засбоит, и нарушит работу программной части — операционная система мгновенно завершит работу (BSOD, Kernel Panic, etc.).
С этим никто не спорит.
Брукс заявил, что баговость и невозможность выпускать софт таким же [более-менее] надежным как железо, останется навсегда, потому что software is a special case. Автор говорит, что при условии отказа от концепции алгоритма, возможно то самое повышение качества, известное как Silver Bullet. Это тема топика, давайте о ней поговорим?
Здравствуйте, Кодёнок, Вы писали:
Кё>Брукс заявил, что баговость и невозможность выпускать софт таким же [более-менее] надежным как железо, останется навсегда, потому что software is a special case. Автор говорит, что при условии отказа от концепции алгоритма, возможно то самое повышение качества, известное как Silver Bullet. Это тема топика, давайте о ней поговорим?
Ну да, если отказаться от софта, то проблем с софтом не будет, эт и ежу понятно.
BTW это ничего, что логику процессоров описывают алгоритмами? Так же как вся математика этими алгоритмами пропитана, её тоже выкинем? И физику, коль она математикой пользуется
Здравствуйте, Курилка, Вы писали:
К>Что за "те же проблемы" на примере эрланга? К>Понятие алгоритма и наличие зависимостей — вещи совершенно разные (причём зависимости — вещь неизбежная, т.к. программа без I/O никому не нужна)
Автор заявил, что невозможность достигнуть уровня качества других инженерных областей присуща только алгоритмам и их разработке, а если разрабатывать другим способом, например, разработка устройств из обменивающихся сигналами стандартных элементов, то это станет возможно. А т.к. ерланговские процессы конструируются из алгоритмов, то... в общем понятно. Это в теории, если хочется на практике и строго об эрланге, то лучше в комментарии к тому блогу пойти.
Здравствуйте, Sinclair, Вы писали:
Кё>>Я еще раз повторяю, что процессор это плохой пример, от него зависит всё. Возьми сетевую карту, CD-ROM, звуковуху. S>Угу. Неужели ты думаешь, что если звуковуха начнет гадить в шину, то все остальные "отряхнутся и продолжат работать"?
Не думаю, но речь не о достижении абсолютной идеальной надежности, а о её повышении. Каково твое мнение, если разрабатывать софт так же, как разрабатывают железо, то
1. Ничего не изменится (потому что software is different?)
2. Качество/стоимость разработки повысится
3. Качество/стоимость понизится (потому что станет еще хуже?)
Вот что меня интересует.
S>Автор статьи также рассказывает о том, как мало багов он видел в процессорах. S>Открытое издевательство: S>1. Баги в процессорах находят на регулярной основе. S>2. Стоимость разработки современного процессора — крайне высока. Если вкладывать по три-четыре миллиарда долларов в каждый софтный проект, то надежность софта резко улучшится.
А других устройств? Еще раз — процессор это частный случай. А звуковуха или модем?
по поводу The Seven Deadly Sins of Erlang
