Никогда не любил линукс...

Одна из разновидностей эффекта бабочки.

Типа да. Только бабочка - демонстрация динамического хаоса во временнóй оси, а вот это вот - демонстрация того же хаоса в пространстве конфигураций: если из достаточно сложной «стройной системы костылей и подпорок™» вытащить произвольный костыль, невозможно предсказать, что ещё отвалится...

Ядумаю, это все следствие сложности. Чем комп сложнее, тем более похож на организм, а в организме все так. Возможно, с какого-то уровня сложности ничто не может работать чотко, как часы.

Бугогашечки! Ви почти сформулировали т.н. "проблему остановки", проблему разрешимости в теории вычислимости. Тьюринг доказал, что общий алгоритм для решения проблемы остановки для любых возможных входных данных не может существовать.

Переводя на человеский: когда мы пишем программу, мы не можем заранее проверить будет-ли она работать при всех возможных данных.

Т.е. для какой-то конкретной программы, или класса программ - можно что-то утверждать, но так как на компе может быть запущена любая произвольная программа - опочки!

))

Т.е. нельзя полностью предсказать поведение программы?

Единственный сто процентный способ: запустить ее сто тыщ пятьсот раз со всеми возможными входными данными, а так как у современной серьезной программы вариантов возможных входных данных сто тыщь мильярдов, то запускать ее придется сто тыщь мильярдов раз и время проверки превысит время жизни вселенной. Где-то так.

Ну, вообще-то halting problem имеет строгое математическое решение, поэтому к "стотыщмиллионов" и "времени жизни вселенной" не сводится: всегда найдётся такая программа, для которой для _всего_ множества входных данных (а оно может быть и бесконечным) ответ "остановится ли она" невозможно получить _ни за какое_ время, "хоть за стотыщмиллионов времён жизни вселенной".

Но на практике выходит так, что хоть сто тышь мильенов жизней - хоть 10 лет - однохуйственно, так что можно не усложнять упрощенное объяснение ))

У организмов всё ещё забавней. С одной стороны - организм затачивался под работу "только в сборе", без возможности переконфигурации пользователем, и распределение ролей органов и их взаимозависимостей шло "как получится", без соблюдения архитектурной стройности (поэтому отрезаем никому не нужный аппендикс - снижается, внезапно, иммунитет). С другой стороны - если не трогать жизненно важные органы, то организм-то как раз адаптируется: если отрезать руку или ногу, работать перестаёт только рука или нога, и даже если отрезать, простите, тестикулы (важнейший орган, ответственен за выработку ряда гормонов!) - повлияет это, конечно, много на что, но прямо вот отвалятся только функции, непосредственно завязанные на них.

В принципе, и система с вирусом или какими-нибудь проблемами дохнет постепенно, иногда довольно долго можно работать на компе с глюками. Будем надеяться, что в дальнейшем способности компов к саморегуляции повысятся.

Вообще я сравнивала комп с организмом не на основании взаимозависимости частей, а скорее на основании неполной прозрачности происходящих там процессов.

Да и не в компьютерах тоже
Да-да, помнится, как-то было дело, у меня мышь законфликтовала... с настольной лампой, самой обычной. Мыша была шариковой, и яркая лампа сквозь щель у кнопки засвечивала потрошки мыши )

android -- java.
Потому и...

А ява-то тут как влияет?

Обычно такие проблемы связаны с race conditions и тому подобные трудноотлаживаемыми вещами, которые характерны для многопоточных приложений. А эта платформа хакрактерна многопоточными приложениями.

Казалось бы - как могут быть при помощи race conditions связаны программа электронной почты и работа фотокамеры/вспышки? Разве что при отмене запуска e-mail программа камеры грузится до того, как проинициализировано что-то другое ей нужное - но тогда при чём тут ява?

В-общем, ясней не стало :-)

Например, программа для работы с фотокамерой рассчитана на моментальную отправку фотографий по e-mail, для чего инициализирует программу e-mail, предполагая, что она запущена. Если она не запущена, получается вызов несуществующего API.

Это предположение, я там не копался.

1) Это не race condition
2) Неужели такое возможно только в Яве?

1) Это будет race codition, если они инициализируются одновременно в разных потоках и вызов какой-то функции из потока обслуживающего камеру, зависит от e-mail

2) Нет, конечно.

1) я не вижу здесь гонки, только неотслеженную разработчиками "зависимость": если программа e-mail запущена - камера работает, если программа e-mail не запущена - камера не работает. Вот если бы камера не работала, если e-mail запускается позже обычного... но об этом речи не идёт, речь идёт о незапуске e-mail вообще.

Кроме того, если сходить по ссылке и почитать полный текст - камера работает, если e-mail запустить ручками позже. А это уже совсем плохо соотносится с гонками...

Ну значит не гонка,значит просто зависимость одного приложения внутри платформы дот другого.

Ну да, RC у него было бы, если бы иногда работало, а иногда нет.

Любят девелоперы очень полюляют использовать всяческие фреймворки и навключать ненужных зависимостей. Это просто катастрофа какая-то, но "нам так проще".

4.ex: какая-нибудь простая утилита разрастается в десятки мегабайт и не будет работать если луна не в той фазе.
А когда ничинаешь копать, что же чудо делает, то высняется, что это всё помещяется в три строчки тривиального шелл-кода, кторому фазы луны пофигу.

В линуксе подобные фокусы с древних времён выдаёт система управления пакетами в Debian-based дистрибутивах. Из недавнего - на EEE 901 с предустановленным линуксом от ASUS'а апгрейд на новую версию Firefox требовал сноса GNOME Sudoku...

Требовать сноса - это свежо. Я чаще слышу истории вроде "хотел поставить пасьянс, а он через цепочку зависимостей потянул за собой апач, SQL-сервер и ещё два гигабайта какой-то требухи" :-)

Там всё, на самом деле, достаточно прозрачно - Firefox хотел новую версию gtk, а у Sudoku была прописана жёсткая зависимость на старую. Ещё в описании пакетов поле Conflicts есть, тоже может приводить к похожим эффектам, особенно когда конфликтующие пакеты тянутся по цепочкам зависимостей.