Здравствуйте, gandalfgrey, Вы писали:

ГВ>>До некоторой степени. Сам понимаешь, что уязвимость системы определяется самым уязвимым звеном. Если скрипт выполняет какую-то критически важную работу, и при этом не защищён от неуправляемых обновлений, то это называется "дыркой". Пусть он даже работает в трёхслойном сандбоксе.
G>Понятно, что именно до некоторой степени ! Но тут есть парадокс : когда я собирал статистику среди телемехаников, на первом месте стояла надежность системы — и это понятно. А вот при эксплуатации на передний план незаметным образом выползает гибкость, оттесняя надежность назад. Причем у тех же самых людей, надо заметить.

Ну и чему тут удивляться? ИМХО, это как раз отражает некую "иерархию приоритетов": прежде всего — надёжность; далее, когда уже подразумевается, что с надёжностью всё в порядке — удобство. В рабочих условиях чаще всего вспоминают про удобство — это ежу понятно. Но удобное ненадёжному не предпочтут, скорее всего, поскольку плюсы от удобства не перекроют минусов от большей возни с ненадёжным устройством.

G>Так что приходится балансировать между тем и другим. Не создается ли тут перевес в одну сторону — вопрос насущный.

Тут вопрос даже не в перевесе, а в возможном неумышленном самообмане, который окажется миной замедленного действия.

Здравствуйте, Геннадий Васильев, Вы писали:

G>>Понятно, что именно до некоторой степени ! Но тут есть парадокс : когда я собирал статистику среди телемехаников, на первом месте стояла надежность системы — и это понятно. А вот при эксплуатации на передний план незаметным образом выползает гибкость, оттесняя надежность назад. Причем у тех же самых людей, надо заметить.

ГВ>Ну и чему тут удивляться? ИМХО, это как раз отражает некую "иерархию приоритетов": прежде всего — надёжность; далее, когда уже подразумевается, что с надёжностью всё в порядке — удобство. В рабочих условиях чаще всего вспоминают про удобство — это ежу понятно. Но удобное ненадёжному не предпочтут, скорее всего, поскольку плюсы от удобства не перекроют минусов от большей возни с ненадёжным устройством.

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

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ну, я так и думал: если на C++ мы получаем относительно редкие, но "большие" падения, то на языках типа Эрланга — мелкие, но много. Это не в упрёк Эрлангу, не подумай. Просто обычная семантика возобновления, которая в защищённых условиях может использоваться без особых трудностей.
Как говорит крутой парень Джо Армстронг — падения в Ерланге есть норма жизни. Главное, что мы всегда можем их обработать и отреагировать.

Здравствуйте, eao197, Вы писали:

E>Кстати да! На моем веку было именно так -- "дайте нам больше гибкости, но чтобы надежность ни в коем случае не пострадала". Временами одновременно требуют повышения и того, и другого.
А иногда требуют гибкости за счет надежности / безопасности, просто не говоря об этом явно...

Здравствуйте, gandalfgrey, Вы писали:

E>>Кстати да! На моем веку было именно так -- "дайте нам больше гибкости, но чтобы надежность ни в коем случае не пострадала". Временами одновременно требуют повышения и того, и другого.
G>А иногда требуют гибкости за счет надежности / безопасности, просто не говоря об этом явно...

Мне, наверное, повезло. Но требований снижения надежности я не припомню.

Хотя, может быть из-за того, что надежность C++ных программ /как здесь очень многие полагают/ и так уже ниже плинтуса?

Здравствуйте, gandalfgrey, Вы писали:

E>>ASN.1, Google Protocol Buffers, Boost.Serialization, s11n.net, даже мой собственный велосипед ObjESSty -- все это работает без встроенной поддержки со стороны языка.
G>Нууууууууу...это все не то. АСН.1 требует предварительного описания, к примеру

А как же без описания в задачах, где требуется сериализация? Если бы нам надо было гонять данные только лишь м/у абсолютно совместимыми (напр. по языку, железу и отображением структур в памяти) системами, то можно было бы прямо куски памяти гонять, без морок с какой-то сериализацией.

Здравствуйте, vdimas, Вы писали:

V>А как же без описания в задачах, где требуется сериализация? Если бы нам надо было гонять данные только лишь м/у абсолютно совместимыми (напр. по языку, железу и отображением структур в памяти) системами, то можно было бы прямо куски памяти гонять, без морок с какой-то сериализацией.

А так же, как в случае с XML (без DTD или XSD), JSON, YAML... Там формат практически самоописывающийся.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ну и чему тут удивляться? ИМХО, это как раз отражает некую "иерархию приоритетов": прежде всего — надёжность; далее, когда уже подразумевается, что с надёжностью всё в порядке — удобство. В рабочих условиях чаще всего вспоминают про удобство — это ежу понятно. Но удобное ненадёжному не предпочтут, скорее всего, поскольку плюсы от удобства не перекроют минусов от большей возни с ненадёжным устройством.
Когда выбирают надежную, но дубовую систему или гибкую, но менее устойчивую — часто делают по факту выбор №2, на словах провозглашая приоритет выбора №1

ГВ>Тут вопрос даже не в перевесе, а в возможном неумышленном самообмане, который окажется миной замедленного действия.
Эхехехе...Есть такое понятие — цейтнот, которое совсем не способствует вдумчивому взвешиванию всех вариантов и последствий их использования. Но даже и без аврала — как сложить в один мешок несовместимые требования ? Вот и приходится выбирать меньшее зло, или то зло, что лучше пахнет, или хотя бы приятнее на вид 8))

Здравствуйте, gandalfgrey, Вы писали:

ГВ>>Я тебе про Фому, а ты мне про Ерёму. Технические сложности давай уж отдельно, организационные — отдельно. Я понимаю, что реальные условия обычно противоречивы и полны глупостей, но это не означает, что глупости перестают быть таковыми. В твоём случае я вижу организационную глупость, связанную с тем, что код вроде бы и нельзя обновлять, но в то же время можно. Можно называеть это корпоративным бюрократизмом, можно ещё как-то — не суть. Суть в том, что у ваших заказчиков эммм... несколько противоречивый подход к организации обновлений.
G>Дык ить, если бы у одного заказчика ! У всех так, как это ни печально

Дык ить — не сомневаюсь. Меня в таких коллизиях напрягает то, что дядьки в дорогих костюмах играют в корпоративные бумажки, а в среде технических специалистов уживаются некие "мифы", типа того, который ты озвучил в первых сообщениях. На поверку, разумеется, вышло, что чуда никакого нет. Всё осталось на своих местах, как всегда.

ГВ>>Ничего революционного в передаче алгоритмов по проводам нет. Революционными были твои формулировки задач на передачу алгоритмов. Я зацепился за твоё высказывание о том, что программа-де может самонастраиваться на обработку новых форматов данных и т.п. На поверку выходит, что никакой неожиданной "самонастройки" на самом деле нет — есть всё то, о чём упомянули твои оппоненты: предварительная подготовка требований, предварительная подготовка системы к самонастройке в виде "закладок", заранее согласованный протокол и т.п.
G>Гм ! Все, что я хотел сказать — это то, что мой подход позволяет сократить эти процедуры, иногда очень сильно. Но ликвидировать их совсем — не получится. Хотя бы потому, что некий начальный протокол ДОЛЖЕН быть согласован — даже если потом он будет равиваться сам по щучьему велению

С одной строны, сейчас ты сформулировал примерно то же самое, о чём тебе говорили с самого начала. С другой — совсем ликвидировать приёмо-сдаточные процедуры нельзя по организационным соображениям. С третьей стороны — твой подход может упростить не столько сами процедуры, сколько развёртывание обновлений после приёмки. Это снова — "по уму". Честно говоря, "минусовать" руководство ваших заказчиков я тут уже запарился.

G>Ну, и должна быть спроектирована архитектура, которая позволит производить эти модификации / самомодификации без изменения ядра системы на максимально возможный срок.

Да-да-да. Именно так, сначала — общие соглашения о том что куда можно.

Здравствуйте, gandalfgrey, Вы писали:

ГВ>>Ну и чему тут удивляться? ИМХО, это как раз отражает некую "иерархию приоритетов" [...]
G>Когда выбирают надежную, но дубовую систему или гибкую, но менее устойчивую — часто делают по факту выбор №2, на словах провозглашая приоритет выбора №1

Ну, если всем всё по х.., то медицина бессильна.

ГВ>>Тут вопрос даже не в перевесе, а в возможном неумышленном самообмане, который окажется миной замедленного действия.
G>Эхехехе...Есть такое понятие — цейтнот, которое совсем не способствует вдумчивому взвешиванию всех вариантов и последствий их использования. Но даже и без аврала — как сложить в один мешок несовместимые требования ? Вот и приходится выбирать меньшее зло, или то зло, что лучше пахнет, или хотя бы приятнее на вид 8))

Ну что тут скажешь... Как всегда, всё сходится на руководстве: не сам же по себе этот самый цейтнот возникает.

Здравствуйте, eao197, Вы писали:

E>Кстати да! На моем веку было именно так -- "дайте нам больше гибкости, но чтобы надежность ни в коем случае не пострадала". Временами одновременно требуют повышения и того, и другого.

Это как раз нормально: кому нужно второстепенное качество без первоочередного?

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Это как раз нормально: кому нужно второстепенное качество без первоочередного?

Ну да, это нормально. Вот только gandalfgrey в других условиях оказался. Или ему так сейчас кажется.

Здравствуйте, gandalfgrey, Вы писали:

E>>Кстати да! На моем веку было именно так -- "дайте нам больше гибкости, но чтобы надежность ни в коем случае не пострадала". Временами одновременно требуют повышения и того, и другого.
G>А иногда требуют гибкости за счет надежности / безопасности, просто не говоря об этом явно...

Мда... А потом ещё что-то говорят про программистов, цивилизацию и дятлов...

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Мда... А потом ещё что-то говорят про программистов, цивилизацию и дятлов...
Это карма ! Видимо, мы слишком грешили в предыдущей жизни и за это несем сейчас всю тяжесть ответственности. Pundis Mundi, так сказать 8))

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ну, если всем всё по х.., то медицина бессильна.
Ампутация части требований иногда спасает, но это долгий и болезненный процесс

ГВ>Ну что тут скажешь... Как всегда, всё сходится на руководстве: не сам же по себе этот самый цейтнот возникает.
Дело в том, что от технических специалистов требуется знание и понимание того, что они делают. Это требуют даже от дорожных рабочих. А вот разнокалиберное начальство находится совершенно в другом положении — им просто не надо знать и понимать хоть что-то, да они этого и не хотят

Здравствуйте, eao197, Вы писали:

ГВ>>Это как раз нормально: кому нужно второстепенное качество без первоочередного?
E>Ну да, это нормально. Вот только gandalfgrey в других условиях оказался. Или ему так сейчас кажется.
А чего вы, собственно, удивляетесь ? Или никогда не видели, как люди выбирают какой-либо продукт за рюшечки, не сильно интересуясь качеством и функциональностью ? Ничего странного тут нет

Здравствуйте, eao197, Вы писали:

E>Обновлять алгоритмы обработки удаленно в C++ хоть и проблематично, но все-таки возможно. Например, можно готовые DLL-ки со специальной точкой входа пересылать. Удаленная сторона их сохраняет, подгружает и интегрирует в свой основной процесс. Хотя лучше это все-таки делать другими средствами, с возможностью быстрого отката к предыдущим версиям.
Ну, DLL может оказаться оверкиллом. Хотя, если ограничиться определенным подмножеством задач (для которого, к примеру, не нужна таблица импорта), то это может и сработать.
Альтернативой могла бы быть передача некоего байт-кода, к примеру LLVM, который после JIT заработает на сервере.

Здравствуйте, eao197, Вы писали:

V>>А как же без описания в задачах, где требуется сериализация? Если бы нам надо было гонять данные только лишь м/у абсолютно совместимыми (напр. по языку, железу и отображением структур в памяти) системами, то можно было бы прямо куски памяти гонять, без морок с какой-то сериализацией.

E>А так же, как в случае с XML (без DTD или XSD), JSON, YAML... Там формат практически самоописывающийся.

Не самоописывающийся, а структурированный. В похожем смысле и ASN.1 BER самоописывающийся.
В любом случае, приёмная сторона должна знать, что с этой структурой делать. И если мы зачастую DTD/XSD в виде отдельных док-тов не делаем, это не значит, что их аналогов нет у нас в голове в момент написания сериализатора/парсера некоего своего XML, иначе просто нихрена работать не будет.